hacktricks/pentesting-web/http-response-smuggling-desync.md

HTTP Response Smuggling / Desync

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Техніка цього посту була взята з відео: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

HTTP Request Queue Desynchronisation

По-перше, ця техніка зловживає вразливістю HTTP Request Smuggling, тому вам потрібно знати, що це таке:

Головна різниця між цією технікою та звичайним HTTP Request smuggling полягає в тому, що замість атаки на запит жертви, додаючи префікс до нього, ми будемо викрадати або модифікувати відповідь, яку отримує жертва. Це робиться шляхом, замість того, щоб надіслати 1 запит і півтора для зловживання HTTP Request smuggling, надіслати 2 повних запити для десинхронізації черги відповідей проксі.

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

HTTP Pipeline Desync

HTTP/1.1 дозволяє запитувати різні ресурси, не чекаючи на попередні. Тому, якщо в середині є проксі, це завдання проксі - підтримувати синхронізовану відповідність запитів, надісланих на бекенд, і відповідей, що надходять з нього.

Однак є проблема з десинхронізацією черги відповідей. Якщо атакуючий надсилає атаку HTTP Response smuggling, і відповіді на початковий запит і на контрабандний відповідають негайно, контрабандна відповідь не буде вставлена в чергу відповідей жертви, а просто буде відкинута як помилка.

Отже, потрібно, щоб контрабандний запит потребував більше часу для обробки на бекенд-сервері. Таким чином, до моменту обробки контрабандного запиту зв'язок з атакуючим буде завершено.

Якщо в цій конкретній ситуації жертва надіслала запит, а контрабандний запит відповідає раніше легітимного запиту, контрабандна відповідь буде надіслана жертві. Таким чином, атакуючий буде контролювати запит, "виконаний" жертвою.

Більше того, якщо атакуючий потім виконує запит, а легітимна відповідь на запит жертви відповідає раніше запиту атакуючого. Відповідь жертві буде надіслана атакуючому, викрадаючи відповідь жертви (яка може містити, наприклад, заголовок Set-Cookie).

Multiple Nested Injections

Ще одна цікава різниця з звичайним HTTP Request Smuggling полягає в тому, що в звичайній контрабандній атаці мета полягає в тому, щоб модифікувати початок запиту жертви, щоб він виконував несподівану дію. У HTTP Response smuggling атаці, оскільки ви надсилаєте повні запити, ви можете впроваджувати в один корисний вантаж десятки відповідей, які будуть десинхронізувати десятки користувачів, які будуть отримувати впроваджені відповіді.

Окрім того, що ви можете легше розподілити десятки експлойтів серед легітимних користувачів, це також може бути використано для виклику DoS на сервері.

Exploit Organisation

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

Цей часомісткий запит є достатнім, якщо ми просто хочемо спробувати вкрасти відповідь жертви. Але якщо ви хочете виконати більш складний експлойт, це буде звичайна структура для експлойту.

По-перше, початковий запит, що зловживає HTTP Request smuggling, потім часомісткий запит, а потім 1 або більше запитів з корисним вантажем, відповіді на які будуть надіслані жертвам.

Abusing HTTP Response Queue Desynchronisation

Capturing other users' requests

Як і з відомими корисними вантажами HTTP Request Smuggling, ви можете вкрасти запит жертви з однією важливою різницею: у цьому випадку вам просто потрібно, щоб надісланий вміст відображався у відповіді, не потрібне постійне зберігання.

По-перше, атакуючий надсилає корисний вантаж, що містить кінцевий POST запит з відображеним параметром в кінці та великим Content-Length.

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

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

Response Desynchronisation

На даний момент ми дізналися, як зловживати атаками HTTP Request Smuggling, щоб контролювати запит, відповідь на який клієнт збирається отримати, і як ви можете потім вкрасти відповідь, яка була призначена жертві.

Але все ще можливо десинхронізувати ще більше відповідей.

Є цікаві запити, такі як HEAD запит, які не повинні мати жодного вмісту всередині тіла відповіді і які повинні (повинні) містити Content-Length запиту, як якщо це був GET запит.

Отже, якщо атакуючий впроваджує HEAD запит, як на цих зображеннях:

Тоді, як тільки синій запит буде відповісти атакуючому, наступний запит жертви буде введено в чергу:

Тоді жертва отримає відповідь на HEAD запит, яка міститиме Content-Length, але жодного вмісту. Отже, проксі не надішле цю відповідь жертві, а чекатиме на деякий вміст, який насправді буде відповіддю на жовтий запит (також впроваджений атакуючим):

Content Confusion

Слідуючи попередньому прикладу, знаючи, що ви можете контролювати тіло запиту, відповідь на який отримає жертва, і що HEAD відповідь зазвичай містить у своїх заголовках Content-Type і Content-Length, ви можете надіслати запит, подібний до наступного, щоб викликати XSS у жертви, не роблячи сторінку вразливою до XSS:

Cache Poisoning

Зловживаючи раніше обговореною десинхронізацією відповіді Content Confusion атаки, якщо кеш зберігає відповідь на запит, виконаний жертвою, і ця відповідь є впровадженою, що викликає XSS, тоді кеш отруєний.

Зловмисний запит, що містить корисний вантаж XSS:

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

{% hint style="warning" %} Зверніть увагу, що в цьому випадку, якщо "жертва" є атакуючим, він тепер може виконати отруєння кешу на довільних URL-адресах, оскільки він може контролювати URL-адресу, яка буде кешована з зловмисною відповіддю. {% endhint %}

Web Cache Deception

Ця атака схожа на попередню, але замість того, щоб впроваджувати корисний вантаж у кеш, атакуючий буде кешувати інформацію жертви всередині кешу:

Response Splitting

Мета цієї атаки полягає в тому, щоб знову зловживати десинхронізацією відповіді, щоб змусити проксі надіслати 100% відповідь, згенеровану атакуючим.

Щоб досягти цього, атакуючий повинен знайти кінцеву точку веб-додатку, яка відображає деякі значення у відповіді і знати довжину вмісту відповіді HEAD.

Він надішле експлойт на зразок:

Після того, як перший запит буде вирішено і надіслано назад атакуючому, запит жертви буде додано в чергу:

Жертва отримає у відповідь HEAD відповідь + вміст відповіді другого запиту (що містить частину відображених даних):

Однак зверніть увагу, як відображені дані мали розмір відповідно до Content-Length відповіді HEAD, що згенерувало дійсну HTTP відповідь у черзі відповідей.

Отже, наступний запит другого жертви буде отримувати у відповідь щось повністю створене атакуючим. Оскільки відповідь повністю створена атакуючим, він також може змусити проксі кешувати відповідь.

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}