O que é DNS rebinding e por que você deveria se importar?

A maioria das verificações de segurança que envolvem um domínio presume que o endereço IP dele é estável o bastante para ser validado uma vez e depois considerado confiável. O DNS rebinding explora exatamente essa suposição. Um atacante controla o DNS de um domínio e o configura para resolver, a princípio, para um endereço IP público normal, passando por qualquer validação que o sistema-alvo faça, e depois muda a resposta para um endereço interno (como 127.0.0.1 ou uma faixa interna 10.x.x.x) em uma requisição posterior, quando a verificação já foi aprovada.

Por que isso é mais do que um truque teórico

Um TTL muito curto torna o ataque viável: o atacante define o registro para expirar em poucos segundos, de modo que uma verificação de validação e a requisição real que vem logo depois podem ver duas respostas diferentes, com milissegundos de diferença, sem que o sistema da vítima perceba que o chão mudou sob seus pés. Qualquer sistema que resolva um domínio uma única vez e reutilize esse IP em várias operações, ou, pior, que o resolva uma vez para a validação e deixe outra parte resolvê-lo de novo para a requisição real, está potencialmente exposto.

A única defesa confiável

Validar a string do nome de host não basta, e validar um IP uma única vez também não. A única defesa robusta é verificar o endereço realmente resolvido contra uma lista de bloqueio de faixas privadas e internas no ponto em que a conexão é de fato feita, todas as vezes, e não apenas na validação inicial. Isso fecha a janela de tempo da qual o rebinding depende, porque deixa de existir um intervalo entre “verificado” e “usado” em que a resposta possa mudar.

• Bloqueie as faixas privadas (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), de loopback (127.0.0.0/8), link-local (169.254.0.0/16) e os endpoints de metadados de nuvem, tanto em IPv4 quanto em IPv6.
• Verifique de novo a cada uso, e não apenas uma vez, na validação da entrada.
• Trate um endereço IPv6 mapeado de IPv4 (como ::ffff:127.0.0.1) como equivalente ao endereço IPv4 embutido nele: as tentativas de rebinding às vezes usam exatamente essa codificação para escapar de uma verificação ingênua feita apenas para IPv6.

Onde isso já importou na prática

O DNS rebinding não é uma preocupação acadêmica de nicho: ele já foi usado repetidas vezes contra roteadores domésticos, hubs de casa inteligente e outros dispositivos que expõem uma interface administrativa local sem autenticação, partindo do princípio de que só o tráfego local confiável poderia alcançá-la. Uma página web maliciosa, aberta em uma aba comum de navegador na mesma rede, pode usar o rebinding para fazer o próprio navegador da vítima, que o roteador já considera confiável só por estar na rede local, enviar requisições diretamente a essa interface administrativa em nome do atacante. O navegador acha que está falando o tempo todo com o domínio público original; só a resposta de DNS por baixo é que mudou.

Uma variante mais sutil: rebinding com várias respostas

Uma versão mais sofisticada dispensa por completo a espera pela expiração de um TTL. Uma única resposta de DNS pode, legitimamente, conter mais de um registro A, e alguns clientes simplesmente os tentam em ordem ou até alternam entre eles, em rodízio, ao longo de requisições diferentes. Um atacante pode retornar, na mesma resposta, tanto um endereço público legítimo quanto um interno, contando que o cliente acabe tentando a segunda entrada: sem espera, sem janela de tempo, apenas explorando o fato de que o DNS nunca foi projetado para garantir que todos os endereços de uma resposta com várias entradas sejam igualmente confiáveis. É um bom lembrete de que “verificar o primeiro endereço retornado” nunca é suficiente; todo endereço de uma resposta exige o mesmo escrutínio.