
Exploit para contornar o Imperva Cloud WAF usando o cabeçalho gzip Content-Encoding para evadir as regras de WAF em requisições HTTP POST. Inclui script de detecção e etapas de teste manual.
O Imperva Cloud WAF estava vulnerável a um bypass que permite que invasores evitem as regras do WAF ao enviar cargas úteis HTTP POST maliciosas, como exploits de log4j, injeção de SQL, execução de comandos, directory traversal, XXE, etc.
A equipe da Imperva levou isso muito a sério desde o minuto em que foi reportado a eles, e eles implementaram uma correção global em apenas alguns dias. Parabéns. Todos os clientes do Cloud WAF foram corrigidos automaticamente a partir de 22 de dezembro de 2021. A Imperva foi ótima de trabalhar e claramente tem uma equipe de segurança madura, qualificada e competente.
Adicione o cabeçalho Content-Encoding: gzip às solicitações HTTP POST. Deixe os dados POST como estão. Não os codifique. Desde que os primeiros quatro bytes do cabeçalho Content-Encoding sejam gzip, nenhuma regra do WAF será aplicada às solicitações POST.
Você pode fazer isso no Burp usando o recurso Match & Replace do proxy:

Adicione um novo cabeçalho assim:

É isso; você está pronto para prosseguir.
Execute imperva_gzip.py contra uma URL que suporte solicitações POST, assim:
Syntax:
./imperva_gzip.py [[-t] | [-r]] URL
Descubra o tipo de WAF para uma determinada 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
Verifique se o WAF está vulnerável ao 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
Se você receber este erro:
$ ./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
então tente passar -r na linha de comando para ativar o modo relaxado. O modo relaxado fica desativado por padrão, o que significa que espera-se que uma solicitação POST receba uma resposta HTTP 200 do servidor. -r expande as respostas aceitáveis para HTTP 2xx, 3xx.
Os códigos de saída para imperva_gzip.py são os seguintes:
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.
Envie três solicitações POST:
&test=../../../../../../../etc/shadow no corpo, para verificar se o Imperva a bloqueiaContent-Encoding: gzip à mesma solicitação maliciosa e verifique se o Imperva não a bloqueiaDe acordo com https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding, há quatro valores válidos para o cabeçalho Content-Encoding:
compressdeflategzipbrNos testes, apenas gzip funcionou como bypass.
O Cloud WAF é gerenciado pela Imperva. Como resultado, as atualizações do Cloud WAF afetam quase todos os clientes quase ao mesmo tempo. Ele está corrigido para todos os clientes a partir de 22 de dezembro de 2021.
O bug do bypass por gzip foi corrigido em um produto separado da Imperva chamado SecureSphere. As notas de versão para a v12.6 do SecureSphere contêm este parágrafo:
SPHR-58185: Quando o SecureSphere não conseguia descompactar o corpo de uma solicitação POST com o cabeçalho "Content-Encoding: gzip/deflate", ele não emitia nenhum alerta e deixava a solicitação passar.
Tenho quase certeza de que este é o mesmo bug, talvez com a mesma herança de código do Cloud WAF... é um bug bastante específico para estar em dois produtos. O problema foi resolvido para o SecureSphere em fevereiro de 2021, mas não sabemos quando foi introduzido. É possível que a vulnerabilidade exista há anos!
Suporte ao Cliente Imperva: https://www.imperva.com/support/technical-support/