mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-22 12:43:23 +00:00
159 lines
15 KiB
Markdown
159 lines
15 KiB
Markdown
# HTTP Response Smuggling / Desync
|
||
|
||
{% hint style="success" %}
|
||
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
||
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||
|
||
<details>
|
||
|
||
<summary>Support HackTricks</summary>
|
||
|
||
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
|
||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||
|
||
</details>
|
||
{% endhint %}
|
||
|
||
**Техніка цього посту була взята з відео:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](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, і відповіді на **початковий запит і на контрабандний** відповідають негайно, контрабандна відповідь не буде вставлена в чергу відповідей жертви, а просто **буде відкинута як помилка**.
|
||
|
||
![](<../.gitbook/assets/image (633).png>)
|
||
|
||
Отже, потрібно, щоб **контрабандний** **запит** **потребував більше часу для обробки** на бекенд-сервері. Таким чином, до моменту обробки контрабандного запиту зв'язок з атакуючим буде завершено.
|
||
|
||
Якщо в цій конкретній ситуації **жертва надіслала запит**, а **контрабандний запит відповідає раніше** легітимного запиту, **контрабандна відповідь буде надіслана жертві**. Таким чином, атакуючий буде **контролювати запит, "виконаний" жертвою**.
|
||
|
||
Більше того, якщо **атакуючий потім виконує запит**, а **легітимна відповідь** на **запит жертви** **відповідає** **раніше** запиту атакуючого. **Відповідь жертві буде надіслана атакуючому**, **викрадаючи** відповідь жертви (яка може містити, наприклад, заголовок **Set-Cookie**).
|
||
|
||
![](<../.gitbook/assets/image (1020).png>)
|
||
|
||
![](<../.gitbook/assets/image (719).png>)
|
||
|
||
### 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 <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||
|
||
Як і з відомими корисними вантажами HTTP Request Smuggling, ви можете **вкрасти запит жертви** з однією важливою різницею: у цьому випадку вам просто потрібно, щоб **надісланий вміст відображався у відповіді**, **не потрібне постійне зберігання**.
|
||
|
||
По-перше, атакуючий надсилає корисний вантаж, що містить **кінцевий POST запит з відображеним параметром** в кінці та великим Content-Length.
|
||
|
||
![](<../.gitbook/assets/image (1053).png>)
|
||
|
||
Потім, як тільки **початковий запит** (синій) був **оброблений** і **поки** **сонний** запит обробляється (жовтий), **наступний запит, що надходить від жертви**, буде **додано в чергу відразу після відображеного параметра**:
|
||
|
||
![](<../.gitbook/assets/image (794).png>)
|
||
|
||
Потім **жертва** отримає **відповідь** на **сонний** запит, і якщо в цей час **атакуючий** **надіслав** **інший** **запит**, **відповідь на запит з відображеним вмістом буде надіслана йому**.
|
||
|
||
## Response Desynchronisation
|
||
|
||
На даний момент ми дізналися, як зловживати атаками HTTP Request Smuggling, щоб **контролювати** **запит**, **відповідь** на який **клієнт** збирається **отримати**, і як ви можете потім **вкрасти відповідь, яка була призначена жертві**.
|
||
|
||
Але все ще можливо **десинхронізувати ще** більше відповідей.
|
||
|
||
Є цікаві запити, такі як **HEAD** запит, які не повинні мати **жодного вмісту всередині тіла відповіді** і які повинні (повинні) **містити Content-Length** запиту, як **якщо це був GET запит**.
|
||
|
||
Отже, якщо атакуючий **впроваджує** **HEAD** запит, як на цих зображеннях:
|
||
|
||
![](<../.gitbook/assets/image (1107).png>)
|
||
|
||
Тоді, **як тільки синій запит буде відповісти атакуючому**, наступний запит жертви буде введено в чергу:
|
||
|
||
![](<../.gitbook/assets/image (999).png>)
|
||
|
||
Тоді **жертва** отримає **відповідь** на **HEAD** запит, яка **міститиме Content-Length, але жодного вмісту**. Отже, проксі **не надішле цю відповідь** жертві, а **чекатиме** на деякий **вміст**, який насправді буде **відповіддю на жовтий запит** (також впроваджений атакуючим):
|
||
|
||
![](<../.gitbook/assets/image (735).png>)
|
||
|
||
### Content Confusion
|
||
|
||
Слідуючи попередньому прикладу, знаючи, що ви можете **контролювати тіло** запиту, відповідь на який отримає жертва, і що **HEAD** **відповідь** зазвичай містить у своїх заголовках **Content-Type і Content-Length**, ви можете **надіслати запит, подібний до наступного**, щоб **викликати XSS** у жертви, не роблячи сторінку вразливою до XSS:
|
||
|
||
![](<../.gitbook/assets/image (688).png>)
|
||
|
||
### Cache Poisoning
|
||
|
||
Зловживаючи раніше обговореною десинхронізацією відповіді Content Confusion атаки, **якщо кеш зберігає відповідь на запит, виконаний жертвою, і ця відповідь є впровадженою, що викликає XSS, тоді кеш отруєний**.
|
||
|
||
Зловмисний запит, що містить корисний вантаж XSS:
|
||
|
||
![](<../.gitbook/assets/image (614).png>)
|
||
|
||
Зловмисна відповідь жертві, що містить заголовок, який вказує кешу зберігати відповідь:
|
||
|
||
![](<../.gitbook/assets/image (566).png>)
|
||
|
||
{% hint style="warning" %}
|
||
Зверніть увагу, що в цьому випадку, якщо **"жертва" є атакуючим**, він тепер може виконати **отруєння кешу на довільних URL-адресах**, оскільки він може **контролювати URL-адресу, яка буде кешована** з зловмисною відповіддю.
|
||
{% endhint %}
|
||
|
||
### Web Cache Deception
|
||
|
||
Ця атака схожа на попередню, але **замість того, щоб впроваджувати корисний вантаж у кеш, атакуючий буде кешувати інформацію жертви всередині кешу:**
|
||
|
||
![](<../.gitbook/assets/image (991).png>)
|
||
|
||
### Response Splitting
|
||
|
||
**Мета** цієї атаки полягає в тому, щоб знову зловживати **десинхронізацією відповіді**, щоб **змусити проксі надіслати 100% відповідь, згенеровану атакуючим**.
|
||
|
||
Щоб досягти цього, атакуючий повинен знайти кінцеву точку веб-додатку, яка **відображає деякі значення у відповіді** і **знати довжину вмісту відповіді HEAD**.
|
||
|
||
Він надішле **експлойт** на зразок:
|
||
|
||
![](<../.gitbook/assets/image (911).png>)
|
||
|
||
Після того, як перший запит буде вирішено і надіслано назад атакуючому, **запит жертви буде додано в чергу**:
|
||
|
||
![](<../.gitbook/assets/image (737).png>)
|
||
|
||
Жертва отримає у відповідь **HEAD відповідь + вміст відповіді другого запиту (що містить частину відображених даних):**
|
||
|
||
![](<../.gitbook/assets/image (356).png>)
|
||
|
||
Однак зверніть увагу, як **відображені дані мали розмір відповідно до Content-Length** відповіді **HEAD**, що **згенерувало дійсну HTTP відповідь у черзі відповідей**.
|
||
|
||
Отже, **наступний запит другого жертви** буде **отримувати** у відповідь щось повністю створене атакуючим. Оскільки відповідь повністю створена атакуючим, він також може **змусити проксі кешувати відповідь**.
|
||
|
||
{% hint style="success" %}
|
||
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
||
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||
|
||
<details>
|
||
|
||
<summary>Support HackTricks</summary>
|
||
|
||
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
|
||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||
|
||
</details>
|
||
{% endhint %}
|