HTTP Response Smuggling / Desync
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Техніка цього посту була взята з відео: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
По-перше, ця техніка зловживає вразливістю HTTP Request Smuggling, тому вам потрібно знати, що це таке:
Головна різниця між цією технікою та звичайним HTTP Request smuggling полягає в тому, що замість атаки на запит жертви, додаючи префікс до нього, ми будемо викрадати або модифікувати відповідь, яку отримує жертва. Це робиться шляхом, замість того, щоб надіслати 1 запит і півтора для зловживання HTTP Request smuggling, надіслати 2 повних запити для десинхронізації черги відповідей проксі.
Це тому, що ми зможемо десинхронізувати чергу відповідей, щоб відповідь від легітимного запиту жертви була надіслана атакуючому, або шляхом впровадження контролюваного атакуючим вмісту у відповідь жертві.
HTTP/1.1 дозволяє запитувати різні ресурси, не чекаючи на попередні. Тому, якщо в середині є проксі, це завдання проксі - підтримувати синхронізовану відповідність запитів, надісланих на бекенд, і відповідей, що надходять з нього.
Однак є проблема з десинхронізацією черги відповідей. Якщо атакуючий надсилає атаку HTTP Response smuggling, і відповіді на початковий запит і на контрабандний відповідають негайно, контрабандна відповідь не буде вставлена в чергу відповідей жертви, а просто буде відкинута як помилка.
Отже, потрібно, щоб контрабандний запит потребував більше часу для обробки на бекенд-сервері. Таким чином, до моменту обробки контрабандного запиту зв'язок з атакуючим буде завершено.
Якщо в цій конкретній ситуації жертва надіслала запит, а контрабандний запит відповідає раніше легітимного запиту, контрабандна відповідь буде надіслана жертві. Таким чином, атакуючий буде контролювати запит, "виконаний" жертвою.
Більше того, якщо атакуючий потім виконує запит, а легітимна відповідь на запит жертви відповідає раніше запиту атакуючого. Відповідь жертві буде надіслана атакуючому, викрадаючи відповідь жертви (яка може містити, наприклад, заголовок Set-Cookie).
Ще одна цікава різниця з звичайним HTTP Request Smuggling полягає в тому, що в звичайній контрабандній атаці мета полягає в тому, щоб модифікувати початок запиту жертви, щоб він виконував несподівану дію. У HTTP Response smuggling атаці, оскільки ви надсилаєте повні запити, ви можете впроваджувати в один корисний вантаж десятки відповідей, які будуть десинхронізувати десятки користувачів, які будуть отримувати впроваджені відповіді.
Окрім того, що ви можете легше розподілити десятки експлойтів серед легітимних користувачів, це також може бути використано для виклику DoS на сервері.
Як було пояснено раніше, щоб зловживати цією технікою, потрібно, щоб перше контрабандне повідомлення на сервер потребувало багато часу для обробки.
Цей часомісткий запит є достатнім, якщо ми просто хочемо спробувати вкрасти відповідь жертви. Але якщо ви хочете виконати більш складний експлойт, це буде звичайна структура для експлойту.
По-перше, початковий запит, що зловживає HTTP Request smuggling, потім часомісткий запит, а потім 1 або більше запитів з корисним вантажем, відповіді на які будуть надіслані жертвам.
Як і з відомими корисними вантажами HTTP Request Smuggling, ви можете вкрасти запит жертви з однією важливою різницею: у цьому випадку вам просто потрібно, щоб надісланий вміст відображався у відповіді, не потрібне постійне зберігання.
По-перше, атакуючий надсилає корисний вантаж, що містить кінцевий POST запит з відображеним параметром в кінці та великим Content-Length.
Потім, як тільки початковий запит (синій) був оброблений і поки сонний запит обробляється (жовтий), наступний запит, що надходить від жертви, буде додано в чергу відразу після відображеного параметра:
Потім жертва отримає відповідь на сонний запит, і якщо в цей час атакуючий надіслав інший запит, відповідь на запит з відображеним вмістом буде надіслана йому.
На даний момент ми дізналися, як зловживати атаками HTTP Request Smuggling, щоб контролювати запит, відповідь на який клієнт збирається отримати, і як ви можете потім вкрасти відповідь, яка була призначена жертві.
Але все ще можливо десинхронізувати ще більше відповідей.
Є цікаві запити, такі як HEAD запит, які не повинні мати жодного вмісту всередині тіла відповіді і які повинні (повинні) містити Content-Length запиту, як якщо це був GET запит.
Отже, якщо атакуючий впроваджує HEAD запит, як на цих зображеннях:
Тоді, як тільки синій запит буде відповісти атакуючому, наступний запит жертви буде введено в чергу:
Тоді жертва отримає відповідь на HEAD запит, яка міститиме Content-Length, але жодного вмісту. Отже, проксі не надішле цю відповідь жертві, а чекатиме на деякий вміст, який насправді буде відповіддю на жовтий запит (також впроваджений атакуючим):
Слідуючи попередньому прикладу, знаючи, що ви можете контролювати тіло запиту, відповідь на який отримає жертва, і що HEAD відповідь зазвичай містить у своїх заголовках Content-Type і Content-Length, ви можете надіслати запит, подібний до наступного, щоб викликати XSS у жертви, не роблячи сторінку вразливою до XSS:
Зловживаючи раніше обговореною десинхронізацією відповіді Content Confusion атаки, якщо кеш зберігає відповідь на запит, виконаний жертвою, і ця відповідь є впровадженою, що викликає XSS, тоді кеш отруєний.
Зловмисний запит, що містить корисний вантаж XSS:
Зловмисна відповідь жертві, що містить заголовок, який вказує кешу зберігати відповідь:
Зверніть увагу, що в цьому випадку, якщо "жертва" є атакуючим, він тепер може виконати отруєння кешу на довільних URL-адресах, оскільки він може контролювати URL-адресу, яка буде кешована з зловмисною відповіддю.
Ця атака схожа на попередню, але замість того, щоб впроваджувати корисний вантаж у кеш, атакуючий буде кешувати інформацію жертви всередині кешу:
Мета цієї атаки полягає в тому, щоб знову зловживати десинхронізацією відповіді, щоб змусити проксі надіслати 100% відповідь, згенеровану атакуючим.
Щоб досягти цього, атакуючий повинен знайти кінцеву точку веб-додатку, яка відображає деякі значення у відповіді і знати довжину вмісту відповіді HEAD.
Він надішле експлойт на зразок:
Після того, як перший запит буде вирішено і надіслано назад атакуючому, запит жертви буде додано в чергу:
Жертва отримає у відповідь HEAD відповідь + вміст відповіді другого запиту (що містить частину відображених даних):
Однак зверніть увагу, як відображені дані мали розмір відповідно до Content-Length відповіді HEAD, що згенерувало дійсну HTTP відповідь у черзі відповідей.
Отже, наступний запит другого жертви буде отримувати у відповідь щось повністю створене атакуючим. Оскільки відповідь повністю створена атакуючим, він також може змусити проксі кешувати відповідь.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
