Google denuncia sequestro de DNS: certificados TLS para google.com.gh, google.sl e google.as

O Google informou em 6 de outubro que atacantes conseguiram emitir certificados de HTTPS não autorizados para nomes do Google e YouTube após comprometer registros DNS autoritativos de três domínios de nível superior com código de país: .gh (Ghana), .sl (Sierra Leone) e .as (American Samoa). De acordo com os registros públicos de Certificate Transparency (CT), entre 22 e 27 de setembro, foram adicionados pelo menos doze certificados para variantes desses nomes (por exemplo, google.com.gh, google.sl e google.as); Let's Encrypt emitiu onze e ZeroSSL emitiu um. O Google esclarece que seus próprios sistemas internos não foram violados; a via de ataque foi a manipulação de DNS nesses ccTLD.

Em termos técnicos, o que aconteceu é um tipo clássico de sequestro de zona DNS: os atacantes mudaram os registros autoritativos que indicam que servidores respondem por um domínio. As autoridades certificadoras (CAs) verificam o controle sobre um nome de domínio antes de emitir um certificado e uma forma habitual de verificação é exigir que quem solicita o certificado coloque um registro DNS específico ou sirva um token em um URL do domínio. Ao tomar controle da área DNS autoritativa, os atacantes puderam responder a esses testes e obter assim certificados válidos emitidos por CAs legítimas. Com um certificado válido em mão, um atacante capaz de interceptar tráfego (por exemplo, numa rede Wi-Fi pública ou através de um roteamento malicioso) pode apresentar o certificado e estabelecer ligações cifradas aparentemente legítimas, permitindo ler ou manipular dados confidenciais.

Atos verificados: O Google bloqueou os certificados não autorizados no Chrome usando CRLSets — o mecanismo rápido de bloqueio de certificados de emergência do navegador — e trabalhou com as CAs para revogar os certificados, de acordo com o seu comunicado. Os registros de CT mostram as entradas e as revogações; pesquisas em serviços públicos como ctlogs. dev e ferramentas de monitoramento como Cert Spotter confirmaram a presença e posterior revogação das pegadas registradas. O Google também disse que detectou indícios de que outras organizações —marcas e serviços amplamente usados — foram afetadas pelo mesmo padrão, embora não as identificou publicamente.

O que continua incerto e não confirmado pelo Google inclui se algum desses certificados foi realmente usado em ataques ativos contra usuários para ler dados, identidade dos atacantes, método exato pelo qual se comprometeram os registros DNS de cada ccTLD e se as registrarias ou registros desses ccTLD foram completamente remediados. O Google também observou que, devido à complexidade dos sequestros DNS, não pode garantir que sua análise tenha detectado todos os domínios afetados.

O incidente expõe várias vulnerabilidades na cadeia de confiança do ecossistema TLS/DNS. Primeiro, a emissão de certificados baseada em testes de controle de domínio (domain validation) depende da integridade do sistema DNS: se o sinal de controle pode ser falsificado por um sequestro de zona, a CA pode legitimamente emitir um certificado a um atacante. Segundo, as CAs podem reusar verificações de controlo prévias para acelerar as emissões subsequentes; as regras do Baseline Requirements (do CA/Browser Forum) fixam prazos para essa reutilização que serão reduzidas nos próximos anos, e alguns fornecedores como Let's Encrypt já anunciaram mudanças nos seus prazos de reuse. Esses detalhes explicam por que um controle de domínio temporário pode derivar em certificados válidos durante dias.

As consequências reais variam por papel: para usuários finais, o risco principal é um ataque de homem-em-médio que apresente um desses certificados e descifre tráfego aparentemente cifrado. Para operadores de domínios e fornecedores de serviços, a consequência é perda de controle e possível suplantação de serviços; além disso, a necessidade de auditar rapidamente CT logs, revogar certificados e verificar a integridade das zonas DNS. Para as CAs, o sucesso obriga a rever procedimentos de validação e a acelerar políticas que reduzam a janela de reuso de verificações de domínio.

O Google e os CAs tomaram medidas concretas e visíveis: bloqueio no Chrome mediante CRLSets e pedidos de revogação às CAs emissoras. No entanto, o Google advertiu que as proteções do Chrome não são suficientes para todos os navegadores e que os proprietários de domínios não devem confiar apenas no navegador para proteger seus usuários.

Recomendações práticas e específicas (quem deve fazer o que): proprietários de domínios sob qualquer um desses ccTLD ou com subdomínios regionais devem immediately Auditar registros de Certificate Transparency para todas as variantes de seus nomes - incluindo domínios estacionados e regionais - usando serviços de monitoramento de CT e revisar qualquer certificado não solicitado. Públique CAA(Certification Authority Authorization) estrita que limite que CAs podem emitir certificados para seu domínio e, quando a CA o permitir, assócie-a à sua conta nessa CA para reduzir riscos. Repórteres imediatos de qualquer emissão não autorizada à CA emissora por um Certificate Problem Report; as CAs são obrigadas a investigar e responder em prazos curtos segundo as regras do sector.

Além disso, e embora o Google já o sugeriu indiretamente, os administradores de DNS e responsáveis por registro devem verificar credenciais e acessos às suas contas de registrador e aos servidores de nomes autoritativos: active autenticação multifator nas contas de registrador, aplique locks de transferência, verifique mudanças nos servidores de nome e registre alertas de mudanças de SOA/serial. Implemente ou verifique DNSSEC em suas zonas quando possível; DNSSEC não é uma panaceia nem sempre está disponível para todos os ccTLD, mas adiciona uma camada que dificulta manipulações em rota da informação de delegação. Finalmente, reduza a janela de confiança em validações de domínio onde a sua CA o permita (por exemplo, usar CAs que não reussem verificações por longos períodos).

Para usuários finais, a recomendação imediata é manter navegadores e sistemas atualizados: o Chrome já bloqueou os certificados afetados, mas outros navegadores podem demorar mais em receber revogações e atualizações. Evite redes Wi-Fi públicas não confiáveis e, se você gerencia informações sensíveis, considere usar redes privadas ou VPNs confiáveis enquanto pesquisas continuam.

Por último, este incidente sublinha a importância da monitorização constante: Certificate Transparency é uma ferramenta pública que permite detectar emissões invulgares, mas só funciona se os proprietários a usam. Documentação e recursos sobre CT e vigilância pública estão disponíveis na página oficial de Certificate Transparency e em serviços de monitoramento como Cert Spotter; que administram domínios devem integrá-los em seus processos de segurança. Mais informações técnicas sobre CT e recursos para começar podem ser consultadas em certificate-transparency.org e a documentação do Cert Spotter.