A Cloudflare testou seu firewall de aplicações web (WAF) usando modelos avançados de inteligência artificial capazes de modificar as solicitações ofensivas após cada tentativa, em vez de se limitar a um conjunto fixo de testes. A empresa realizou o experimento em um ambiente de staging privado de um cliente, com aprovação prévia, e registrou 1.107 tentativas em 45 cenários.
A ideia básica é simular parte do comportamento de um invasor capaz de experimentar diferentes codificações, transferir a carga útil para outras posições dentro de uma solicitação HTTP ou alterar a forma de representação do destino e, em seguida, usar a resposta para escolher a próxima tentativa. O modelo não recebeu o código da aplicação, as regras internas do WAF nem os números das regras; ele lidou apenas com o contexto da solicitação e dados específicos da resposta HTTP.
Como funcionou o teste adaptativo?
Cada cenário começou com uma solicitação conhecida por ser bloqueada pelo WAF, e então o modelo propôs uma nova modificação. Depois do envio da solicitação, outro modelo ou uma chamada de revisão do modelo analisava a resposta, antes de o sistema determinar a etapa seguinte dentro de um limite máximo de tentativas. O código ficou responsável por executar as solicitações e registrar as evidências; também verificava o nome de domínio antes de cada tentativa por meio de uma lista permitida, interrompia redirecionamentos e impedia o sistema de alterar ou publicar regras de proteção.
44 dos cenários abrangeram seis categorias: cross-site scripting (XSS), injeção de SQL, injeção de comandos, falsificação de solicitações do lado do servidor (SSRF), travessia de caminhos ou inclusão de arquivos locais (LFI) e ataques Log4j. O 45º cenário tratou da injeção de registros separadamente.
De 1.107 tentativas a 49 resultados investigáveis
O desempenho do WAF foi forte no geral, com cobertura quase completa das categorias XSS, LFI, SQLi e Log4j. Após a revisão humana, restaram 49 resultados que mereciam investigação, dos quais 48 pertenciam às categorias de injeção de comandos e SSRF. O número de solicitações bloqueadas foi de 558, enquanto outras tentativas foram excluídas por serem inválidas, benignas, duplicadas ou por não terem chegado ao alvo.
A Cloudflare não considerou uma solicitação não bloqueada uma vulnerabilidade confirmada. Exigiu que a solicitação fosse válida e chegasse ao alvo, que permanecesse claramente maliciosa, que o comportamento fosse atribuído ao WAF e que os engenheiros conseguissem reproduzi-lo com segurança. Essa distinção é importante porque contornar o WAF, por si só, não comprova o sucesso da exploração da aplicação nem o acesso a dados confidenciais.
Exemplo de uma lacuna na detecção de SSRF
Em um dos cenários, o sistema alterou a forma de escrever o endereço do serviço de metadados da nuvem, usou diferentes representações numéricas e colocou o endereço em várias partes da solicitação. A maioria das tentativas foi bloqueada, mas uma das tentativas que usou uma representação com um ponto final levou a um redirecionamento, em vez de ser bloqueada pelo WAF. A Cloudflare considerou isso um sinal que merecia investigação, não uma prova de acesso às credenciais ou de sucesso da exploração.
O que mudou na prática?
A Cloudflare analisou os resultados para determinar se precisava de uma nova regra, de melhorias na normalização das solicitações ou da intervenção de outra camada de segurança. Os resultados contribuíram para três mudanças no Managed Ruleset: a adição das detecções SSRF - Obfuscated Host e SSRF - Restricted Protocol na versão de 21 de julho e a melhoria da detecção SSRF - Cloud. A detecção de host ofuscado veio diretamente de solicitações que usaram formatos numéricos incomuns para endereços internos.
O experimento mostra que a inteligência artificial é, nesse caso, uma ferramenta para ampliar o espaço de testes, não um substituto para o julgamento de engenharia. Dois modelos da mesma família produziram variações diferentes, mas os problemas básicos apareceram em ambos. Além disso, aumentar o número de tentativas dentro de um mesmo cenário não garantiu a descoberta de resultados adicionais; algumas sequências começaram a repetir ideias, enquanto o aumento dos pontos de partida, das categorias de ataque e das posições de entrada proporcionou uma cobertura mais ampla.
Os limites do WAF continuam presentes: a carga útil que ultrapassa o firewall só terá sucesso se a própria aplicação for explorável, portanto manter o software atualizado e corrigir vulnerabilidades continua sendo necessário. A Cloudflare também recomenda ativar as regras primeiro no modo de registro, revisar as solicitações correspondentes e os eventos de segurança e só então passar ao bloqueio após verificar que o tráfego legítimo não foi afetado. Posteriormente, a empresa planeja realizar um teste white-box no qual o modelo conhecerá simultaneamente as vulnerabilidades da aplicação e as regras do WAF.