Sequestro de domínios do Google: entenda o ataque DNS

Sequestro de domínios do Google: entenda o ataque DNS

Um recente incidente de segurança chamou a atenção da comunidade de infraestrutura e redes ao demonstrar como falhas na cadeia de suprimentos de registros de domínios podem comprometer até mesmo as maiores gigantes de tecnologia. Hackers conseguiram realizar o sequestro de domínios do Google e de diversas marcas globais após comprometerem operadores terceirizados responsáveis por registros de código de país (ccTLDs) de Gana (.GH), Samoa Americana (.AS) e Serra Leoa (.SL). O ataque permitiu a alteração de registros DNS autoritativos e a emissão ilícita de certificados HTTPS válidos.

A engenharia do ataque chama a atenção por não ter exigido a invasão direta dos servidores ou da infraestrutura interna do Google. Em vez disso, os atacantes exploraram o elo mais fraco da corrente: os operadores regionais de registro de domínios superiores. Ao assumir o controle das zonas DNS, os cibercriminosos contornaram os mecanismos tradicionais de validação das Autoridades Certificadoras (CAs), conseguindo emitir certificados TLS legítimos para direcionar usuários a servidores maliciosos com o falso selo de segurança do cadeado verde.

Para mitigar o impacto e conter a ameaça, o Google agiu rapidamente bloqueando proativamente os certificados comprometidos por meio do CRLSets no Google Chrome e analisando logs públicos de Transparência de Certificados (CT). Este caso serve como um alerta crítico para administradores de sistemas, engenheiros DevSecOps e profissionais de segurança sobre os riscos decorrentes de invasões no ecossistema de DNS autoritativo e a urgência de implementar salvaguardas adicionais, como os registros CAA.

Como os atacantes manipularam os registros DNS para emitir certificados HTTPS

Para compreender a gravidade do incidente, é necessário analisar o funcionamento do processo de validação de domínio (DV) utilizado pelas Autoridades Certificadoras (CAs) modernas, como o protocolo ACME (utilizado por entidades como o Let’s Encrypt). Quando uma organização solicita um certificado HTTPS, a CA exige uma prova irrefutável de que o solicitante realmente controla aquele endereço web.

A forma mais comum e automatizada dessa verificação consiste na criação de um registro TXT específico nas zonas do DNS autoritativo do domínio. A CA fornece uma string aleatória de verificação e faz uma consulta pública ao servidor DNS do domínio. Se a resposta contiver o valor esperado, a CA presume que o solicitante é o proprietário legítimo e emite o certificado TLS.

Logo Google

A mecânica da emissão não autorizada de TLS

Os atacantes não precisaram quebrar a criptografia dos certificados e nem comprometer a infraestrutura interna do Google. Em vez disso, eles atacaram os registradores e provedores terceirizados responsáveis por gerenciar os ccTLDs .GH, .SL e .AS.

Com acesso privilegiado aos sistemas do operador de ccTLD, os invasores alteraram as delegações de servidores de nome (NS records) ou injetaram novos registros TXT autoritativos para os domínios afetados. Quando os hackers solicitaram um novo certificado HTTPS para as propriedades do Google nesses domínios específicos, as Autoridades Certificadoras efetuaram a checagem padrão via DNS. Como o DNS autoritativo estava sob controle malicioso, a resposta de validação foi positiva, resultando na emissão de certificados TLS perfeitamente legítimos para os invasores.

O impacto nos domínios afetados

Com o controle do DNS autoritativo e a posse de certificados HTTPS reconhecidos pelos navegadores, os atacantes puderam interceptar e redirecionar o tráfego dos usuários para a infraestrutura por eles controlada. Como o certificado exibido era válido e assinado por uma CA confiável, os navegadores não emitiam nenhum alerta de segurança tradicional para os visitantes.

Esse cenário abriu margem para ataques do tipo Man-in-the-Middle (MitM), onde páginas falsas podiam ser exibidas para capturar credenciais, distribuir malware ou realizar campanhas de phishing altamente sofisticadas personificando o Google e outras grandes marcas atingidas pela mesma brecha.

