HTTP Request Smuggling / HTTP Desync Attack
Last updated
Last updated
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ova ranjivost se javlja kada desinkronizacija između frontalnih proksija i pozadinskog servera omogućava napadaču da pošalje HTTP zahtev koji će biti tumačen kao jedan zahtev od strane frontalnih proksija (load balance/reverse-proxy) i kao 2 zahteva od strane pozadinskog servera. To omogućava korisniku da modifikuje sledeći zahtev koji stigne do pozadinskog servera nakon njegovog.
Ako je poruka primljena sa oba, Transfer-Encoding header polje i Content-Length header polje, potonje MORA biti ignorisano.
Content-Length
Content-Length entitetski header označava veličinu entitetskog tela, u bajtovima, poslatog primaocu.
Transfer-Encoding: chunked
Transfer-Encoding header specificira oblik kodiranja koji se koristi za sigurno prenošenje sadržaja korisniku. Chunked znači da se veliki podaci šalju u seriji delova.
Frontalni (load-balance / Reverse Proxy) obrađuje content-length ili transfer-encoding header, a pozadinski server obrađuje drugi izazivajući desinkronizaciju između 2 sistema. To može biti veoma kritično jer napadač može poslati jedan zahtev na reverse proxy koji će biti tumačen od strane pozadinskog servera kao 2 različita zahteva. Opasnost ove tehnike leži u činjenici da će pozadinski server tumačiti 2. zahtev koji je ubačen kao da je došao od sledećeg klijenta i pravi zahtev tog klijenta će biti deo ubačenog zahteva.
Zapamtite da u HTTP novi red karakter se sastoji od 2 bajta:
Content-Length: Ovaj header koristi decimalni broj da označi broj bajtova tela zahteva. Očekuje se da telo završi u poslednjem karakteru, novi red nije potreban na kraju zahteva.
Transfer-Encoding: Ovaj header koristi u telu heksadecimalni broj da označi broj bajtova sledećeg dela. Deo mora završiti sa novim redom, ali ovaj novi red se ne računa od strane indikatora dužine. Ova metoda prenosa mora završiti sa delom veličine 0 praćenim sa 2 nova reda: 0
Connection: Na osnovu mog iskustva, preporučuje se korišćenje Connection: keep-alive na prvom zahtevu u request Smuggling.
Kada pokušavate da iskoristite ovo sa Burp Suite onemogućite Update Content-Length i Normalize HTTP/1 line endings u repeater-u jer neki gadgeti zloupotrebljavaju nove redove, povratne znakove i neispravne content-length vrednosti.
HTTP request smuggling napadi se kreiraju slanjem nejasnih zahteva koji koriste razlike u tome kako frontalni i pozadinski serveri tumače Content-Length (CL) i Transfer-Encoding (TE) heder. Ovi napadi se mogu manifestovati u različitim oblicima, prvenstveno kao CL.TE, TE.CL, i TE.TE. Svaka vrsta predstavlja jedinstvenu kombinaciju načina na koji frontalni i pozadinski serveri prioritetizuju ove hedere. Ranjivosti nastaju kada serveri obrađuju isti zahtev na različite načine, što dovodi do neočekivanih i potencijalno zlonamernih ishoda.
U prethodnu tabelu treba dodati TE.0 tehniku, kao CL.0 tehniku, ali koristeći Transfer Encoding.
Frontalni (CL): Obradjuje zahtev na osnovu Content-Length hedera.
Pozadinski (TE): Obradjuje zahtev na osnovu Transfer-Encoding hedera.
Scenarijo napada:
Napadač šalje zahtev gde vrednost Content-Length hedera ne odgovara stvarnoj dužini sadržaja.
Frontalni server prosleđuje ceo zahtev pozadinskom, na osnovu Content-Length vrednosti.
Pozadinski server obrađuje zahtev kao chunked zbog Transfer-Encoding: chunked hedera, tumačeći preostale podatke kao odvojen, sledeći zahtev.
Primer:
Frontalni (TE): Obradjuje zahtev na osnovu Transfer-Encoding hedera.
Pozadinski (CL): Obradjuje zahtev na osnovu Content-Length hedera.
Scenarijo napada:
Napadač šalje chunked zahtev gde veličina dela (7b) i stvarna dužina sadržaja (Content-Length: 4) ne odgovaraju.
Frontalni server, poštujući Transfer-Encoding, prosleđuje ceo zahtev pozadinskom.
Pozadinski server, poštujući Content-Length, obrađuje samo početni deo zahteva (7b bajtova), ostavljajući ostatak kao deo neplaniranog sledećeg zahteva.
Primer:
Serveri: Obe podržavaju Transfer-Encoding, ali jedan može biti prevaren da ga ignoriše putem obfuscation.
Scenarijo napada:
Napadač šalje zahtev sa obfuskovanim Transfer-Encoding hederima.
U zavisnosti od toga koji server (frontalni ili pozadinski) ne prepozna obfuscation, može se iskoristiti CL.TE ili TE.CL ranjivost.
Neobrađeni deo zahteva, kako ga vidi jedan od servera, postaje deo sledećeg zahteva, što dovodi do smuggling-a.
Primer:
Obe servera obrađuju zahtev isključivo na osnovu Content-Length hedera.
Ovaj scenario obično ne dovodi do smuggling-a, jer postoji usklađenost u tome kako oba servera tumače dužinu zahteva.
Primer:
Odnosi se na scenarije gde je Content-Length header prisutan i ima vrednost različitu od nule, što ukazuje da telo zahteva ima sadržaj. Pozadinski ignoriše Content-Length header (koji se tretira kao 0), ali frontalni ga analizira.
Ključno je za razumevanje i kreiranje smuggling napada, jer utiče na to kako serveri određuju kraj zahteva.
Primer:
Kao prethodni, ali koristeći TE.
Tehnika prijavljena ovde
Primer:
Ova tehnika je takođe korisna u scenarijima gde je moguće rušiti web server dok se čitaju inicijalni HTTP podaci ali bez zatvaranja veze. Na ovaj način, telo HTTP zahteva će se smatrati sledećim HTTP zahtevom.
Na primer, kao što je objašnjeno u ovoj analizi, u Werkzeug-u je bilo moguće poslati neke Unicode karaktere i to će uzrokovati rušenje servera. Međutim, ako je HTTP veza kreirana sa zaglavljem Connection: keep-alive, telo zahteva neće biti pročitano i veza će i dalje biti otvorena, tako da će se telo zahteva tretirati kao sledeći HTTP zahtev.
Zloupotrebom hop-by-hop zaglavlja možete naznačiti proxy-ju da izbaci zaglavlje Content-Length ili Transfer-Encoding kako bi se HTTP request smuggling mogao zloupotrebiti.
For više informacija o hop-by-hop header-ima posetite:
hop-by-hop headersIdentifikacija ranjivosti HTTP request smuggling često se može postići korišćenjem tehnika merenja vremena, koje se oslanjaju na posmatranje koliko dugo serveru treba da odgovori na manipulirane zahteve. Ove tehnike su posebno korisne za otkrivanje CL.TE i TE.CL ranjivosti. Pored ovih metoda, postoje i druge strategije i alati koji se mogu koristiti za pronalaženje takvih ranjivosti:
Metod:
Pošaljite zahtev koji, ako je aplikacija ranjiva, će uzrokovati da back-end server čeka na dodatne podatke.
Primer:
Posmatranje:
Front-end server obrađuje zahtev na osnovu Content-Length i prekida poruku prerano.
Back-end server, očekujući chunked poruku, čeka na sledeći chunk koji nikada ne dolazi, uzrokujući kašnjenje.
Indikatori:
Timeout-ovi ili duga kašnjenja u odgovoru.
Primanje 400 Bad Request greške od back-end servera, ponekad sa detaljnim informacijama o serveru.
Metod:
Pošaljite zahtev koji, ako je aplikacija ranjiva, će uzrokovati da back-end server čeka na dodatne podatke.
Primer:
Posmatranje:
Front-end server obrađuje zahtev na osnovu Transfer-Encoding i prosleđuje celu poruku.
Back-end server, očekujući poruku na osnovu Content-Length, čeka na dodatne podatke koji nikada ne dolaze, uzrokujući kašnjenje.
Analiza Diferencijalnog Odgovora:
Pošaljite blago izmenjene verzije zahteva i posmatrajte da li se odgovori servera razlikuju na neočekivan način, što ukazuje na grešku u parsiranju.
Korišćenje Automatizovanih Alata:
Alati poput Burp Suite-ove 'HTTP Request Smuggler' ekstenzije mogu automatski testirati ove ranjivosti slanjem različitih oblika nejasnih zahteva i analizom odgovora.
Testovi Varijacije Content-Length:
Pošaljite zahteve sa različitim Content-Length vrednostima koje nisu usklađene sa stvarnom dužinom sadržaja i posmatrajte kako server reaguje na takve neslaganja.
Testovi Varijacije Transfer-Encoding:
Pošaljite zahteve sa obfuskovanim ili neispravnim Transfer-Encoding header-ima i pratite kako se front-end i back-end serveri različito ponašaju na takve manipulacije.
Nakon potvrđivanja efikasnosti tehnika merenja vremena, ključno je proveriti da li se klijentski zahtevi mogu manipulirati. Jednostavna metoda je pokušaj trovanja vaših zahteva, na primer, da zahtev za / vrati 404 odgovor. Primeri CL.TE i TE.CL prethodno raspravljani u Osnovnim Primerima pokazuju kako otrovati klijentov zahtev da izazove 404 odgovor, uprkos tome što klijent pokušava da pristupi drugom resursu.
Ključne Napomene
Kada testirate ranjivosti request smuggling-a ometajući druge zahteve, imajte na umu:
Različite Mrežne Konekcije: "Napad" i "normalni" zahtevi treba da budu poslati preko odvojenih mrežnih konekcija. Korišćenje iste konekcije za oba ne potvrđuje prisustvo ranjivosti.
Dosledni URL i Parametri: Ciljajte da koristite identične URL-ove i imena parametara za oba zahteva. Moderne aplikacije često usmeravaju zahteve ka specifičnim back-end serverima na osnovu URL-a i parametara. Usklađivanje ovih povećava verovatnoću da oba zahteva obrađuje isti server, što je preduslov za uspešan napad.
Vreme i Uslovi Trke: "Normalni" zahtev, koji je namenjen otkrivanju ometanja od "napadnog" zahteva, takmiči se protiv drugih istovremenih zahteva aplikacije. Stoga, pošaljite "normalni" zahtev odmah nakon "napadnog" zahteva. Zauzete aplikacije mogu zahtevati više pokušaja za konačnu potvrdu ranjivosti.
Izazovi Balansiranja Opterećenja: Front-end serveri koji deluju kao balansatori opterećenja mogu raspodeliti zahteve preko različitih back-end sistema. Ako "napadni" i "normalni" zahtevi završe na različitim sistemima, napad neće uspeti. Ovaj aspekt balansiranja opterećenja može zahtevati nekoliko pokušaja za potvrdu ranjivosti.
Nepredviđeni Uticaj na Korisnike: Ako vaš napad nenamerno utiče na zahtev drugog korisnika (ne "normalni" zahtev koji ste poslali za detekciju), to ukazuje da je vaš napad uticao na drugog korisnika aplikacije. Kontinuirano testiranje može ometati druge korisnike, što zahteva oprezan pristup.
Ponekad, front-end proksi primenjuju bezbednosne mere, preispitujući dolazne zahteve. Međutim, ove mere se mogu zaobići iskorišćavanjem HTTP Request Smuggling, omogućavajući neovlašćen pristup ograničenim krajnjim tačkama. Na primer, pristup /admin može biti zabranjen spolja, pri čemu front-end proksi aktivno blokira takve pokušaje. Ipak, ovaj proksi može zanemariti ugradnje zahteva unutar prokrijumčarenog HTTP zahteva, ostavljajući rupu za zaobilaženje ovih ograničenja.
Razmotrite sledeće primere koji ilustruju kako se HTTP Request Smuggling može koristiti za zaobilaženje front-end bezbednosnih kontrola, posebno ciljajući /admin putanju koja je obično zaštićena front-end proksijem:
CL.TE Primer
U CL.TE napadu, Content-Length zaglavlje se koristi za inicijalni zahtev, dok sledeći ugnježdeni zahtev koristi Transfer-Encoding: chunked zaglavlje. Frontalni proxy obrađuje inicijalni POST zahtev, ali ne uspeva da ispita ugnježdeni GET /admin zahtev, omogućavajući neovlašćen pristup /admin putanji.
TE.CL Primer
S druge strane, u TE.CL napadu, inicijalni POST zahtev koristi Transfer-Encoding: chunked, a sledeći ugnježdeni zahtev se obrađuje na osnovu Content-Length zaglavlja. Slično CL.TE napadu, front-end proxy zanemaruje ugnježdeni GET /admin zahtev, nenamerno omogućavajući pristup ograničenom /admin putu.
Aplikacije često koriste front-end server za modifikaciju dolaznih zahteva pre nego što ih proslede back-end serveru. Tipična modifikacija uključuje dodavanje zaglavlja, kao što je X-Forwarded-For: <IP klijenta>, kako bi se prenela IP adresa klijenta na back-end. Razumevanje ovih modifikacija može biti ključno, jer može otkriti načine za obići zaštite ili otkriti skrivene informacije ili krajnje tačke.
Da biste istražili kako proxy menja zahtev, pronađite POST parametar koji back-end ponavlja u odgovoru. Zatim, kreirajte zahtev, koristeći ovaj parametar kao poslednji, slično sledećem:
U ovoj strukturi, sledeći delovi zahteva se dodaju nakon search=, što je parametar koji se odražava u odgovoru. Ova refleksija će otkriti zaglavlja sledećeg zahteva.
Važno je uskladiti Content-Length zaglavlje ugnježdenog zahteva sa stvarnom dužinom sadržaja. Preporučuje se da se počne sa malom vrednošću i postepeno povećava, jer će previše niska vrednost skratiti odražene podatke, dok previše visoka vrednost može izazvati grešku u zahtevu.
Ova tehnika se takođe može primeniti u kontekstu TE.CL ranjivosti, ali zahtev treba da se završi sa search=\r\n0. Bez obzira na karaktere novog reda, vrednosti će se dodati parametru pretrage.
Ova metoda prvenstveno služi za razumevanje izmena zahteva koje vrši front-end proxy, suštinski obavljajući samostalnu istragu.
Moguće je uhvatiti zahteve sledećeg korisnika dodavanjem specifičnog zahteva kao vrednosti parametra tokom POST operacije. Evo kako se to može postići:
Dodavanjem sledećeg zahteva kao vrednosti parametra, možete sačuvati zahtev sledećeg klijenta:
U ovom scenariju, parametar komentara je namenjen za čuvanje sadržaja unutar sekcije komentara posta na javno dostupnoj stranici. Kao rezultat, sadržaj narednog zahteva će se pojaviti kao komentar.
Međutim, ova tehnika ima ograničenja. Generalno, hvata podatke samo do delimičnog razdvajanja parametara korišćenog u prokrijumčarenom zahtevu. Za URL-enkodirane forme, ovaj razdvojnik je karakter &. To znači da će uhvaćeni sadržaj iz zahteva žrtve prestati na prvom &, koji može biti deo upitnog niza.
Pored toga, vredi napomenuti da je ovaj pristup takođe izvodljiv sa TE.CL ranjivošću. U takvim slučajevima, zahtev bi trebao da se završi sa search=\r\n0. Bez obzira na karaktere novog reda, vrednosti će biti dodate parametru pretrage.
HTTP Request Smuggling se može iskoristiti za iskorišćavanje web stranica ranjivih na Reflektovani XSS, nudeći značajne prednosti:
Interakcija sa ciljnim korisnicima nije potrebna.
Omogućava iskorišćavanje XSS u delovima zahteva koji su normalno nedostupni, poput HTTP zaglavlja zahteva.
U scenarijima gde je veb sajt podložan Reflektovanom XSS putem User-Agent zaglavlja, sledeći payload prikazuje kako iskoristiti ovu ranjivost:
Ovaj payload je strukturiran da iskoristi ranjivost na sledeći način:
Inicira POST zahtev, naizgled tipičan, sa Transfer-Encoding: chunked header-om da označi početak šverca.
Nakon toga sledi 0, što označava kraj chunked poruke.
Zatim se uvodi švercovani GET zahtev, gde je User-Agent header zaražen skriptom, <script>alert(1)</script>, što pokreće XSS kada server obradi ovaj sledeći zahtev.
Manipulacijom User-Agent kroz šverc, payload zaobilazi normalna ograničenja zahteva, čime se iskorišćava Reflected XSS ranjivost na nestandardan, ali efikasan način.
U slučaju da se sadržaj korisnika odražava u odgovoru sa Content-type kao što je text/plain, sprečavajući izvršenje XSS. Ako server podržava HTTP/0.9, možda će biti moguće zaobići ovo!
Verzija HTTP/0.9 je prethodila 1.0 i koristi samo GET glagole i ne odgovara sa header-ima, samo telom.
U ovoj analizi, ovo je zloupotrebljeno sa švercom zahteva i ranjivim krajnjim tačkom koja će odgovoriti sa unosom korisnika da švercuje zahtev sa HTTP/0.9. Parametar koji će biti odražen u odgovoru sadržavao je lažni HTTP/1.1 odgovor (sa header-ima i telom) tako da će odgovor sadržati validan izvršni JS kod sa Content-Type od text/html.
Aplikacije često preusmeravaju sa jednog URL-a na drugi koristeći ime hosta iz Host header-a u URL-u preusmeravanja. Ovo je uobičajeno sa web serverima kao što su Apache i IIS. Na primer, zahtev za folder bez završnog kosa rezultira preusmeravanjem da uključi kosu:
Rezultati u:
Iako naizgled bezopasno, ovo ponašanje se može iskoristiti pomoću HTTP request smuggling-a za preusmeravanje korisnika na spoljašnju stranicu. Na primer:
Ova prokrijumčarena zahtev može uzrokovati da sledeći obrađeni korisnički zahtev bude preusmeren na veb sajt pod kontrolom napadača:
Rezultati u:
U ovom scenariju, korisnički zahtev za JavaScript datotekom je preuzet. Napadač može potencijalno kompromitovati korisnika tako što će poslužiti zlonamerni JavaScript kao odgovor.
Trovanje web kešom može se izvršiti ako bilo koja komponenta infrastrukture front-end kešira sadržaj, obično radi poboljšanja performansi. Manipulacijom serverovog odgovora, moguće je otrovati keš.
Prethodno smo posmatrali kako se serverovi odgovori mogu izmeniti da vrate 404 grešku (pogledajte Osnovni primeri). Slično tome, moguće je prevariti server da isporuči sadržaj /index.html kao odgovor na zahtev za /static/include.js. Kao rezultat, sadržaj /static/include.js se zamenjuje u kešu sa onim od /index.html, čineći /static/include.js nedostupnim korisnicima, što potencijalno može dovesti do Denial of Service (DoS).
Ova tehnika postaje posebno moćna ako se otkrije ranjivost Open Redirect ili ako postoji preusmeravanje na sajtu ka otvorenom preusmeravanju. Takve ranjivosti se mogu iskoristiti za zamenu keširanog sadržaja /static/include.js sa skriptom pod kontrolom napadača, što suštinski omogućava široku Cross-Site Scripting (XSS) napad protiv svih klijenata koji zahtevaju ažurirani /static/include.js.
Ispod je ilustracija iskorišćavanja trovanja keša u kombinaciji sa preusmeravanjem na sajtu ka otvorenom preusmeravanju. Cilj je izmeniti keš sadržaj /static/include.js da poslužuje JavaScript kod pod kontrolom napadača:
Napomena o ugrađenom zahtevu koji cilja /post/next?postId=3. Ovaj zahtev će biti preusmeren na /post?postId=4, koristeći Host header value za određivanje domena. Menjanjem Host header-a, napadač može preusmeriti zahtev na svoj domen (on-site redirect to open redirect).
Nakon uspešnog socket poisoning-a, treba inicirati GET request za /static/include.js. Ovaj zahtev će biti kontaminiran prethodnim on-site redirect to open redirect zahtevom i preuzeti sadržaj skripte koju kontroliše napadač.
Nakon toga, svaki zahtev za /static/include.js će služiti keširani sadržaj napadačeve skripte, efikasno pokrećući širok XSS napad.
Koja je razlika između web cache poisoning-a i web cache deception-a?
U web cache poisoning-u, napadač uzrokuje da aplikacija sačuva neki zlonamerni sadržaj u kešu, a ovaj sadržaj se servira iz keša drugim korisnicima aplikacije.
U web cache deception-u, napadač uzrokuje da aplikacija sačuva neki osetljiv sadržaj koji pripada drugom korisniku u kešu, a napadač zatim preuzima ovaj sadržaj iz keša.
Napadač kreira smuggled zahtev koji preuzima osetljiv sadržaj specifičan za korisnika. Razmotrite sledeći primer:
Ako ovaj smugglovani zahtev otrova keš unos namenjen za statički sadržaj (npr., /someimage.png), osetljivi podaci žrtve sa /private/messages mogli bi biti keširani pod unosom keša statičkog sadržaja. Kao rezultat, napadač bi potencijalno mogao da povrati ove keširane osetljive podatke.
U ovom postu se sugeriše da, ako server ima omogućenu metodu TRACE, može biti moguće zloupotrebiti je putem HTTP Request Smuggling. To je zato što će ova metoda reflektovati bilo koji header poslat serveru kao deo tela odgovora. Na primer:
Će poslati odgovor kao što je:
Primer kako iskoristiti ovo ponašanje bio bi da se prokrijumčari prvo HEAD zahtev. Ovaj zahtev će biti odgovoreno samo sa zaglavljima GET zahteva (Content-Type među njima). I prokrijumčariti odmah nakon HEAD TRACE zahtev, koji će odražavati poslati podaci.
Pošto će HEAD odgovor sadržati Content-Length zaglavlje, odgovor TRACE zahteva će biti tretiran kao telo HEAD odgovora, što će stoga odražavati proizvoljne podatke u odgovoru.
Ovaj odgovor će biti poslat sledećem zahtevu preko veze, tako da bi ovo moglo biti iskorišćeno u keširanom JS fajlu na primer da se ubaci proizvoljan JS kod.
Nastavite da pratite ovaj post koji sugeriše još jedan način da se iskoristi TRACE metoda. Kao što je komentarisano, prokrijumčariti HEAD zahtev i TRACE zahtev je moguće kontrolisati neke odražene podatke u odgovoru na HEAD zahtev. Dužina tela HEAD zahteva je u suštini naznačena u Content-Length zaglavlju i formira se odgovorom na TRACE zahtev.
Stoga, nova ideja bi bila da, znajući ovo Content-Length i podatke date u TRACE odgovoru, moguće je učiniti da TRACE odgovor sadrži validan HTTP odgovor nakon poslednjeg bajta Content-Length, omogućavajući napadaču da potpuno kontroliše zahtev za sledeći odgovor (što bi moglo biti iskorišćeno za izvođenje trovanja keša).
Primer:
Generisaće ove odgovore (obratite pažnju na to kako HEAD odgovor ima Content-Length, što čini da TRACE odgovor bude deo HEAD tela, a kada se završi HEAD Content-Length, validan HTTP odgovor se švercuje):
Da li ste pronašli neku HTTP Request Smuggling ranjivost i ne znate kako da je iskoristite. Pokušajte ove druge metode eksploatacije:
HTTP Response Smuggling / DesyncBrowser HTTP Request Smuggling (Client Side)
Request Smuggling in HTTP/2 Downgrades
Sa https://hipotermia.pw/bb/http-desync-idor
From: https://hipotermia.pw/bb/http-desync-account-takeover
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: Ovaj alat je HTTP Fuzzer zasnovan na gramatici koji je koristan za pronalaženje čudnih razlika u request smuggling-u.
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
