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

HTTP Response Smuggling / Desync

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

• Ako želite da vidite vašu kompaniju reklamiranu u HackTricks-u ili preuzmete HackTricks u PDF formatu proverite SUBSCRIPTION PLANS!
• Nabavite zvanični PEASS & HackTricks swag
• Otkrijte The PEASS Family, našu kolekciju ekskluzivnih NFT-ova
• Pridružite se 💬 Discord grupi ili telegram grupi ili nas pratite na Twitter-u 🐦 @carlospolopm.
• Podelite svoje hakovanje trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.

Tehnika ovog posta je preuzeta iz videa: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

Desinhronizacija reda HTTP zahteva

Prvo, ova tehnika zloupotrebljava ranjivost HTTP Request Smuggling, pa morate znati šta je to:

Glavna razlika između ove tehnike i uobičajenog HTTP Request smuggling-a je ta što umesto napada zahteva žrtve dodavanjem prefiksa, mi ćemo procuriti ili izmeniti odgovor koji žrtva prima. To se postiže tako što, umesto slanja 1 zahteva i pola za zloupotrebu HTTP Request smuggling-a, šaljemo 2 potpuna zahteva da bismo desinhronizovali red odgovora proxy-ja.

To je zato što ćemo biti u mogućnosti da desinhronizujemo red odgovora, tako da odgovor na legitimni zahtev žrtve bude poslat napadaču, ili da se ubaci sadržaj pod kontrolom napadača u odgovor žrtvi.

Desinhronizacija HTTP Pipeline-a

HTTP/1.1 omogućava da se zahtevaju različiti resursi bez čekanja na prethodne. Dakle, ako postoji proxy na sredini, zadatak proxy-ja je da održava sinhronizovanu vezu između zahteva poslatih backend-u i odgovora koji dolaze od njega.

Međutim, postoji problem desinhronizacije reda odgovora. Ako napadač pošalje napad HTTP Response smuggling-a i odgovori na početni zahtev i prokrijumčareni zahtev budu odgovoreni odmah, prokrijumčareni odgovor neće biti ubačen u red odgovora žrtve, već će biti odbačen kao greška.

Zato je potrebno da prokrijumčareni zahtev traje duže vreme da bi bio obrađen na backend serveru. Dakle, do trenutka kada se prokrijumčareni zahtev obradi, komunikacija sa napadačem će biti završena.

Ako u ovoj specifičnoj situaciji žrtva pošalje zahtev i prokrijumčareni zahtev bude odgovoren pre legitimnog zahteva, prokrijumčareni odgovor će biti poslat žrtvi. Dakle, napadač će kontrolisati zahtev "izvršen" od strane žrtve.

Osim toga, ako napadač zatim izvrši zahtev i legitimni odgovor na zahtev žrtve bude odgovoren pre napadačevog zahteva. Odgovor na žrtvu će biti poslat napadaču, ukraden odgovor žrtvi (koji može sadržati na primer zaglavlje Set-Cookie).

Višestruke ugnježdene injekcije

Još jedna interesantna razlika u odnosu na uobičajeni HTTP Request Smuggling je ta što, kod uobičajenog smuggling napada, cilj je izmeniti početak zahteva žrtve kako bi izvršila neočekivanu radnju. Kod HTTP Response smuggling napada, pošto šaljete potpune zahteve, možete ubaciti u jedan payload desetine odgovora koji će desinhronizovati desetine korisnika koji će primiti ubacene odgovore.

Osim što možete lakše distribuirati desetine eksploatacija među legitimnim korisnicima, ovo takođe može biti korišćeno za izazivanje DoS napada na server.

Organizacija eksploatacije

Kao što je objašnjeno ranije, da biste zloupotrebili ovu tehniku, potrebno je da prva prokrijumčarena poruka u serveru zahteva dosta vremena za obradu.

Ovaj zahtev koji troši vreme je dovoljan ako samo želimo da pokušamo ukrasti odgovor žrtve. Ali ako želite da izvršite složeniju eksploataciju, ovo će biti uobičajena struktura za eksploataciju.

