bishopfox/imperva_gzip_waf_bypassExploit para evadir Imperva Cloud WAF mediante la cabecera gzip Content-Encoding para eludir las reglas del WAF en peticiones HTTP POST. Incluye script de detección y pasos de prueba manuales.
Imperva Cloud WAF era vulnerable a un bypass que permite a los atacantes evadir las reglas del WAF al enviar payloads HTTP POST maliciosos, como exploits de log4j, inyección SQL, ejecución de comandos, traversal de directorios, XXE, etc.
El equipo de Imperva se tomó esto muy en serio desde el minuto en que se les notificó, y pusieron en marcha una corrección global en solo unos días. Felicitaciones. Todos los clientes de Cloud WAF están parcheados automáticamente a partir del 22 de diciembre de 2021. Fue un placer trabajar con Imperva; claramente tienen un equipo de seguridad maduro, cualificado y competente.
Agrega la cabecera Content-Encoding: gzip a las peticiones HTTP POST. Deja los datos POST tal cual. No los codifiques. Mientras los primeros cuatro bytes de la cabecera Content-Encoding sean gzip, no se aplicará ninguna regla del WAF a las peticiones POST.
Puedes hacerlo en Burp usando la función Match & Replace del proxy:
Añade una nueva cabecera así:
Eso es todo; ya estás listo.
Ejecuta imperva_gzip.py contra una URL que admita peticiones POST, así:
Sintaxis:
./imperva_gzip.py [[-t] | [-r]] URL
Detecta el tipo de WAF para una URL determinada:
$ ./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
Comprueba si el WAF es vulnerable al bypass por 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
Si obtienes este error:
$ ./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
entonces prueba a pasar -r en la línea de comandos para habilitar el modo relajado. El modo relajado está desactivado por defecto, lo que significa que se espera que una petición POST provoque una respuesta HTTP 200 del servidor. -r amplía las respuestas aceptables a HTTP 2xx, 3xx.
Los códigos de salida de imperva_gzip.py son los siguientes:
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.
Envía tres peticiones POST:
&test=../../../../../../../etc/shadow, en el cuerpo para verificar que Imperva la bloqueaContent-Encoding: gzip a la misma petición maliciosa y verifica que Imperva no la bloqueaSegún https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding, hay cuatro valores válidos para la cabecera Content-Encoding:
compressdeflategzipbrEn las pruebas, solo gzip funcionó como bypass.
Cloud WAF está gestionado por Imperva. Como resultado, las actualizaciones de Cloud WAF afectan a casi todos los clientes casi al mismo tiempo. Está parcheado para todos los clientes a partir del 22 de diciembre de 2021.
El fallo de bypass por gzip se ha corregido en un producto independiente de Imperva llamado SecureSphere. Las notas de la versión 12.6 de SecureSphere contienen este párrafo:
SPHR-58185: Cuando SecureSphere no podía descomprimir el cuerpo POST en peticiones con la cabecera “Content-Encoding: gzip/deflate”, no emitía ninguna alerta y dejaba pasar la petición.
Estoy bastante seguro de que es el mismo fallo, quizá con el mismo origen de código que Cloud WAF... es un fallo muy específico para estar en dos productos. El problema se resolvió para SecureSphere en febrero de 2021, pero no sabemos cuándo se introdujo. ¡Es posible que la vulnerabilidad haya estado ahí durante años!
Soporte al cliente de Imperva: https://www.imperva.com/support/technical-support/