Ataques SSRF explicados: como o DNS é explorado

A falsificação de requisição no servidor (SSRF, de server-side request forgery) acontece quando um atacante faz um servidor enviar uma requisição HTTP (ou de outro protocolo de rede) em seu nome, para um destino escolhido por ele, e não pelo desenvolvedor da aplicação. Um vetor clássico: um recurso que busca uma URL informada pelo usuário (uma importação de imagem, o destino de um webhook, uma prévia de link), e o atacante informa uma URL que aponta para a infraestrutura interna em vez de um recurso público.

Onde o DNS entra no ataque

A defesa ingênua é verificar se o hostname da URL informada parece um endereço interno. Isso é contornado com facilidade: o atacante registra um domínio público, aponta o registro DNS dele para um IP interno e entrega ao seu servidor um hostname de aparência perfeitamente normal. A sua validação enxerga um domínio, e não um IP: a parte perigosa só aparece depois que a resolução de DNS acontece, o que muitas vezes ocorre dentro da biblioteca de cliente HTTP que faz a requisição de fato, bem depois de qualquer etapa de validação inicial.

Como é uma proteção de verdade

• Resolva o hostname você mesmo, de forma explícita, antes de fazer qualquer requisição: não deixe um cliente HTTP resolvê-lo de forma invisível em seu nome.
• Verifique cada endereço resolvido (todos eles: um domínio pode retornar vários) contra uma lista de bloqueio de endereços privados, de loopback, link-local e de metadados de nuvem.
• Rejeite a requisição se qualquer endereço resolvido não for permitido, em vez de verificar apenas o primeiro retornado.
• Valide de novo no momento da requisição, e não só no momento da entrada, para fechar a brecha do DNS rebinding descrita separadamente: na prática, SSRF e rebinding costumam ser combinados.

Os endpoints de metadados de nuvem merecem destaque aqui: na maioria dos provedores de nuvem, uma requisição feita de dentro de uma VM para um endereço link-local específico pode retornar credenciais, metadados da instância ou configurações que nunca deveriam ser alcançáveis de fora da máquina. A combinação de SSRF com um endpoint de metadados como alvo é uma das cadeias de exploração mais comuns e de maior impacto no mundo real, e ela começa, todas as vezes, com um nome de domínio de aparência comum.

Filtros que verificam o texto, e não o endereço, não funcionam

Um endereço IP tem mais representações textuais válidas do que a maioria dos códigos de validação considera. Um filtro escrito como uma comparação de texto com “127.0.0.1” ou “localhost” deixa passar intactas todas as formas alternativas abaixo, porque nenhuma delas se parece com o texto que está sendo procurado.

A única defesa confiável converte primeiro o endereço no seu valor numérico real e avalia a lista de bloqueio com base nele, que é exatamente a abordagem do resolvedor desta ferramenta, em vez de comparar padrões com a forma como o endereço foi escrito. Um resolvedor devolve um endereço normalizado, independentemente de como o registro do hostname original o codificou, e é exatamente por isso que resolver primeiro e validar o resultado resolvido é mais robusto do que tentar validar um texto bruto em todas as formas que um atacante pode escolher para escrevê-lo.

Os redirecionamentos são o outro desvio comum

Até um sistema que resolve e valida corretamente a URL inicial ainda pode ser surpreendido por um redirecionamento HTTP. Uma requisição para uma URL pública e aprovada pode responder com um 302 apontando para um endereço interno, e um cliente HTTP que segue redirecionamentos automaticamente (o comportamento padrão da maioria das bibliotecas) fará essa segunda requisição sem nenhum problema, sem nunca repetir a validação que passou na primeira vez. Qualquer defesa contra SSRF que valida uma única vez, logo no início, e depois deixa o cliente HTTP lidar com os redirecionamentos por conta própria tem uma brecha exatamente do mesmo formato da que a resolução de DNS cria, e a correção também é a mesma: validar de novo, de forma explícita, antes de seguir qualquer redirecionamento, em vez de confiar que uma URL que passou uma vez continuará apontando para algum lugar seguro.