HTTP Response Smuggling / Desync
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 zahteva za smugling, tako da morate znati šta je to:
Glavna razlika između ove tehnike i običnog HTTP zahteva za smugling je što umesto napadanja zahteva žrtve dodavanjem prefiksa, mi ćemo procuriti ili modifikovati odgovor koji žrtva prima. Ovo se postiže tako što, umesto slanja 1 zahteva i pola za zloupotrebu HTTP zahteva za smugling, šaljemo 2 potpuna zahteva za desinhronizaciju redova odgovora posrednika.
Ovo je zato što ćemo biti u mogućnosti da desinhronizujemo red odgovora tako da odgovor sa legitimnog zahteva žrtve bude poslat napadaču, ili ubacivanjem sadržaja kontrolisanog od strane napadača u odgovor žrtvi.
Desinhronizacija HTTP Pipelina
HTTP/1.1 omogućava da se zatraže različiti resursi bez čekanja na prethodne. Stoga, ako postoji posrednik u sredini, posao posrednika je da održava sinhronizovan odgovarajući par zahteva poslatih backendu i odgovora koji dolaze od njega.
Međutim, postoji problem desinhronizacije redova odgovora. Ako napadač pošalje napad za smugling HTTP odgovora i odgovori na početni zahtev i prokrijumčaren budu odgovoreni odmah, prokrijumčareni odgovor neće biti ubačen unutar reda odgovora žrtve već će biti odbačen kao greška.
Stoga je potrebno da prokrijumčareni zahtev traje duže da se obradi unutar serverske strane. Stoga, do trenutka kada se prokrijumčareni zahtev obradi, komunikacija sa napadačem će biti završena.
Ukoliko 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. Stoga, napadač će kontrolisati zahtev "izvršen" od strane žrtve.
Osim toga, ako napadač zatim izvrši zahtev i legitimni odgovor na žrtvin zahtev bude odgovoren pre napadačevog zahteva. Odgovor žrtvi će biti poslat napadaču, ukradući odgovor žrtvi (koji može sadržati na primer zaglavlje Set-Cookie).
Višestruke Ugnježdene Injekcije
Još jedna interesantna razlika sa običnim HTTP zahtevom za smugling je da, u običnom napadu za smugling, cilj je modifikovati početak zahteva žrtve tako da izvrši neočekivanu akciju. U napadu za smuglingu HTTP odgovora, pošto šaljete kompletne zahteve, možete ubaciti u jedan payload desetine odgovora koji će desinhronizovati desetine korisnika koji će primiti ubacene odgovore.
Osim što možete jednostavnije distribuirati desetine eksploatacija među legitimnim korisnicima, ovo takođe može biti korišćeno za izazivanje DoS na serveru.
Organizacija Eksploatacije
Kao što je objašnjeno ranije, da biste zloupotrebili ovu tehniku, potrebno je da prva prokrijumčarena poruka u serveru traje dugo da se obradi.
Ovaj zahtev koji traje dugo je dovoljan ako želimo samo da pokušamo ukrasti odgovor žrtve. Ali ako želite izvršiti složeniju eksploataciju, ovo će biti zajednička struktura za eksploataciju.
Prvo početni zahtev zloupotrebljavajući HTTP zahtev za smugling, zatim zahtev koji traje dugo i zatim 1 ili više zahteva za payload čiji će odgovori biti poslati žrtvama.
Zloupotreba Desinhronizacije Reda HTTP Odgovora
Hvatanje zahteva drugih korisnika
Kao i sa poznatim payloadima za HTTP zahtev za smugling, možete ukrasti zahtev žrtve sa jednom važnom razlikom: U ovom slučaju vam je potrebno samo da poslati sadržaj bude reflektovan u odgovoru, nije potrebno trajno skladištenje.
Prvo, napadač šalje payload koji sadrži završni POST zahtev sa reflektovanim parametrom na kraju i velikim Content-Length
Zatim, kada je početni zahtev (plavi) obradjen i dok se spori zahtev obrađuje (žuti) sledeći zahtev koji stiže od žrtve će biti dodat u red odmah posle reflektovanog parametra:
Zatim, žrtva će primiti odgovor na spor zahtev i ako u međuvremenu napadač pošalje još jedan zahtev, odgovor na zahtev sa reflektovanim sadržajem će biti poslat njemu.
Desinhronizacija Odgovora
Do ovog trenutka, naučili smo kako zloupotrebiti napade HTTP zahteva za smugling da kontrolišemo zahtev čiji odgovor klijent treba da primi i kako možete zatim ukrasti odgovor koji je bio namenjen žrtvi.
Ali još uvek je moguće desinhronizovati još više odgovora.
Postoje interesantni zahtevi poput HEAD zahteva koji su specifični da nemaju bilo kakav sadržaj unutar tela odgovora i koji bi (mora) sadržati Content-Length zahteva kao da je to GET zahtev.
Stoga, ako napadač ubaci HEAD zahtev, kao na ovim slikama:
Onda, kada plavi bude odgovoren napadaču, sledeći zahtev žrtve će biti ubačen u red:
Zatim, žrtva će primiti odgovor na HEAD zahtev, koji će sadržati Content-Length ali nikakav sadržaj. Stoga, posrednik neće poslati ovaj odgovor žrtvi, već će čekati na neki sadržaj, koji će zapravo biti odgovor na žuti zahtev (takođe ubačen od strane napadača):
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 biste izazvali XSS u žrtvi, a da stranica nije ranjiva na XSS:
Trovanje keša
Zloupotrebom prethodno komentisanog napada na konfuziju sadržaja odgovora desinhronizacije, ako keš čuva odgovor na zahtev koji je izvršila žrtva i ovaj odgovor je ubačen koji izaziva XSS, tada je keš zaražen.
Zlonamerni zahtev koji sadrži XSS payload:
Zlonamerni odgovor žrtvi koji sadrži zaglavlje koje ukazuje kešu da sačuva odgovor:
Imajte na umu da u ovom slučaju ako je "žrtva" napadač on može sada izvršiti trovanje keša na proizvoljnim URL-ovima jer može kontrolisati URL koji će biti keširan sa zlonamernim odgovorom.
Prevara keša veb stranica
Ovaj napad je sličan prethodnom, ali umesto ubacivanja payloada unutar keša, 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% generisao napadač.
Da bi postigao ovo, 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:
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, primetite kako je reflektovani podatak imao 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 naterati proxy da kešira odgovor.
Last updated
