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 attack, оскільки ви надсилаєте повні запити, ви можете впроваджувати в один корисний вантаж десятки відповідей, які будуть десинхронізувати десятки користувачів, які будуть отримувати впроваджені відповіді.
Окрім того, що ви можете легше розподілити десятки експлойтів серед легітимних користувачів, це також може бути використано для виклику 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)
