# Nadogradnja Header Smuggling
Naučite hakovanje AWS-a od nule do heroja sahtARTE (HackTricks AWS Red Team Expert)!
Drugi načini podrške HackTricks-u:
* Ako želite da vidite svoju **kompaniju reklamiranu na HackTricks-u** ili da **preuzmete HackTricks u PDF formatu** proverite [**PLANOVE ZA PRIJAVU**](https://github.com/sponsors/carlospolop)!
* Nabavite [**zvanični PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Otkrijte [**Porodicu PEASS**](https://opensea.io/collection/the-peass-family), našu kolekciju ekskluzivnih [**NFT-ova**](https://opensea.io/collection/the-peass-family)
* **Pridružite se** 💬 [**Discord grupi**](https://discord.gg/hRep4RUj7f) ili [**telegram grupi**](https://t.me/peass) ili nas **pratite** na **Twitteru** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Podelite svoje hakovanje trikove slanjem PR-ova na** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repozitorijume.
**Try Hard Security Group**
{% embed url="https://discord.gg/tryhardsecurity" %}
***
### H2C Smuggling
#### HTTP2 preko čistog teksta (H2C)
H2C, ili **http2 preko čistog teksta**, odstupa od norme prolaznih HTTP veza nadogradnjom standardne HTTP **veze na postojanu**. 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 **reverse proxy-ja**. Obično, reverse proxy obrađuje i prosleđuje HTTP zahteve backend-u, vraćajući odgovor backend-a nakon toga. Međutim, kada je `Connection: Upgrade` zaglavlje prisutno u HTTP zahtevu (često viđeno kod websocket veza), reverse **proxy održava postojanu vezu** između klijenta i servera, olakš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
```
### Ranjive proxy serveri
Ranjivost nastaje kada, nakon ažuriranja veze, reverzni proxy prestane da upravlja pojedinačnim zahtevima, pretpostavljajući da je njegov posao rutiranja završen nakon uspostavljanja veze. Iskorišćavanje H2C Smuggling-a omogućava zaobilaženje pravila reverznog proxy-ja koja se primenjuju tokom obrade zahteva, kao što su rutiranje zasnovano na putanji, autentifikacija i WAF obrada, pod uslovom da je H2C veza uspešno uspostavljena.
#### Ranjivi proxy serveri
Ranjivost zavisi od rukovanja reverznog proxy-ja sa `Upgrade` i ponekad `Connection` zaglavljima. Sledeći proxy serveri inherentno prosleđuju ova zaglavlja tokom proxy-pass, čime inherentno omogućavaju H2C smuggling:
* HAProxy
* Traefik
* Nuster
S druge strane, ovi servisi inherentno ne prosleđuju oba zaglavlja tokom proxy-pass. Međutim, mogu biti konfigurisani nebezbedno, omogućavajući nefiltrirano prosleđivanje `Upgrade` i `Connection` zaglavlja:
* AWS ALB/CLB
* NGINX
* Apache
* Squid
* Varnish
* Kong
* Envoy
* Apache Traffic Server
#### Iskorišćavanje
Važno je napomenuti da ne svi serveri inherentno prosleđuju potrebna zaglavlja za usklađenu H2C vezu. Stoga, 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 `Connection` zaglavlja, jer neki backend-ovi 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 podrazumevano se vraća na `http://backend:9999`. Ovo omogućava interakciju sa bilo kojom putanjom unutar te interne 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**](https://github.com/BishopFox/h2csmuggler) i [**h2csmuggler od strane assetnote-a**](https://github.com/assetnote/h2csmuggler) olakšavaju pokušaje da se **zaobiđu zaštite nametnute od strane proxy-ja** uspostavljanjem H2C veze, čime se omogućava pristup resursima zaštićenim od strane proxy-ja.
Za dodatne informacije o ovoj ranjivosti, posebno u vezi sa NGINX-om, pogledajte [**ovaj detaljan resurs**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
## Websocket Smuggling
Websocket smuggling, za razliku od kreiranja HTTP2 tunela do tačke pristupa preko proxy-ja, uspostavlja Websocket tunel radi zaobilaženja potencijalnih ograničenja proxy-ja i olakšavanja direktnog komuniciranja sa tačkom pristupa.
### Scenario 1
U ovom scenariju, zlonamerni klijent cilja backend koji nudi javni WebSocket API zajedno sa nepristupačnim internim REST API-jem. Napad se odvija u nekoliko koraka:
1. Klijent započinje slanjem Upgrade zahteva reverznom proxy-ju sa netačnom verzijom protokola `Sec-WebSocket-Version` u zaglavlju. Proxy, ne uspevajući da validira `Sec-WebSocket-Version` zaglavlje, veruje da je Upgrade zahtev validan i prosleđuje ga backend-u.
2. Backend odgovara status kodom `426`, ukazujući na netačnu verziju protokola u `Sec-WebSocket-Version` zaglavlju. Reverzni proxy, ignorisavši odgovor backend-a, pretpostavlja spremnost za WebSocket komunikaciju i prosleđuje odgovor klijentu.
3. Stoga, reverzni proxy je zaveden da veruje da je uspostavljena WebSocket veza između klijenta i backend-a, dok je zapravo backend odbio Upgrade zahtev. Bez obzira na to, proxy održava otvorenu TCP ili TLS vezu između klijenta i backend-a, omogućavajući klijentu neograničen pristup privatnom REST API-ju putem ove veze.
Pogođeni reverzni proxy serveri uključuju Varnish, koji je odbio da reši problem, i Envoy proxy verziju 1.8.0 ili starije, pri čemu su kasnije verzije promenile mehanizam nadogradnje. Drugi proxy serveri 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 zdravlja, zajedno sa nepristupačnim internim REST API-jem. Napad, složeniji, uključuje sledeće korake:
1. Klijent šalje POST zahtev kako bi pokrenuo health check API, uključujući dodatni HTTP zaglavlje `Upgrade: websocket`. NGINX, koji služi kao reverzni proxy, tumači ovo kao standardni Upgrade zahtev zasnovan isključivo na `Upgrade` zaglavlju, zanemarujući druge aspekte zahteva, i prosleđuje ga backend-u.
2. Backend izvršava health check API, pristupajući spoljnom resursu koji kontroliše napadač i koji vraća HTTP odgovor sa status kodom `101`. Ovaj odgovor, kada stigne do backend-a i bude prosleđen NGINX-u, zavodi proxy da veruje da je uspostavljena WebSocket veza zbog validacije samo status koda.
> **Upozorenje:** Složenost ove tehnike se povećava jer zahteva sposobnost interakcije sa tačkom pristupa koja može vratiti status kod 101.
Na kraju, NGINX je prevaren da veruje da postoji WebSocket veza između klijenta i backend-a. U stvarnosti, takva veza ne postoji; health check REST API je bio meta. Ipak, reverzni proxy održava otvorenu vezu, omogućavajući klijentu pristup privatnom REST API-ju putem nje.
Većina reverznih proxy servera je ranjiva na ovaj scenario, ali iskorišćavanje zavisi od prisustva spoljne SSRF ranjivosti, obično smatrane kao problem niskog stepena ozbiljnosti.
#### Laboratorije
Proverite laboratorije kako biste testirali oba scenarija na [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
### Reference
* [https://blog.assetnote.io/2021/03/18/h2c-smuggling/](https://blog.assetnote.io/2021/03/18/h2c-smuggling/)
* [https://bishopfox.com/blog/h2c-smuggling-request](https://bishopfox.com/blog/h2c-smuggling-request)
* [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
