# HTTP Response Smuggling / Desync
{% hint style="success" %}
Learn & practice AWS Hacking:
[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Learn & practice GCP Hacking: 
[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* 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.
{% endhint %}
**The technique of this post was taken from the video:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
## HTTP Request Queue Desynchronisation
Kwanza kabisa, mbinu hii **inatumia udhaifu wa HTTP Request Smuggling**, hivyo unahitaji kujua ni nini hicho:
**tofauti** **kuu** kati ya mbinu hii na HTTP Request smuggling ya kawaida ni kwamba **badala** ya **kushambulia** **ombile** la **mhasiriwa** **kwa kuongeza kiambatisho** kwake, tunakwenda **kuvuja au kubadilisha jibu ambalo mhasiriwa anapata**. Hii inafanywa kwa, badala ya kutuma ombi 1 na nusu ili kutumia HTTP Request smuggling, **tuma ombi 2 kamili ili kuondoa usawa wa foleni za majibu ya proxies**.
Hii ni kwa sababu tutakuwa na uwezo wa **kuondoa usawa wa foleni ya majibu** ili **jibu** kutoka kwa **ombile** la **halali** la **mhasiriwa litumwe kwa mshambuliaji**, au kwa **kuingiza maudhui yanayodhibitiwa na mshambuliaji katika jibu kwa mhasiriwa**.
### HTTP Pipeline Desync
HTTP/1.1 inaruhusu kuomba **rasilimali tofauti bila kuhitaji kusubiri zilizopita**. Hivyo, ikiwa kuna **proxy** katikati, ni jukumu la proxies **kuweka usawa wa maombi yaliyotumwa kwa backend na majibu yanayotoka kutoka kwake**.
Hata hivyo, kuna tatizo la kuondoa usawa wa foleni za majibu. Ikiwa mshambuliaji atatuma shambulio la HTTP Response smuggling na majibu kwa **ombile la awali na lile lililovuja yanajibiwa mara moja**, jibu lililovuja halitaingizwa ndani ya foleni ya jibu la mhasiriwa bali litakataliwa **kama kosa**.
.png>)
Hivyo, inahitajika kwamba **ombile** **lililovuja** **lichukue muda mrefu zaidi kutekelezwa** ndani ya seva ya backend. Hivyo, wakati ombi lililovuja linaposhughulikiwa, mawasiliano na mshambuliaji yatakuwa yameisha.
Ikiwa katika hali hii maalum **mhasiriwa ametuma ombi** na **ombile lililovuja linajibiwa kabla** ya ombi halali, **jibu lililovuja litatumwa kwa mhasiriwa**. Hivyo, mshambuliaji atakuwa **akidhibiti ombi "lililofanywa" na mhasiriwa**.
Zaidi ya hayo, ikiwa **mshambuliaji kisha atafanya ombi** na **jibu halali** kwa **ombile** la **mhasiriwa** linajibiwa **kabla** ya ombi la mshambuliaji. **Jibu kwa mhasiriwa litatumwa kwa mshambuliaji**, **kuchukua** jibu kwa mhasiriwa (ambalo linaweza kuwa na mfano kichwa **Set-Cookie**).
.png>)
.png>)
### Multiple Nested Injections
Tofauti nyingine **ya kuvutia** na **HTTP Request Smuggling** ya kawaida ni kwamba, katika shambulio la kawaida la smuggling, **lengo** ni **kubadilisha mwanzo wa ombi la mhasiriwa** ili lifanye kitendo kisichotarajiwa. Katika **shambulio la HTTP Response smuggling**, kwa kuwa unatumia **maombi kamili**, unaweza **kuingiza katika payload moja majibu kumi** ambayo yatakuwa **yakiondoa usawa wa watumiaji kumi** ambao watakuwa **wakipokea** **majibu yaliyoingizwa**.
Mbali na kuwa na uwezo wa **kusambaza kwa urahisi majaribio kumi** kati ya watumiaji halali, hii pia inaweza kutumika kusababisha **DoS** katika seva.
### Exploit Organisation
Kama ilivyoelezwa hapo awali, ili kutumia mbinu hii, inahitajika kwamba **ujumbe wa kwanza ulioingizwa** ndani ya seva **uchukue muda mwingi kutekelezwa**.
Hii **ombile linalochukua muda** ni ya kutosha ikiwa tunataka tu **kujaribu kuiba jibu la mhasiriwa.** Lakini ikiwa unataka kufanya exploit ngumu zaidi hii itakuwa muundo wa kawaida kwa exploit.
Kwanza kabisa **ombile la awali** linalotumia **HTTP** **Request** **smuggling**, kisha **ombile linalochukua muda** na kisha **ombile 1 au zaidi** ambayo majibu yake yatatumwa kwa mhasiriwa.
## Abusing HTTP Response Queue Desynchronisation
### Capturing other users' requests
Kama ilivyo na payloads za HTTP Request Smuggling zinazojulikana, unaweza **kuiba ombi la mhasiriwa** kwa tofauti moja muhimu: Katika kesi hii unahitaji tu **kupeleka maudhui ili yaonyeshwe katika jibu**, **hakuna hifadhi ya kudumu** inahitajika.
Kwanza, mshambuliaji anatuma payload inayojumuisha **ombile la mwisho la POST lenye parameter iliyoonyeshwa** mwishoni na Content-Length kubwa.
.png>)
Kisha, mara tu **ombile la awali** (bluu) liliposhughulikiwa na **wakati** **ombile la usingizi** linaposhughulikiwa (njano) **ombile linalofuata linalotoka kwa mhasiriwa** litakuwa **limeongezwa kwenye foleni mara tu baada ya parameter iliyoonyeshwa**:
.png>)
Kisha, **mhasiriwa** atapokea **jibu** kwa **ombile la usingizi** na ikiwa wakati huo **mshambuliaji** **alituma** **ombile** **lingine**, **jibu kutoka kwa ombi la maudhui yaliyoonyeshwa litatumwa kwake**.
## Response Desynchronisation
Hadi sasa, tumefundishwa jinsi ya kutumia shambulio la HTTP Request Smuggling ili **kudhibiti** **ombile** **ambalo** **jibu** ambalo **mteja** atakuwa **akipokea** na jinsi unaweza kisha **kuiba jibu ambalo lilikuwa limekusudiwa kwa mhasiriwa**.
Lakini bado inawezekana **kuondoa usawa hata** zaidi majibu.
Kuna maombi ya kuvutia kama **HEAD** ambayo yameelezwa kutokuwa na **maudhui yoyote ndani ya mwili wa majibu** na ambayo yanapaswa (lazima) **kujumuisha Content-Length** ya ombi kama **kama ingekuwa ombi la GET**.
Hivyo, ikiwa mshambuliaji **anaingiza** ombi la **HEAD**, kama katika picha hizi:
.png>)
Kisha, **mara tu bluu inajibiwa kwa mshambuliaji**, ombi linalofuata la mhasiriwa litakuwa limeingizwa kwenye foleni:
.png>)
Kisha, **mhasiriwa** atapokea **jibu** kutoka kwa **ombile la HEAD**, ambalo **litakuwa na Content-Length lakini hakuna maudhui kabisa**. Hivyo, proxy **haitatuma jibu hili** kwa mhasiriwa, bali itangojea **maudhui**, ambayo kwa kweli yatakuwa **jibu kwa ombi la njano** (pia lililoingizwa na mshambuliaji):
.png>)
### Content Confusion
Kufuata mfano wa awali, ukijua kwamba unaweza **kudhibiti mwili** wa ombi ambalo jibu litakalopokea mhasiriwa na kwamba **jibu la HEAD** kawaida lina **Content-Type na Content-Length** katika vichwa vyake, unaweza **kutuma ombi kama ifuatavyo** ili **kusababisha XSS** kwa mhasiriwa bila ukurasa kuwa na udhaifu wa XSS:
.png>)
### Cache Poisoning
Kutatiza shambulio la awali lililozungumziwa la desynchronisation ya jibu la Content Confusion, **ikiwa cache inahifadhi jibu kwa ombi lililofanywa na mhasiriwa na jibu hili ni la kuingizwa linalosababisha XSS, basi cache inakuwa na sumu**.
Ombi la uhalifu likijumuisha payload ya XSS:
.png>)
Jibu la uhalifu kwa mhasiriwa ambalo lina kichwa kinachoonyesha kwa cache kuhifadhi jibu:
.png>)
{% hint style="warning" %}
Note that in this case if the **"victim" is the attacker** he can now perform **cache poisoning in arbitrary URLs** as he can **control the URL that is going to be cached** with the malicious response.
{% endhint %}
### Web Cache Deception
Shambulio hili ni sawa na la awali, lakini **badala ya kuingiza payload ndani ya cache, mshambuliaji atakuwa akihifadhi taarifa za mhasiriwa ndani ya cache:**
.png>)
### Response Splitting
**Lengo** la shambulio hili ni kutumia tena **desynchronisation** ya **jibu** ili **kufanya proxy itume jibu 100% lililotengenezwa na mshambuliaji**.
Ili kufikia hili, mshambuliaji anahitaji kupata mwisho wa programu ya wavuti ambayo **inaonyesha baadhi ya thamani ndani ya jibu** na **ajue urefu wa maudhui ya jibu la HEAD**.
Atatuma **exploit** kama:
.png>)
Baada ya ombi la kwanza kutatuliwa na kutumwa kwa mshambuliaji, **ombile la mhasiriwa linaongezwa kwenye foleni**:
.png>)
Mhasiriwa atapokea kama jibu **jibu la HEAD + maudhui ya jibu la ombi la pili (linalojumuisha sehemu ya data iliyoonyeshwa):**
.png>)
Hata hivyo, angalia jinsi **data iliyoonyeshwa ilikuwa na ukubwa kulingana na Content-Length** ya **jibu la HEAD** ambayo **ilitoa jibu halali la HTTP katika foleni ya majibu**.
Hivyo, **ombile linalofuata la mhasiriwa wa pili** litakuwa **likipokea** kama **jibu kitu kilichotengenezwa kabisa na mshambuliaji**. Kwa kuwa jibu linatengenezwa kabisa na mshambuliaji anaweza pia **kufanya proxy ihifadhi jibu**.
{% hint style="success" %}
Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* 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.
{% endhint %}