
Exploit per CVE-2021-45468, un bypass di Imperva WAF.
Imperva Cloud WAF era vulnerabile a un bypass che permette agli attaccanti di eludere le regole 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 implementato una correzione globale in pochi giorni. Complimenti. Tutti i clienti di Cloud WAF sono automaticamente aggiornati a partire dal 22 dicembre 2021. Imperva è stato un partner eccellente con cui lavorare e ha chiaramente 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 WAF verrà applicata alle richieste POST.
Puoi farlo in Burp utilizzando la funzione Match & Replace del proxy:

Aggiungi un nuovo header in questo modo:

Questo è tutto; sei a posto.
Esegui imperva_gzip.py su 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
Verifica se il WAF è vulnerabile al bypass gzip:
$ ./imperva_gzip.py https://www.vulnerable.com/search
[+] Possiamo fare richieste POST a https://www.vulnerable.com/search?
[+] Verifica per Imperva WAF...
[+] Tentativo di bypass gzip per trigger UNIX...
[+] Vulnerabile! Codice risposta HTTP: 200
[+] Tentativo di bypass gzip per trigger Windows...
[+] Vulnerabile! Codice risposta HTTP: 200
Se ottieni questo errore:
$ ./imperva_gzip.py https://www.vulnerable.com/search
[+] Possiamo fare richieste POST a https://www.vulnerable.com/search?
[!] Impossibile fare POST a https://www.vulnerable.com/search. Prova -r se sono consentiti redirect 30x. Codice risposta HTTP: 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 dovrebbe ottenere una risposta HTTP 200 dal server. -r estende le risposte accettabili a HTTP 2xx, 3xx.
I codici di uscita per imperva_gzip.py sono i seguenti:
0: Restituito dopo aver ottenuto il tipo di WAF.
1: Riga di comando non valida.
2: Si è verificato un errore di connessione. Potrebbe essere un errore DNS, timeout, ecc.
3: Nessun WAF rilevato; i payload dannosi UNIX/Windows non sono stati bloccati.
4: Rilevato un WAF, ma non era Imperva.
5: Il server ha risposto a una richiesta POST di test con qualcosa di diverso da HTTP 200.
128: È presente un WAF Imperva, ma non è vulnerabile al bypass gzip.
129: Il bypass è stato efficace per il payload UNIX, ma non per quello Windows.
130: Il bypass è stato efficace per il payload Windows, ma non per quello UNIX.
131: Il bypass è stato efficace sia per i payload Windows che UNIX.
Invia tre richieste POST:
&test=../../../../../../../etc/shadow nel corpo per verificare che Imperva blocchi la richiestaContent-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 aggiornato 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 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 eredità di 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 sia stato introdotto. È possibile che la vulnerabilità sia presente da anni!
Supporto clienti Imperva: https://www.imperva.com/support/technical-support/