HTTP Response Smuggling / Desync
Tehnika ovog posta je preuzeta iz videa: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
HTTP Request Queue Desynchronisation
Prvo, ova tehnika zloupotrebljava HTTP Request Smuggling ranjivost, tako da treba da znate šta je to:
Glavna razlika između ove tehnike i uobičajenog HTTP Request smuggling-a je to što umesto da napadamo zahtev žrtve dodavanjem prefiksa, mi ćemo ukrasti ili izmeniti odgovor koji žrtva prima. To se postiže tako što, umesto da pošaljemo 1 zahtev i po da zloupotrebimo HTTP Request smuggling, pošaljemo 2 potpuna zahteva da desinkronizujemo redosled odgovora proksija.
To je zato što ćemo moći da desinkronizujemo redosled odgovora tako da odgovor iz legitimnog zahteva žrtve bude poslat napadaču, ili tako što ćemo ubaciti sadržaj pod kontrolom napadača u odgovor žrtvi.
HTTP Pipeline Desync
HTTP/1.1 omogućava da se traže različiti resursi bez potrebe da se čeka na prethodne. Stoga, ako postoji proksi u sredini, zadatak proksija je da održi sinhronizovanu podudarnost zahteva poslatih ka backend-u i odgovora koji dolaze iz njega.
Međutim, postoji problem sa desinkronizacijom redosleda odgovora. Ako napadač pošalje HTTP Response smuggling napad i odgovori na početni zahtev i smugglovani zahtev budu odmah poslati, smugglovani odgovor neće biti umetnut u redosled odgovora žrtve, već će biti odbijen kao greška.
Stoga, potrebno je da smugglovani zahtev traje duže da bude obrađen unutar backend servera. Tako da, dok se smugglovani zahtev obrađuje, komunikacija sa napadačem će biti završena.
Ako u ovoj specifičnoj situaciji žrtva pošalje zahtev i smugglovani zahtev bude odgovoreno pre legitimnog zahteva, smugglovani odgovor će biti poslat žrtvi. Tako da će napadač kontrolisati zahtev "izvršen" od strane žrtve.
Štaviše, ako napadač zatim izvrši zahtev i legitimni odgovor na zahtev žrtve bude odgovoren pre napadačevog zahteva. Odgovor žrtvi će biti poslat napadaču, kradući odgovor žrtvi (koji može sadržati, na primer, zaglavlje Set-Cookie).
Multiple Nested Injections
Još jedna zanimljiva razlika sa uobičajenim HTTP Request Smuggling je to što, u uobičajenom smugglovanju, cilj je da se izmeni početak zahteva žrtve tako da izvrši neočekivanu akciju. U HTTP Response smuggling napadu, pošto šaljete pune zahteve, možete ubaciti u jedan payload desetine odgovora koji će desinkronizovati desetine korisnika koji će primati ubacene odgovore.
Pored toga što možete lakše distribuirati desetine eksploita među legitimnim korisnicima, ovo se takođe može koristiti za izazivanje DoS na serveru.
Exploit Organisation
Kao što je ranije objašnjeno, da biste zloupotrebili ovu tehniku, potrebno je da prva smugglovana poruka unutar servera zahteva puno vremena da bude obrađena.
Ovaj zahtev koji zahteva vreme je dovoljan ako samo želite da pokušate da ukradete odgovor žrtve. Ali ako želite da izvršite složeniji exploit, ovo će biti uobičajena struktura za exploit.
Prvo, početni zahtev koji zloupotrebljava HTTP Request smuggling, zatim zahtev koji zahteva vreme i zatim 1 ili više payload zahteva čiji će odgovori biti poslati žrtvama.
Abusing HTTP Response Queue Desynchronisation
Capturing other users' requests
Kao i sa poznatim payload-ima HTTP Request Smuggling-a, možete ukrasti zahtev žrtve sa jednom važnom razlikom: U ovom slučaju vam je samo potrebno da sadržaj bude reflektovan u odgovoru, nije potrebno trajno skladištenje.
Prvo, napadač šalje payload koji sadrži konačni POST zahtev sa reflektovanim parametrom na kraju i velikim Content-Length.
Zatim, kada je početni zahtev (plavi) bio obrađen i dok se spori obrađuje (žuti), sledeći zahtev koji dolazi od žrtve će biti dodato u redosled odmah nakon reflektovanog parametra:
Zatim, žrtva će primiti odgovor na spori zahtev i ako u međuvremenu napadač pošalje još jedan zahtev, odgovor iz zahteva reflektovanog sadržaja će biti poslat njemu.
Response Desynchronisation
Do ovog trenutka, naučili smo kako da zloupotrebimo HTTP Request Smuggling napade da kontrolišemo zahtev čiji odgovor će klijent primiti i kako možete zatim ukrasti odgovor koji je bio namenjen žrtvi.
Ali je još uvek moguće desinkronizovati još više odgovore.
Postoje zanimljivi zahtevi kao što je HEAD zahtev koji su specificirani da nemaju nikakav sadržaj unutar tela odgovora i koji bi trebali (moraju) sadržati Content-Length zahteva kao da je to GET zahtev.
Stoga, ako napadač ubaci HEAD zahtev, kao u ovim slikama:
Zatim, kada plavi zahtev bude odgovoreno napadaču, sledeći zahtev žrtve će biti uveden u redosled:
Zatim, žrtva će primiti odgovor iz HEAD zahteva, koji će sadržati Content-Length ali nikakav sadržaj. Stoga, proksi 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):
Content Confusion
Prateći prethodni primer, znajući da možete kontrolisati telo zahteva čiji odgovor će primiti žrtva i da HEAD odgovor obično sadrži u svojim zaglavljima Content-Type i Content-Length, možete poslati zahtev kao što je sledeći da uzrokujete XSS kod žrtve bez da stranica bude ranjiva na XSS:
Cache Poisoning
Zloupotrebljavajući prethodno komentarisani odgovor desinkronizacije Content Confusion napad, ako keš skladišti odgovor na zahtev izvršen od strane žrtve i ovaj odgovor je ubačen izazivajući XSS, tada je keš otrovan.
Maliciozni zahtev koji sadrži XSS payload:
Maliciozni odgovor žrtvi koji sadrži zaglavlje koje ukazuje kešu da skladišti odgovor:
Napomena da u ovom slučaju ako je "žrtva" napadač, on sada može izvršiti keš otrovanje na proizvoljnim URL-ovima jer može kontrolisati URL koji će biti keširan sa malicioznim odgovorom.
Web Cache Deception
Ovaj napad je sličan prethodnom, ali umesto da ubacuje payload unutar keša, napadač će keširati informacije o žrtvi unutar keša:
Response Splitting
Cilj ovog napada je ponovo zloupotreba odgovora desinkronizacije kako bi se proksi naterao da pošalje 100% napadačem generisan odgovor.
Da bi to postigao, napadač treba da pronađe krajnju tačku web aplikacije koja reflektuje neke vrednosti unutar odgovora i zna sadržaj dužine HEAD odgovora.
On će poslati eksploit kao:
Nakon što je prvi zahtev rešen i poslat nazad napadaču, zahtev žrtve se dodaje u redosled:
Žrtva će primiti kao odgovor HEAD odgovor + sadržaj odgovora drugog zahteva (sadrži deo reflektovanih podataka):
Međutim, obratite pažnju kako su reflektovani podaci imali veličinu prema Content-Length HEAD odgovora koji je generisao validan HTTP odgovor u redosledu odgovora.
Stoga, sledeći zahtev drugog žrtve će primiti kao odgovor nešto potpuno kreirano od strane napadača. Kako je odgovor potpuno kreiran od strane napadača, on takođe može naterati proksi da kešira odgovor.
Last updated
