HTTP Response Smuggling / Desync

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

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

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

Web Cache Deception

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

Response Splitting

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

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

Він надішле експлойт, подібний до:

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

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

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

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