mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-29 08:01:00 +00:00
159 lines
11 KiB
Markdown
159 lines
11 KiB
Markdown
# HTTP Response Smuggling / Desync
|
|
|
|
{% hint style="success" %}
|
|
Leer & oefen 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">\
|
|
Leer & oefen 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>
|
|
|
|
* Kyk na die [**subskripsie planne**](https://github.com/sponsors/carlospolop)!
|
|
* **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
|
|
|
</details>
|
|
{% endhint %}
|
|
|
|
**Die tegniek van hierdie pos is geneem uit die video:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
|
|
|
|
## HTTP Request Queue Desynchronisation
|
|
|
|
Eerstens, hierdie tegniek **misbruik 'n HTTP Request Smuggling kwesbaarheid**, so jy moet weet wat dit is:
|
|
|
|
Die **hoof** **verskil** tussen hierdie tegniek en 'n algemene HTTP Request smuggling is dat **in plaas van** om die **aanvraag** van die **slagoffer** **te aanval** **deur 'n voorvoegsel daaraan toe te voeg**, gaan ons die **antwoord wat die slagoffer ontvang** **lek of wysig**. Dit word gedoen deur, in plaas daarvan om 1 aanvraag en 'n half te stuur om die HTTP Request smuggling te misbruik, **2 volledige versoeke te stuur om die proxies se antwoordqueue te desynchroniseer**.
|
|
|
|
Dit is omdat ons in staat gaan wees om die **antwoordqueue te desynchroniseer** sodat die **antwoord** van die **legitieme** **aanvraag** van die **slagoffer na die aanvaller gestuur word**, of deur **aanvallers beheerde inhoud in die antwoord aan die slagoffer in te spuit**.
|
|
|
|
### HTTP Pipeline Desync
|
|
|
|
HTTP/1.1 laat toe om **verskillende hulpbronne te vra sonder om te wag vir vorige**. Daarom, as daar 'n **proxy** in die **middel** is, is dit die proxies se taak om 'n **gesinkroniseerde ooreenstemming van versoeke wat na die agtergrond gestuur is en antwoorde wat daaruit kom, te handhaaf**.
|
|
|
|
Daar is egter 'n probleem om die antwoordequeue te desynchroniseer. As 'n aanvaller 'n HTTP Response smuggling aanval stuur en die antwoorde op die **aanvanklike aanvraag en die gesmugde een onmiddellik beantwoord word**, sal die gesmugde antwoord nie in die queue van die slagoffer se antwoord ingevoeg word nie, maar sal **net as 'n fout weggegooi word**.
|
|
|
|
.png>)
|
|
|
|
Daarom is dit nodig dat die **gesmugde** **aanvraag** **meer tyd neem om verwerk te word** binne die agtergrond bediener. Daarom, teen die tyd dat die gesmugde aanvraag verwerk word, sal die kommunikasie met die aanvaller verby wees.
|
|
|
|
As in hierdie spesifieke situasie 'n **slagoffer 'n aanvraag gestuur het** en die **gesmugde aanvraag voor** die legitieme aanvraag beantwoord word, sal die **gesmugde antwoord na die slagoffer gestuur word**. Daarom sal die aanvaller die **aanvraag "uitgevoer" deur die slagoffer** **beheer**.
|
|
|
|
Boonop, as die **aanvaller dan 'n aanvraag uitvoer** en die **legitieme antwoord** op die **slagoffer** se aanvraag **beantwoord** **voor** die aanvaller se aanvraag. Die **antwoord aan die slagoffer gaan na die aanvaller gestuur word**, **steel** die antwoord aan die slagoffer (wat byvoorbeeld die header **Set-Cookie** kan bevat).
|
|
|
|
.png>)
|
|
|
|
.png>)
|
|
|
|
### Meervoudige Geneste Inspuitings
|
|
|
|
Nog 'n **interessante verskil** met algemene **HTTP Request Smuggling** is dat, in 'n algemene smuggling aanval, die **doel** is om die **begin van die slagoffer se aanvraag** te **wysig** sodat dit 'n onverwagte aksie uitvoer. In 'n **HTTP Response smuggling aanval**, aangesien jy **volledige versoeke stuur**, kan jy **in een payload tiener antwoorde inspuit** wat **tieners gebruikers gaan desynchroniseer** wat die **ingespuite** **antwoorde** gaan **ontvang**.
|
|
|
|
Afgesien van die vermoë om **meer maklik tiener exploits** oor legitieme gebruikers te versprei, kan dit ook gebruik word om 'n **DoS** op die bediener te veroorsaak.
|
|
|
|
### Exploit Organisasie
|
|
|
|
Soos voorheen verduidelik, om hierdie tegniek te misbruik, is dit nodig dat die **eerste gesmugde boodskap** in die bediener **baie tyd neem om verwerk te word**.
|
|
|
|
Hierdie **tydrowende aanvraag is genoeg** as ons net wil **probeer om die slagoffer se antwoord te steel.** Maar as jy 'n meer komplekse exploit wil uitvoer, sal dit 'n algemene struktuur vir die exploit wees.
|
|
|
|
Eerstens die **aanvanklike** aanvraag wat **HTTP** **Request** **smuggling** misbruik, dan die **tydrowende aanvraag** en dan **1 of meer payload versoeke** waarvan die antwoorde aan die slagoffers gestuur sal word.
|
|
|
|
## Misbruik van HTTP Response Queue Desynchronisation
|
|
|
|
### Vasvang ander gebruikers se versoeke <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
|
|
|
Soos met HTTP Request Smuggling bekende payloads, kan jy **die slagoffer se aanvraag steel** met een belangrike verskil: In hierdie geval het jy net die **gestuurde inhoud wat in die antwoord weerspieël moet word**, **geen volhoubare berging** is nodig nie.
|
|
|
|
Eerstens, die aanvaller stuur 'n payload wat 'n **finale POST aanvraag met die weerspieëlde parameter** aan die einde en 'n groot Content-Length bevat.
|
|
|
|
.png>)
|
|
|
|
Dan, sodra die **aanvanklike aanvraag** (blou) verwerk is en **terwyl** die **slaapagtige** een verwerk word (geel) gaan die **volgende aanvraag wat van 'n slagoffer aankom** in die queue **net na die weerspieëlde parameter** ingevoeg word:
|
|
|
|
.png>)
|
|
|
|
Dan, die **slagoffer** sal die **antwoord** op die **slaapagtige** aanvraag ontvang en as intussen die **aanvaller** **nog 'n** **aanvraag gestuur het**, sal die **antwoord van die weerspieëlde inhoud aanvraag na hom gestuur word**.
|
|
|
|
## Antwoord Desynchronisation
|
|
|
|
Tot op hierdie punt, het ons geleer hoe om HTTP Request Smuggling aanvalle te misbruik om die **aanvraag** **waarvan** die **antwoord** 'n **klient** gaan **ontvang** te **beheer** en hoe jy dan die **antwoord wat bedoel was vir die slagoffer** kan **steel**.
|
|
|
|
Maar dit is steeds moontlik om die antwoorde **nog meer te desynchroniseer**.
|
|
|
|
Daar is interessante versoeke soos **HEAD** versoeke wat gespesifiseer is om **geen inhoud binne die antwoord se liggaam** te hê nie en wat moet (moet) **die Content-Length** van die aanvraag bevat soos **as dit 'n GET aanvraag was**.
|
|
|
|
Daarom, as 'n aanvaller 'n **HEAD** aanvraag **inspuit**, soos in hierdie beelde:
|
|
|
|
.png>)
|
|
|
|
Dan, **sodra die blou een aan die aanvaller beantwoord word**, gaan die volgende slagoffer se aanvraag in die queue ingevoer word:
|
|
|
|
.png>)
|
|
|
|
Dan, die **slagoffer** sal die **antwoord** van die **HEAD** aanvraag ontvang, wat **'n Content-Length gaan bevat maar geen inhoud nie**. Daarom, die proxy **sal hierdie antwoord nie aan die slagoffer stuur nie**, maar sal **wag** vir 'n **inhoud**, wat eintlik die **antwoord op die geel aanvraag** gaan wees (ook deur die aanvaller ingespuit):
|
|
|
|
.png>)
|
|
|
|
### Inhoud Verwarring
|
|
|
|
Volgende die vorige voorbeeld, wetende dat jy die **liggaam** van die aanvraag kan **beheer** waarvan die antwoord die slagoffer gaan ontvang en dat 'n **HEAD** **antwoord** gewoonlik in sy headers die **Content-Type en die Content-Length** bevat, kan jy **'n aanvraag soos die volgende** stuur om **XSS** in die slagoffer te veroorsaak sonder dat die bladsy kwesbaar is vir XSS:
|
|
|
|
.png>)
|
|
|
|
### Cache Vergiftiging
|
|
|
|
Deur die voorheen bespreekte antwoord desynchronisering Inhoud Verwarring aanval te misbruik, **as die cache die antwoord op die aanvraag wat deur die slagoffer uitgevoer is, stoor en hierdie antwoord 'n ingespuite een is wat 'n XSS veroorsaak, dan is die cache vergiftig**.
|
|
|
|
Kwaadwillige aanvraag wat die XSS payload bevat:
|
|
|
|
.png>)
|
|
|
|
Kwaadwillige antwoord aan die slagoffer wat die header bevat wat aan die cache aandui om die antwoord te stoor:
|
|
|
|
.png>)
|
|
|
|
{% hint style="warning" %}
|
|
Let daarop dat in hierdie geval as die **"slagoffer" die aanvaller** is, hy nou **cache vergiftiging in arbitrêre URL's** kan uitvoer aangesien hy die **URL wat in die cache gestoor gaan word** met die kwaadwillige antwoord kan **beheer**.
|
|
{% endhint %}
|
|
|
|
### Web Cache Misleiding
|
|
|
|
Hierdie aanval is soortgelyk aan die vorige een, maar **in plaas daarvan om 'n payload binne die cache in te spuit, sal die aanvaller slagofferinligting binne die cache stoor:**
|
|
|
|
.png>)
|
|
|
|
### Antwoord Splitting
|
|
|
|
Die **doel** van hierdie aanval is om weer die **antwoord** **desynchronisering** te misbruik om die **proxy 'n 100% aanvaller gegenereerde antwoord** te laat stuur.
|
|
|
|
Om dit te bereik, moet die aanvaller 'n eindpunt van die webtoepassing vind wat **sekere waardes binne die antwoord weerspieël** en **weet die inhoud lengte van die HEAD antwoord**.
|
|
|
|
Hy sal 'n **exploit** soos volg stuur:
|
|
|
|
.png>)
|
|
|
|
Nadat die eerste aanvraag opgelos is en aan die aanvaller teruggestuur is, word die **slagoffer se aanvraag in die queue ingevoeg**:
|
|
|
|
.png>)
|
|
|
|
Die slagoffer sal as antwoord die **HEAD antwoord + die inhoud van die tweede aanvraag se antwoord (wat 'n deel van die weerspieëlde data bevat):**
|
|
|
|
.png>)
|
|
|
|
Let egter op hoe die **weerspieëlde data 'n grootte gehad het volgens die Content-Length** van die **HEAD** antwoord wat **'n geldige HTTP antwoord in die antwoordqueue** gegenereer het.
|
|
|
|
Daarom, die **volgende aanvraag van die tweede slagoffer** sal as **antwoord iets heeltemal deur die aanvaller saamgestel ontvang**. Aangesien die antwoord heeltemal deur die aanvaller saamgestel is, kan hy ook **die proxy laat cache die antwoord**.
|
|
|
|
{% hint style="success" %}
|
|
Leer & oefen 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">\
|
|
Leer & oefen 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>
|
|
|
|
* Kyk na die [**subskripsie planne**](https://github.com/sponsors/carlospolop)!
|
|
* **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
|
|
|
</details>
|
|
{% endhint %}
|