Pesquisadores das Universidades de Hamburgo e Colônia
O problema se deve ao fato de que os CDNs armazenam em cache não apenas solicitações concluídas com sucesso, mas também situações em que o servidor http retorna um erro. Via de regra, se houver problemas na formação de solicitações, o servidor emite um erro 400 (Solicitação incorreta); a única exceção é o IIS, que emite um erro 404 (Não encontrado) para cabeçalhos muito grandes. O padrão permite apenas que erros com os códigos 404 (Not Found), 405 (Method Not Allowed), 410 (Gone) e 501 (Not Implemented) sejam armazenados em cache, mas alguns CDNs também armazenam em cache respostas com o código 400 (Bad Request), que depende na solicitação enviada.
Os invasores podem fazer com que o recurso original retorne um erro “400 Bad Request” enviando uma solicitação com cabeçalhos HTTP formatados de uma determinada maneira. Esses cabeçalhos não são levados em consideração pelo CDN, portanto, as informações sobre a impossibilidade de acessar a página serão armazenadas em cache, e todas as outras solicitações válidas do usuário antes que o tempo limite expire podem resultar em erro, apesar do site original veicular o conteúdo sem quaisquer problemas.
Três opções de ataque foram propostas para forçar o servidor HTTP a retornar um erro:
- HMO (HTTP Method Override) - um invasor pode substituir o método de solicitação original por meio dos cabeçalhos "X-HTTP-Method-Override", "X-HTTP-Method" ou "X-Method-Override", suportados por alguns servidores, mas não levado em consideração no CDN. Por exemplo, você pode alterar o método “GET” original para o método “DELETE”, que é proibido no servidor, ou para o método “POST”, que não é aplicável para estática;
- HHO (HTTP Header Oversize) - um invasor pode selecionar o tamanho do cabeçalho para que exceda o limite do servidor de origem, mas não se enquadre nas restrições do CDN. Por exemplo, o Apache httpd limita o tamanho do cabeçalho a 8 KB, e o Amazon Cloudfront CDN permite cabeçalhos de até 20 KB;
- HMC (HTTP Meta Character) - um invasor pode inserir caracteres especiais na solicitação (\n, \r, \a), que são considerados inválidos no servidor de origem, mas são ignorados no CDN.
O mais suscetível a ataques foi o CloudFront CDN usado pela Amazon Web Services (AWS). A Amazon já corrigiu o problema desativando o cache de erros, mas os pesquisadores levaram mais de três meses para adicionar proteção. O problema também afetou Cloudflare, Varnish, Akamai, CDN77 e
Rapidamente, mas o ataque através deles é limitado a servidores alvo que usam IIS, ASP.NET,
Como solução alternativa para bloquear um ataque no lado do site, você pode usar o cabeçalho “Cache-Control: no-store”, que proíbe o cache de resposta. Em alguns CDNs, por ex.
CloudFront e Akamai, você pode desativar o cache de erros no nível das configurações do perfil. Para proteção, você também pode usar firewalls de aplicativos da web (WAF, Web Application Firewall), mas eles devem ser implementados no lado CDN na frente dos hosts de cache.
Fonte: opennet.ru