dns-rebinding-attacks

Sobre dns-rebinding-attacks

Um guia de ataque de rebinding de DNS focado na técnica do lado do cliente para contornar a política de mesma origem do navegador, alterando o endereço IP por trás de um nome de host que a vítima já tenha carregado. A ideia central é que a política de mesma origem verifica a string do nome de host, e não o endereço IP resolvido: um invasor que controla o DNS autoritativo de seu domínio pode servir um JavaScript malicioso na primeira resolução (IP do invasor) e, em seguida, resolver novamente o mesmo nome de host para um IP interno; assim, o navegador trata as solicitações ao serviço interno como sendo da mesma origem, e o script pode ler as respostas.

Isso esclarece a distinção em relação ao SSRF, já que o rebinding de DNS é a contraparte do lado do cliente, e detalha os obstáculos práticos e as soluções alternativas. Como os navegadores mantêm seu próprio cache de DNS que ignora TTLs baixos (aproximadamente 60 segundos no Chrome, Edge e Firefox), o artigo documenta estratégias de contorno, incluindo aguardar o esvaziamento do cache, respostas com múltiplos registros A com bloqueio do IP do invasor para forçar o fallback, inundação de subdomínios para novas resoluções e atrasos no service worker. As variantes de ataque incluem o rebinding HTTP clássico, o rebinding via WebSocket, um híbrido TOCTOU do lado do servidor e a abordagem rápida de registros A múltiplos.

Utilize-a ao testar aplicativos que confiam no DNS para verificações de origem ou que realizam fetch/XHR do lado do cliente para domínios controlados pelo invasor, especialmente quando o SSRF do lado do servidor não é possível. Uma tabela de alvos de alto valor lista metadados de nuvem (169.254.169.254), as APIs do Docker e do Kubernetes, painéis de administração internos, Elasticsearch, Redis e Consul/etcd, com uma observação de que a exigência de token do IMDSv2 resiste à reatribuição, pois cabeçalhos personalizados não podem ser facilmente definidos no modo no-cors. A cobertura de ferramentas inclui o Singularity, o serviço rbndr.us sem necessidade de configuração (com formato de subdomínio IP hexadecimal), o whonow e servidores DNS mínimos em Python, além de fazer referência cruzada às técnicas de SSRF e de configuração incorreta de CORS.

Perguntas frequentes

Em que o rebinding de DNS difere do SSRF?

O SSRF ocorre no lado do servidor, enquanto o rebinding de DNS é sua contraparte no lado do cliente, executada no navegador da vítima. Ele se aproveita do fato de que a política de mesma origem verifica a string do nome do host, e não o IP resolvido.

Por que um TTL de 0 não funciona imediatamente?

Os navegadores mantêm seu próprio cache de DNS que ignora TTLs baixos (cerca de 60 segundos no Chrome, Edge e Firefox); por isso, a habilidade abrange formas de contornar essa limitação, como espera, vários registros A com fallback, inundação de subdomínios e atrasos no service worker.

Quais são os alvos internos de alto valor?

Metadados na nuvem em 169.254.169.254, a API do Docker, a API do Kubernetes, painéis internos de administração, Elasticsearch na porta 9200, Redis na porta 6379 e Consul/etcd.

O rebinding consegue roubar credenciais da AWS a partir do IMDSv2?

Não é fácil. O IMDSv2 exige um cabeçalho `X-aws-ec2-metadata-token` em uma solicitação PUT, e o rebinding não consegue definir facilmente cabeçalhos personalizados na solicitação inicial do token no modo no-cors. O IMDSv1 está mais exposto.

Quais ferramentas são recomendadas?

Singularity (uma estrutura completa), rbndr.us (sem configuração, usando subdomínios com pares de IP hexadecimais), whonow (um servidor de rebinding dinâmico) e servidores DNS minimalistas personalizados em Python.