Italian - Ht
HackTricks Training Twitter Linkedin Sponsor

Upgrade Header Smuggling

Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

Try Hard Security Group

H2C Smuggling

HTTP2 Over Cleartext (H2C)

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:

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

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.

Proxy Vulnerabili

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:

  • HAProxy

  • Traefik

  • Nuster

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:

  • AWS ALB/CLB

  • NGINX

  • Apache

  • Squid

  • Varnish

  • Kong

  • Envoy

  • Apache Traffic Server

Sfruttamento

È 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 e h2csmuggler di assetnote 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.

Smuggling Websocket

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.

Scenario 1

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.

Scenario 2

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

Laboratori

Controlla i laboratori per testare entrambi gli scenari su https://github.com/0ang3el/websocket-smuggle.git

Riferimenti

Try Hard Security Group

Impara l'hacking AWS da zero a esperto con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

PreviousHTTP Response Smuggling / DesyncNexthop-by-hop headers

Last updated