Os Web Application Firewalls (WAFs) são uma parte crucial da infraestrutura de segurança de qualquer serviço ou aplicação baseados na web, protegendo-os de ataques que podem causar danos financeiros e de reputação. Como tal, formas de contornar as capacidades de bloqueio e filtro de um WAF são altamente procuradas pelos cibercriminosos.
Em Dezembro de 2022 falamos sobre um desses ataques, um “bypass” descoberto pela Team82, a equipe de pesquisa em segurança da Claroty. Ele afetava múltiplos Web Application Firewalls oferecidos por vários fornecedores populares. O WAF da Azion era imune ao ataque que possibilitava o bypass.
Agora, pesquisadores de segurança da Praetorian encontraram outro bypass1, que afeta o WAF da Akamai. E ele pode não ser o único que é vulnerável: os pesquisadores afirmam não querer “que este artigo destaque a Akamai em particular. Em vez disso, suspeitamos que agressores poderiam usar técnicas de evasão similares contra praticamente qualquer Web Application Firewall no mercado”.
Após uma avaliação interna, podemos afirmar com confiança que o WAF da Azion não é vulnerável a esse novo ataque.
Como o ataque funciona
De acordo com a Praetorian, este é um ataque de “Injeção de CRLF”. Esse tipo de ataque ocorre quando “uma aplicação não realiza a filtragem corretamente e retorna um cabeçalho de resposta HTTP que inclui entrada do usuário controlada pelo agressor. Esse tipo de vulnerabilidade permite a um agressor inserir os caracteres para retorno de carro (abreviado como CR, e comumente representado pela sequência ‘\r’) e avanço de linha (abreviado como LF e representado pela sequência ‘\n’) no corpo da resposta HTTP”.
Com isso, um agressor pode “acabar controlando tanto os cabeçalhos HTTP quanto os dados no corpo da resposta HTTP. Este problema pode levar a outras vulnerabilidades como Cross-Site Scripting (XSS) e redirecionamento aberto”.
Indo além, os engenheiros tentaram explorar a vulnerabilidade adicionando a payload <script>alert(“XSS”)</script> no corpo da resposta HTTP. Entretanto, isto foi corretamente bloqueado pelo WAF, já que suas regras detectaram a tag <script>.
O que poderia ser feito para evitar a detecção? Ofuscar. “Levantamos a hipótese de que poderíamos injetar um cabeçalho usando injeção CRLF para especificar que o corpo da resposta HTTP está comprimido”, disseram os engenheiros. “Neste caso, não precisaríamos modificar nossa payload XSS, já que usamos a compressão para contornar as regras do WAF”.
Eles escolheram o algoritmo de compressão deflate e injetaram um cabeçalho Content-Encoding especificando isso. Um cabeçalho Content-length, especificando o tamanho exato do cabeçalho comprimido, também foi adicionado. E o experimento funcionou.
De acordo com os engenheiros, essa técnica é digna de nota já que “o encadeamento de uma injeção CRLF para causar cross-site scripting e a evasão de um web application firewall através da injeção de dados comprimidos no corpo da resposta é uma abordagem inovadora. Não estamos cientes de outro artigo que discuta esse método”.
Por que o WAF da Azion não é afetado?
Após ser informada sobre o ataque, nossa equipe de segurança testou a prova de conceito apresentada pela Praetorian contra seu próprio Web Application Firewall.
Dois testes foram executados em um ambiente controlado usando o WAF da Azion. Nossa equipe de segurança usou uma ferramenta de teste de segurança chamada Burp Suite Professional para executar ataques simulados. Esse software permite a um pesquisador enviar diferentes tipos de requisições a um sistema e validar seu comportamento e resposta.
No primeiro teste, simulamos um agressor adicionando um caractere de quebra de linha URL-encoded (%0a) à requisição GET para definir um cookie (usando a declaração Set-Cookie) com o par de chave/valor “crlf=injection”. Como é possível ver no campo Resposta, a declaração não foi interpretada e o cookie não foi definido.
Imagem: Azion Technologies
No segundo teste, novamente injetamos um CRLF na requisição GET (não visível na imagem abaixo) para definir os cabeçalhos Content-Type, Content-Encoding e Content-Length de forma fraudulenta. Entretanto, a tentativa foi bloqueada com sucesso pelo WAF da Azion, que retornou o código de status HTTP 400 (Bad Request).
Imagem: Azion Technologies
Conclusão
Os resultados obtidos em ambos os testes provam novamente a eficácia do WAF da Azion em proteger nossos clientes de ameaças zero-day. De acordo com Marcos R. Carvalho, Security Architect da Azion: “Isso foi feito usando as regras padrão da Azion e seu algoritmo de classificação proprietário, sem a necessidade de expressões regulares adicionais”.
Cadastre-se gratuitamente e descubra como o Web Application Firewall da Azion pode ajudar a proteger suas aplicações e serviços contra vários tipos de ameaças, ou contate nossos experts para mais detalhes.
Referências
1 Bypassing Akamai’s Web Application Firewall Using an Injected Content-Encoding Header
