Imperva Web Application Firewall (WAF) POST-Request-Bypass

Imperva Cloud WAF war anfällig für einen Bypass, der es Angreifern ermöglicht, WAF-Regeln zu umgehen, wenn sie bösartige HTTP-POST-Payloads senden, wie z. B. log4j-Exploits, SQL-Injection, Befehlsausführung, Directory Traversal, XXE usw.

Behebung

Das Imperva-Team hat die Meldung von der ersten Minute an sehr ernst genommen und in nur wenigen Tagen einen globalen Fix umgesetzt. Alle Achtung. Alle Kunden von Cloud WAF sind seit dem 22. Dezember 2021 automatisch gepatcht. Die Zusammenarbeit mit Imperva war hervorragend, und das Team verfügt eindeutig über ein reifes, kompetentes und leistungsfähiges Sicherheitsteam.

So nutzen Sie die Schwachstelle aus

Fügen Sie HTTP-POST-Requests den Header Content-Encoding: gzip hinzu. Lassen Sie die POST-Daten unverändert. Kodieren Sie sie nicht. Solange die ersten vier Bytes des Content-Encoding-Headers gzip sind, werden keine WAF-Regeln auf POST-Requests angewendet.

Sie können dies in Burp über die Funktion „Match & Replace" des Proxys tun:

Fügen Sie einen neuen Header wie folgt hinzu:

Das war's; Sie können loslegen.

Ausführen des Testskripts

Führen Sie imperva_gzip.py gegen eine URL aus, die POST-Requests unterstützt, wie folgt:

Syntax: ./imperva_gzip.py [[-t] | [-r]] URL

Ermitteln Sie den WAF-Typ für eine bestimmte 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

Prüfen Sie, ob die WAF anfällig für den gzip-Bypass ist:

$ ./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

Wenn Sie diesen Fehler erhalten:

$ ./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

versuchen Sie dann, -r an der Befehlszeile zu übergeben, um den Relaxed-Modus zu aktivieren. Der Relaxed-Modus ist standardmäßig deaktiviert, d. h., es wird erwartet, dass ein POST-Request eine HTTP-200-Antwort vom Server auslöst. -r erweitert die akzeptablen Antworten auf HTTP 2xx, 3xx.

Skripting

Die Exit-Codes für imperva_gzip.py lauten wie folgt:

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.

Verfahren zum manuellen Testen der Schwachstelle

Senden Sie drei POST-Requests:

Legen Sie mit einem gültigen, aber harmlosen POST-Request eine Baseline für POST-Request/-Response fest.
Lösen Sie die Imperva-WAF mit demselben POST-Request, aber mit zusätzlichen „bösartigen" Daten wie &test=../../../../../../../etc/shadow im Body aus, um zu überprüfen, dass Imperva sie blockiert.
Fügen Sie demselben bösartigen Request den Header Content-Encoding: gzip hinzu und überprüfen Sie, dass Imperva ihn nicht blockiert.

Weitere Kodierungen

Laut https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding gibt es vier gültige Werte für den Content-Encoding-Header:

compress
deflate
gzip
br

Im Test funktionierte nur gzip als Bypass.

Betroffene Versionen

Imperva Cloud WAF

Cloud WAF wird von Imperva verwaltet. Daher wirken sich Updates für Cloud WAF fast zur gleichen Zeit auf fast alle Kunden aus. Seit dem 22. Dezember 2021 ist es für alle Kunden gepatcht.

SecureSphere

Der Fehler im gzip-Bypass wurde in einem separaten Imperva-Produkt namens SecureSphere behoben. Die Versionshinweise für v12.6 von SecureSphere enthalten diesen Absatz:

SPHR-58185: Wenn SecureSphere den POST-Body bei Requests mit dem Header „Content-Encoding: gzip/deflate" nicht dekomprimieren konnte, wurde keine Warnung ausgegeben und der Request durchgelassen.

Ich bin mir ziemlich sicher, dass es sich um denselben Fehler handelt, möglicherweise mit demselben Code-Ursprung wie bei Cloud WAF ... Es ist ein zu spezifischer Fehler, als dass er in zwei Produkten vorkommen könnte. Das Problem wurde für SecureSphere im Februar 2021 behoben, aber wir wissen nicht, wann es eingeführt wurde. Es ist möglich, dass die Schwachstelle seit Jahren besteht!

Imperva_gzip_WAF_Bypass

Beliebteste