<summary><strong>Impara l'hacking AWS da zero a eroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
* Se vuoi vedere la tua **azienda pubblicizzata su HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT esclusivi**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.
#### HTTP2 Over Cleartext (H2C) <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
H2C, o **http2 over cleartext**, si discosta dalla norma delle connessioni HTTP transitorie aggiornando una connessione HTTP standard a una persistente. Questa connessione aggiornata utilizza il protocollo binario http2 per la comunicazione continua, invece della natura di singola richiesta dell'HTTP in chiaro.
Il nocciolo della questione dello smuggling sorge con l'uso di un **proxy inverso**. Normalmente, il proxy inverso elabora e inoltra le richieste HTTP al backend, restituendo la risposta del backend successivamente. Tuttavia, quando l'intestazione `Connection: Upgrade` è presente in una richiesta HTTP (comunemente vista con le connessioni websocket), il **proxy inverso mantiene una connessione persistente** tra client e server, facilitando lo scambio continuo richiesto da alcuni protocolli. Per le connessioni H2C, il rispetto dell'RFC richiede la presenza di tre intestazioni specifiche:
La vulnerabilità sorge quando, dopo l'aggiornamento di una connessione, il reverse proxy smette di gestire singole richieste, assumendo che il suo compito di instradamento sia completato dopo l'instaurazione della connessione. Sfruttare lo Smuggling H2C consente di aggirare le regole del reverse proxy applicate durante l'elaborazione delle richieste, come l'instradamento basato sul percorso, l'autenticazione e l'elaborazione del WAF, assumendo che una connessione H2C venga avviata con successo.
La vulnerabilità dipende dal modo in cui il reverse proxy gestisce gli header `Upgrade` e talvolta `Connection`. I seguenti proxy inoltrano inherentemente questi header durante il proxy-pass, abilitando di conseguenza lo Smuggling H2C:
Al contrario, questi servizi non inoltrano inherentemente entrambi gli header durante il proxy-pass. Tuttavia, potrebbero essere configurati in modo non sicuro, consentendo l'inoltro non filtrato degli header `Upgrade` e `Connection`:
È fondamentale notare che non tutti i server inoltrano inherentemente gli header necessari per un aggiornamento della connessione H2C conforme. Pertanto, server come AWS ALB/CLB, NGINX e Apache Traffic Server, tra gli altri, bloccano naturalmente le connessioni H2C. Tuttavia, è utile testare con la variante non conforme `Connection: Upgrade`, che esclude il valore `HTTP2-Settings` dall'header `Connection`, poiché alcuni back-end potrebbero non conformarsi agli standard.
Indipendentemente dal **percorso** specifico designato nell'URL `proxy_pass` (ad esempio, `http://backend:9999/socket.io`), la connessione stabilita predefinita è `http://backend:9999`. Ciò consente l'interazione con qualsiasi percorso all'interno di tale endpoint interno, sfruttando questa tecnica. Di conseguenza, la specifica di un percorso nell'URL `proxy_pass` non limita l'accesso.
Gli strumenti [**h2csmuggler di BishopFox**](https://github.com/BishopFox/h2csmuggler) e [**h2csmuggler di assetnote**](https://github.com/assetnote/h2csmuggler) agevolano i tentativi di **aggirare le protezioni imposte dal proxy** stabilendo una connessione H2C, consentendo così l'accesso alle risorse protette dal proxy.
Per ulteriori informazioni su questa vulnerabilità, in particolare riguardo a NGINX, fare riferimento a [**questa risorsa dettagliata**](../network-services-pentesting/pentesting-web/nginx.md#proxy\_set\_header-upgrade-and-connection).
Lo Smuggling Websocket, a differenza della creazione di un tunnel HTTP2 verso un endpoint accessibile tramite un proxy, stabilisce un tunnel Websocket per aggirare eventuali limitazioni del proxy e facilitare la comunicazione diretta con l'endpoint.
In questo scenario, un back-end che offre un'API WebSocket pubblica insieme a un'API REST interna non accessibile è preso di mira da un client malintenzionato che cerca di accedere all'API REST interna. L'attacco si sviluppa in diverse fasi:
1. Il client inizia inviando una richiesta di Upgrade al reverse proxy con una versione del protocollo `Sec-WebSocket-Version` errata nell'header. Il proxy, non riuscendo a convalidare l'header `Sec-WebSocket-Version`, ritiene valida la richiesta di Upgrade e la inoltra al back-end.
2. Il back-end risponde con un codice di stato `426`, indicando la versione del protocollo errata nell'header `Sec-WebSocket-Version`. Il reverse proxy, ignorando lo stato di risposta del back-end, assume la prontezza alla comunicazione WebSocket e inoltra la risposta al client.
3. Di conseguenza, il reverse proxy viene ingannato nel credere che sia stata stabilita una connessione WebSocket tra il client e il back-end, mentre in realtà il back-end ha respinto la richiesta di Upgrade. Nonostante ciò, il proxy mantiene una connessione TCP o TLS aperta tra il client e il back-end, consentendo al client di accedere senza restrizioni all'API REST privata tramite questa connessione.
I reverse proxy interessati includono Varnish, che ha rifiutato di affrontare il problema, e il proxy Envoy versione 1.8.0 o più vecchie, con versioni successive che hanno modificato il meccanismo di aggiornamento. Anche altri proxy potrebbero essere vulnerabili.
Questo scenario coinvolge un back-end con un'API WebSocket pubblica e un'API REST pubblica per il controllo dello stato di salute, insieme a un'API REST interna non accessibile. L'attacco, più complesso, coinvolge i seguenti passaggi:
1. Il client invia una richiesta POST per attivare l'API di controllo dello stato di salute, includendo un header HTTP aggiuntivo `Upgrade: websocket`. NGINX, in qualità di reverse proxy, interpreta ciò come una richiesta di Upgrade standard basata esclusivamente sull'header `Upgrade`, trascurando gli altri aspetti della richiesta, e la inoltra al back-end.
2. Il back-end esegue l'API di controllo dello stato di salute, contattando una risorsa esterna controllata dall'attaccante che restituisce una risposta HTTP con codice di stato `101`. Questa risposta, una volta ricevuta dal back-end e inoltrata a NGINX, inganna il proxy facendogli credere che sia stata stabilita una connessione WebSocket a causa della sua convalida solo del codice di stato.
> **Avviso:** La complessità di questa tecnica aumenta poiché richiede la capacità di interagire con un endpoint in grado di restituire un codice di stato 101.
Alla fine, NGINX viene ingannato nel credere che esista una connessione WebSocket tra il client e il back-end. In realtà, tale connessione non esiste; l'API REST di controllo dello stato di salute era l'obiettivo. Tuttavia, il reverse proxy mantiene la connessione aperta, consentendo al client di accedere all'API REST privata attraverso di essa.
La maggior parte dei reverse proxy è vulnerabile a questo scenario, ma lo sfruttamento dipende dalla presenza di una vulnerabilità SSRF esterna, generalmente considerata un problema di bassa gravità.
Controlla i laboratori per testare entrambi gli scenari su [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)
<summary><strong>Impara l'hacking AWS da zero a esperto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se desideri vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale PEASS & HackTricks**](https://peass.creator-spring.com)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
