Tell HN: Microsoft.com adicionou 192.168.1.1 ao seu registro DNS

Discussão no Hacker News ↗

Uma configuração incorreta adicionou brevemente endereços IP privados (192.168.1.0/1) aos registros DNS públicos de microsoft.com, o que significa que as solicitações de alguns usuários podiam resolver para seus próprios roteadores domésticos ou dispositivos locais em vez dos servidores da Microsoft. Os comentaristas exploram o impacto operacional (timeouts, perda parcial de tráfego, fallback para IPv6), as implicações de segurança em torno de DNS rebinding e emissão de certificados, e como um erro desses poderia passar pelo controle de mudanças em uma grande empresa. O incidente também provoca reflexões mais amplas sobre mecanismos de segurança do DNS, proteções do lado do resolvedor contra respostas com endereços privados e salvaguardas organizacionais para evitar erros semelhantes.

O que Aconteceu

  • microsoft.com por um breve período teve registros A apontando para 192.168.1.1 e 192.168.1.0, ambos endereços privados RFC1918.
  • Muitos usuários confirmaram ter visto esses registros por meio de consultas DNS; um endereço desapareceu primeiro, o outro permaneceu por mais tempo.
  • Os registros incorretos foram posteriormente removidos dos servidores de nomes autoritativos, mas os resolvedores públicos levaram tempo para limpar seus caches.

Efeitos Imediatos & Impacto no Usuário

  • Com 2 de 7 registros A sendo IPs privados, alguns clientes resolveram microsoft.com aleatoriamente para dispositivos locais (frequentemente roteadores domésticos ou impressoras).
  • Os sintomas incluíam timeouts, falhas de conexão ou a abertura da página de administração do roteador em vez do site da Microsoft.
  • Algumas configurações de DNS (por exemplo, com proteção contra DNS rebinding) bloquearam as respostas, tornando microsoft.com efetivamente apenas IPv6 ou inacessível nessas redes.

Preocupações de Segurança & Modelos de Ameaça

  • Vários comentários enfatizaram que isso é principalmente um risco para a Microsoft, não para as redes dos usuários finais.
  • Riscos potenciais discutidos:
    • Se um agente malicioso tivesse controlado um IP público em vez de um privado, poderia ter interceptado parte do tráfego ou tentado phishing.
    • Possibilidade de usar validação de domínio baseada em HTTP para obter certificados, embora isso exigisse controle significativo e roteamento correto do tráfego.
  • Outros apontaram proteções: HTTPS, atualizações assinadas e servidores DNS que rejeitam IPs privados em respostas públicas como defesas contra DNS rebinding.
  • Alguns observaram que o uso indevido de microsoft.com dessa forma poderia ter sido mais perigoso se cuidadosamente planejado por um atacante ou ator estatal.

Como Isso Pode Ter Acontecido? (Especulação Dentro do Fio)

  • As teorias incluíam: erro de copiar e colar, bugs de automação ou IaC, configs de dev/test vazando para produção, ou falhas gerais de ClickOps/processo.
  • Alguns duvidaram que pessoal de nível inicial pudesse alterar uma zona tão crítica, sugerindo um pipeline mais complexo ou uma falha de revisão.

Processo, Cultura e Lições

  • Apelos por melhores salvaguardas: validação para bloquear RFC1918 em grandes zonas públicas, revisões com controle duplo e verificações automatizadas.
  • Reações mistas: alguns veem isso como um erro inofensivo, mas embaraçoso; outros o encaram como uma falha séria de processo para uma dependência central da internet.