SSRF DNS Rebinding Case Study
A imagem mostra quando eu tive acesso à uma instância da AWS de uma empresa através de DNS Rebinding como bypass de um SSRF que possuía algumas proteções. Foi dahora ver na prática isso.
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 [Photo]