
Exploit para CVE-2021-45468, un bypass de Imperva WAF.
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, directory traversal, XXE, etc.
El equipo de Imperva se tomó esto muy en serio desde el momento en que se les reportó, y aplicaron una corrección global en solo unos días. Felicitaciones. Todos los clientes de Cloud WAF están parcheados automáticamente desde el 22 de diciembre de 2021. Fue un placer trabajar con Imperva, que claramente cuenta con un equipo de seguridad maduro, capacitado y capaz.
Añada el encabezado Content-Encoding: gzip a las solicitudes HTTP POST. Deje los datos POST tal cual. No los codifique. Mientras los primeros cuatro bytes del encabezado Content-Encoding sean gzip, no se aplicarán reglas WAF a las solicitudes POST.
Puede hacer esto en Burp usando la función Match & Replace del proxy:

Añada un nuevo encabezado así:

Eso es todo; ya está listo.
Ejecute imperva_gzip.py contra una URL que acepte solicitudes POST así:
Sintaxis:
./imperva_gzip.py [[-t] | [-r]] URL
Adivina el tipo de WAF para una URL dada:
$ ./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 gzip:
$ ./imperva_gzip.py https://www.vulnerable.com/search
[+] ¿Podemos hacer solicitudes POST a https://www.vulnerable.com/search?
[+] Verificando si hay Imperva WAF...
[+] Intentando bypass gzip para trigger UNIX...
[+] ¡Vulnerable! Código de respuesta HTTP: 200
[+] Intentando bypass gzip para trigger Windows...
[+] ¡Vulnerable! Código de respuesta HTTP: 200
Si obtiene este error:
$ ./imperva_gzip.py https://www.vulnerable.com/search
[+] ¿Podemos hacer solicitudes POST a https://www.vulnerable.com/search?
[!] No se puede enviar POST a https://www.vulnerable.com/search. Pruebe -r si se permiten redirecciones 30x. Código de respuesta HTTP: 302
entonces intente 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 solicitud POST genere 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: Retornado después de obtener el tipo de WAF.
1: La línea de comandos no era válida.
2: Hubo un error de conexión. Podría ser un error DNS, timeout, etc.
3: No se detectó WAF; los payloads maliciosos de UNIX/Windows no fueron bloqueados.
4: Se detectó un WAF, pero no era Imperva.
5: El servidor respondió a una solicitud POST de prueba con algo diferente a HTTP 200.
128: Hay un WAF Imperva, pero no es vulnerable al bypass gzip.
129: El bypass fue efectivo para el payload UNIX, pero no para el de Windows.
130: El bypass fue efectivo para el payload Windows, pero no para el de UNIX.
131: El bypass fue efectivo tanto para payloads Windows como UNIX.
Envíe tres solicitudes POST:
&test=../../../../../../../etc/shadow en el cuerpo para verificar que Imperva lo bloqueaContent-Encoding: gzip a la misma solicitud maliciosa y verifique que Imperva no la bloqueaSegún https://developer.mozilla.org/es/docs/Web/HTTP/Headers/Content-Encoding, hay cuatro valores válidos para el encabezado Content-Encoding:
compressdeflategzipbrEn las pruebas, solo gzip funcionó como bypass.
Cloud WAF es 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 desde el 22 de diciembre de 2021.
El error del bypass gzip ha sido corregido en un producto separado de Imperva llamado SecureSphere. Las notas de la versión v12.6 de SecureSphere contienen este párrafo:
SPHR-58185: Cuando SecureSphere fallaba al descomprimir el cuerpo POST en solicitudes con el encabezado "Content-Encoding: gzip/deflate", no emitía ninguna alerta y dejaba pasar la solicitud.
Estoy bastante seguro de que es el mismo error, quizás con la misma herencia de código que Cloud WAF... es un error muy específico como 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 presente durante años!
Soporte al cliente de Imperva: https://www.imperva.com/support/technical-support/