A resposta do Google e o papel do CRLSets no Chrome

Assim que identificou a anomalia, a equipe de segurança do Google colocou em prática seu plano de resposta a incidentes. A empresa ressaltou publicamente que seus sistemas centrais permaneceram intocados e que as Autoridades Certificadoras agiram de acordo com as regras operacionais vigentes, pois receberam confirmações válidas provenientes das zonas DNS manipuladas.

Para proteger os usuários de forma imediata contra novos ataques aos domínios do Google, a empresa acionou o CRLSets, um mecanismo de emergência integrado ao Google Chrome. O CRLSets permite que o navegador receba atualizações rápidas contendo uma lista restrita de certificados HTTPS revogados ou considerados não confiáveis, sem a necessidade de esperar pelas atualizações tradicionais de sistema operacional ou depender de consultas OCSP (que costumam falhar por questões de latência ou privacidade).

Além disso, os engenheiros da gigante de buscas realizaram varreduras profundas nos registros públicos de Transparência de Certificados (CT). A análise dos logs revelou que o sequestro de DNS do Google não foi um evento isolado, mas sim parte de uma campanha mais ampla que atingiu diversas outras marcas internacionais nos mesmos ccTLDs. Os certificados identificados foram proativamente bloqueados no Chrome, e as organizações afetadas foram notificadas.

Entretanto, o próprio Google emitiu um aviso importante: a proteção via CRLSets é direcionada primariamente ao ecossistema do Chrome. Usuários de outros navegadores que não utilizam a mesma lista de revogação urgente podem continuar expostos aos certificados maliciosos caso as CAs emissoras não atualizem suas listas tradicionais com a rapidez necessária.

Como proteger seus domínios contra ataques de validação DNS

O incidente serve como uma importante lição técnica sobre resiliência de infraestrutura. Depender exclusivamente da segurança do registrador não é suficiente quando atores maliciosos conseguem comprometer níveis mais altos da hierarquia do DNS, como os operadores de ccTLD.

Administrators de sistemas e engenheiros de segurança devem adotar uma postura proativa reforçando a monitoria e utilizando recursos nativos do protocolo DNS.

Recomendações fundamentais para mitigação:

  1. Implementação de registros CAA (Certificate Authority Authorization):O registro CAA é um tipo de recurso DNS (tipo 257) que permite ao proprietário de um domínio especificar explicitamente quais Autoridades Certificadoras têm permissão para emitir certificados em seu nome. Embora o registro CAA possa ser burlado durante um sequestro ativo de DNS, ele impede que CAs não autorizadas reaproveitem validações em cache após o controle do DNS ser restabelecido.
  2. Monitoramento contínuo de Logs de Transparência de Certificados (CT):Ferramentas automatizadas devem monitorar os logs de Certificate Transparency em tempo real para todo o portfólio de domínios da empresa — incluindo domínios inativos ou estacionados (parked domains). Qualquer emissão de certificado não reconhecida gera um alerta imediato para a equipe de SOC.
  3. Uso de DNSSEC (Domain Name System Security Extensions):A assinatura digital das zonas DNS via DNSSEC previne a falsificação e a adulteração de registros por intermediários, garantindo a autenticidade das respostas entregues aos resolvedores.
  4. Habilitação de Registrar Lock e Multi-Factor Authentication (MFA):Garantir que os painéis de controle dos registradores exijam autenticação forte e travas contra transferência ou alteração de servidores de nome (Name Server Locks).

Conclusão: lições sobre a resiliência da infraestrutura Web

O sequestro de domínios do Google através de ccTLDs expõe a fragilidade inerente a um modelo de confiança baseado em múltiplos intermediários globais. A segurança de uma aplicação web de grande porte não depende apenas da robustez de seus próprios servidores, mas também da integridade dos registros mantidos por terceiros na hierarquia do DNS.

A rápida mitigação através do CRLSets e a transparência propiciada pelos logs de CT demonstraram como ferramentas modernas de observabilidade e bloqueio emergencial são vitais para mitigar danos em grande escala.