Galera, num artigo anterior, detalhei como a técnica de DNS Rebinding é empregada para explorar vulnerabilidades do tipo TOCTOU (Time-of-Check Time-of-Use), subvertendo validações em cenários de Server-Side Request Forgery (SSRF). Fica o link ao final para consulta.
Em um contexto prático: considere uma aplicação com uma funcionalidade de coleta de imagens externas, acessível via um parâmetro como ?url=http://siteexterno.com/imagem.png. Essa funcionalidade foi projetada para interagir com IPs externos.
Qualquer tentativa de fornecer um hostname que resolva diretamente para IPs internos (e.g., 127.0.0.1) ou para o serviço de metadados da instância cloud (e.g., 169.254.169.254) é explicitamente bloqueada pela aplicação, que retorna uma mensagem indicando que domínios resolvendo para tais IPs não são permitidos.
Nesse ponto, o DNS Rebinding se apresenta como uma técnica viável.
O objetivo é induzir a aplicação a, na etapa de check, validar um hostname que resolva para um IP externo permitido (conforme o design da funcionalidade). Subsequentemente, na etapa de use (TOU, que é quando a aplicação efetivamente tenta buscar a imagem), o mesmo hostname deve resolver para o IP do serviço de metadados (169.254.169.254), permitindo a exfiltração de dados sensíveis.
A execução envolve:
Configuração do Domínio Controlado:
Utiliza-se um domínio sob nosso controle (e.g., rebind-target.com) com um servidor DNS configurado para respostas dinâmicas e com um TTL (Time-To-Live) exíguo (e.g., 1 segundo).
Fase de Verificação (Time-of-Check):
Na consulta DNS inicial para rebind-target.com pela aplicação alvo (durante a validação da URL da imagem), nosso servidor DNS responde com um IP externamente roteável (e.g., 8.8.8.8). A aplicação, verificando que este é um IP externo, considera o domínio válido para prosseguir com a coleta da imagem.
Fase de Rebinding e Uso (Time-of-Use):
Imediatamente após a primeira resolução ser atendida, o servidor DNS sob nosso controle altera o registro A/AAAA de rebind-target.com para o IP do serviço de metadados (169.254.169.254). Quando a aplicação procede para estabelecer a conexão HTTP para buscar a "imagem", o TTL baixo provavelmente forçará uma nova consulta DNS, ou o cache local do resolver já terá expirado. Esta nova consulta retornará o IP 169.254.169.254.
Dessa forma, a aplicação estabelece uma conexão com o serviço de metadados, sob a premissa de estar interagindo com um host externo para buscar uma imagem.
Como resultado, os dados retornados pelo serviço de metadados, como um access_token da instância cloud, são exfiltrados e podem ser apresentados na resposta da aplicação que originalmente esperava o conteúdo de uma imagem, efetivamente comprometendo a segurança da instância.
O artigo original aprofunda com cenários de exploração e o impacto real.
Artigo: https://medium.com/@bminossi/dns-rebinding-um-caso-de-race-condition-f0360d94a828
