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

HTTP Response Smuggling / Desync

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

• Якщо ви хочете побачити вашу компанію рекламовану в HackTricks або завантажити HackTricks у форматі PDF, перевірте ПЛАНИ ПІДПИСКИ!
• Отримайте офіційний PEASS & HackTricks мерч
• Відкрийте для себе Сім'ю PEASS, нашу колекцію ексклюзивних NFT
• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами на Twitter 🐦 @carlospolopm.
• Поділіться своїми хакерськими трюками, надсилайте PR до HackTricks та HackTricks Cloud репозиторіїв GitHub.

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

Десинхронізація черги HTTP-запитів

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

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

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

Десинхронізація черги HTTP-каналів

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

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

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

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

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

Кілька Вкладених Впроваджень

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

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

Організація Експлойтів

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

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

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

Зловживання десинхронізацією черги відповідей HTTP

Захоплення запитів інших користувачів

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

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

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

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

Десинхронізація відповідей

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

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

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

Тому, якщо зловмисник впроваджує HEAD-запит, як на цих зображеннях:

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

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

Плутанина контенту

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

Отруєння кешу

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

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

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

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

Обман веб-кешу

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

Розділення відповіді

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

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

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

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

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

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

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