Prvo početni zahtev koji zloupotrebljava HTTP Request smuggling, zatim zahtev koji troši vreme, a zatim 1 ili više zahteva sa payload-om čiji će odgovori biti poslati žrtvama.

Zloupotreba desinhronizacije reda HTTP odgovora

Snimanje zahteva drugih korisnika

Kao i sa poznatim payload-ima za HTTP Request Smuggling, možete ukrasti zahtev žrtve sa jednom važnom razlikom: U ovom slučaju vam je potrebno samo poslati sadržaj koji će se odraziti u odgovoru, nije potrebno trajno skladištenje.

Prvo, napadač šalje payload koji sadrži završni POST zahtev sa odraženim parametrom na kraju i velikom Content-Length vrednošću

Zatim, jednom kada je početni zahtev (plavi) obrađen, a dok se zahtev koji troši vreme (žuti) obrađuje, sledeći zahtev koji stigne od žrtve će biti dodat u red odmah nakon odraženog parametra:

Zatim, žrtva će primiti odgovor na zahtev koji troši vreme, i ako u međuvremenu napadač pošalje još jedan zahtev, **odgovor na zahtev sa

Konfuzija sadržaja

Sledeći prethodni primer, znajući da možete kontrolisati telo zahteva čiji će odgovor primiti žrtva i da HEAD odgovor obično sadrži u zaglavljima Content-Type i Content-Length, možete poslati zahtev kao što je sledeći da izazovete XSS u žrtvi, čak i ako stranica nije ranjiva na XSS:

Trovanje keša

Zloupotrebom prethodno komentarisane napadačke desinhronizacije odgovora, ako keš čuva odgovor na zahtev koji je izvršila žrtva, a taj odgovor je ubačen i izaziva XSS, tada je keš otrovan.

Zlonamerni zahtev koji sadrži XSS payload:

Zlonamerni odgovor žrtvi koji sadrži zaglavlje koje ukazuje kešu da sačuva odgovor:

{% hint style="warning" %} Imajte na umu da u ovom slučaju, ako je "žrtva" napadač, sada može izvršiti trovanje keša na proizvoljnim URL-ovima, jer može kontrolisati URL koji će biti keširan sa zlonamernim odgovorom. {% endhint %}

Prevara veb keša

Ovaj napad je sličan prethodnom, ali umesto ubacivanja payloada u keš, napadač će keširati informacije žrtve unutar keša:

Podela odgovora

Cilj ovog napada je ponovo zloupotreba desinhronizacije odgovora kako bi se naterao proxy da pošalje odgovor koji je 100% generisan od strane napadača.

Da bi to postigao, napadač mora pronaći krajnju tačku veb aplikacije koja reflektuje neke vrednosti unutar odgovora i znati dužinu sadržaja HEAD odgovora.

Poslaće eksploataciju kao što je:

Nakon što se prvi zahtev reši i pošalje nazad napadaču, zahtev žrtve se dodaje u red:

Žrtva će kao odgovor primiti HEAD odgovor + sadržaj odgovora drugog zahteva (koji sadrži deo reflektovanih podataka):

Međutim, obratite pažnju kako su reflektovani podaci imali veličinu u skladu sa Content-Length odgovora HEAD koji je generisao validan HTTP odgovor u redu odgovora.

Stoga, naredni zahtev drugog žrtve će primiti kao odgovor nešto potpuno kreirano od strane napadača. Pošto je odgovor potpuno kreiran od strane napadača, on takođe može keširati odgovor proxy servera.

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

• Ako želite da vidite oglašavanje vaše kompanije u HackTricks-u ili preuzmete HackTricks u PDF formatu, proverite SUBSCRIPTION PLANS!
• Nabavite zvanični PEASS & HackTricks swag
• Otkrijte The PEASS Family, našu kolekciju ekskluzivnih NFT-ova
• Pridružite se 💬 Discord grupi ili telegram grupi ili nas pratite na Twitter-u 🐦 @carlospolopm.
• Podelite svoje hakovanje trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.