Nadogradnja Smugglinga Zaglavlja

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 na 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.

Pronađite najvažnije ranjivosti kako biste ih brže popravili. Intruder prati vašu površinu napada, pokreće proaktivne pretnje, pronalazi probleme u celokupnom tehnološkom skupu, od API-ja do veb aplikacija i cloud sistema. Isprobajte ga besplatno danas.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

H2C Smuggling

HTTP2 preko čistog teksta (H2C)

H2C, ili http2 preko čistog teksta, odstupa od norme privremenih HTTP veza nadogradnjom standardne HTTP veze na trajnu vezu. Ova nadograđena veza koristi http2 binarni protokol za kontinuiranu komunikaciju, za razliku od jednokratne prirode plaintext HTTP-a.

Srž problema sa smugglingom nastaje sa korišćenjem obrnute proxy-je. Obično, obrnuta proxy obrađuje i prosleđuje HTTP zahteve ka backend-u, vraćajući odgovor backend-a nakon toga. Međutim, kada je zaglavlje Connection: Upgrade prisutno u HTTP zahtevu (često viđeno kod websocket veza), obrnuta proxy održava trajnu vezu između klijenta i servera, omogućavajući kontinuiranu razmenu potrebnu za određene protokole. Za H2C veze, poštovanje RFC-a zahteva prisustvo tri specifična zaglavlja:

Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings

Ranjivost se javlja kada, nakon nadogradnje veze, obrnuti proxy prestaje da upravlja pojedinačnim zahtevima, pretpostavljajući da je njegov posao rutiranja završen nakon uspostavljanja veze. Iskorišćavanje H2C Smugglinga omogućava zaobilaženje pravila obrnutog proxyja koja se primenjuju tokom obrade zahteva, kao što su rutiranje na osnovu putanje, autentifikacija i obrada WAF-a, pod uslovom da je H2C veza uspešno uspostavljena.

Ranjivi proxyji

Ranjivost zavisi od rukovanja proxyja obrnutim Upgrade i ponekad Connection zaglavljima. Sledeći proxyji inherentno prosleđuju ova zaglavlja tokom proxy-pass, čime inherentno omogućavaju H2C smuggling:

HAProxy
Traefik
Nuster

S druge strane, ovi servisi ne prosleđuju inherentno oba zaglavlja tokom proxy-pass. Međutim, mogu biti konfigurisani nesigurno, što omogućava nefiltrirano prosleđivanje zaglavlja Upgrade i Connection:

AWS ALB/CLB
NGINX
Apache
Squid
Varnish
Kong
Envoy
Apache Traffic Server

Iskorišćavanje

Važno je napomenuti da ne sve servere inherentno prosleđuju zaglavlja potrebna za usklađeno nadogradnju H2C veze. Zbog toga, serveri poput AWS ALB/CLB, NGINX i Apache Traffic Server, između ostalih, prirodno blokiraju H2C veze. Ipak, vredi testirati sa neusklađenom varijantom Connection: Upgrade, koja isključuje vrednost HTTP2-Settings iz zaglavlja Connection, jer neki backendovi možda ne poštuju standarde.

{% hint style="danger" %} Bez obzira na specifičnu putanju određenu u URL-u proxy_pass (npr. http://backend:9999/socket.io), uspostavljena veza podrazumeva podrazumevano http://backend:9999. To omogućava interakciju sa bilo kojom putanjom unutar tog internog krajnog tačke, koristeći ovu tehniku. Stoga, specificiranje putanje u URL-u proxy_pass ne ograničava pristup. {% endhint %}

Alati h2csmuggler od strane BishopFox-a i h2csmuggler od strane assetnote-a olakšavaju pokušaje zaobilaženja zaštite nametnute proxyjem uspostavljanjem H2C veze, čime se omogućava pristup resursima zaštićenim proxyjem.

Za dodatne informacije o ovoj ranjivosti, posebno u vezi sa NGINX-om, pogledajte ovaj detaljni resurs.

Websocket Smuggling

Websocket smuggling, za razliku od kreiranja HTTP2 tunela do endpointa koji je dostupan putem proxyja, uspostavlja Websocket tunel kako bi zaobišao potencijalna ograničenja proxyja i omogućio direktnu komunikaciju sa endpointom.

Scenario 1

U ovom scenariju, zlonamerni klijent cilja backend koji nudi javni WebSocket API zajedno sa nepristupačnim internim REST API-jem i želi pristupiti internom REST API-ju. Napad se odvija u nekoliko koraka:

Klijent započinje slanjem Upgrade zahteva obrnutom proxyju sa netačnom verzijom protokola Sec-WebSocket-Version u zaglavlju. Proxy, ne uspevajući da validira zaglavlje Sec-WebSocket-Version, veruje da je Upgrade zahtev validan i prosleđuje ga backendu.
Backend odgovara sa status kodom 426, koji ukazuje na netačnu verziju protokola u zaglavlju Sec-WebSocket-Version. Obrnuti proxy, ne primećujući statusni kod odgovora backenda, pretpostavlja da je spreman za WebSocket komunikaciju i prosleđuje odgovor klijentu.
Kao rezultat toga, obrnuti proxy je zaveden da veruje da je WebSocket veza uspostavljena između klijenta i backenda, dok je u stvarnosti backend odbio Upgrade zahtev. Bez obzira na to, proxy održava otvorenu TCP ili TLS vezu između klijenta i backenda, omogućavajući klijentu neograničen pristup privatnom REST API-ju putem ove veze.

Pogođeni obrnuti proxyji uključuju Varnish, koji nije želeo da se bavi ovim problemom, i Envoy proxy verziju 1.8.0 ili starije, pri čemu su kasnije verzije izmenile mehanizam nadogradnje. Ostali proxyji takođe mogu biti podložni.

Scenario 2

Ovaj scenario uključuje backend sa javnim WebSocket API-jem i javnim REST API-jem za proveru stanja, zajedno sa nepristupačnim internim REST API-jem. Napad, koji je složeniji, uključuje sledeće korake:

Klijent šalje POST zahtev za pokretanje API-ja za proveru stanja, uključujući dodatno HTTP zaglavlje Upgrade: websocket. NGINX, koji služi kao obrnuti proxy, tumači ovo kao standardni Upgrade zahtev samo na osnovu zaglavlja Upgrade, zanemarujući druge aspekte zahteva, i prosleđuje ga backendu.
Backend izvršava API za proveru stanja, pristupajući spoljnom resursu koji kontroliše napadač i koji vraća HTTP odgovor sa status kodom 101. Ovaj odgovor, kada ga backend primi i prosledi NGINX-u, vara proxy da misli da je WebSocket veza uspostavljena zbog njegove validacije samo statusnog koda.

Upozorenje: Složenost ove tehnike se povećava jer zahteva mogućnost interakcije sa endpointom koji može vratiti status kod 101.

Konačno, NGINX je prevaran da veruje da postoji WebSocket veza između klijenta i backenda. U stvarnosti, takva veza ne postoji; cilj je bio REST API za proveru stanja. Ipak, obrnuti proxy održava otvorenu vezu, omogućavajući klijentu pristup privatnom REST API-ju putem nje.

Većina obrnutih proxyja je ranjiva na ovaj scenario, ali iskorišćavanje zavisi od prisustva ranjivosti spoljnjeg SSRF-a, koja se obično smatra problemom n

8.5 KiB Raw Blame History