DigiNotar: a autoridade certificadora hackeada em 2011 e falida

Em agosto de 2011, um usuário do Gmail no Irã abriu o Chrome e viu um alerta: o certificado do Google não era confiável. Ele postou o aviso num fórum de suporte da empresa. Aquele print foi o primeiro sinal público de um dos ataques mais graves à infraestrutura de confiança da web: a invasão da DigiNotar, uma autoridade certificadora holandesa que acabou falindo poucas semanas depois.

O que é uma autoridade certificadora (CA)?

Para que serve o cadeado do HTTPS?

O cadeado do HTTPS indica que a conexão é criptografada e que o certificado do site foi assinado por uma autoridade certificadora em que o seu navegador confia. Se você acessa google.com e o certificado apresentado foi assinado por uma CA da lista do navegador, ele aceita sem perguntar.

O ponto frágil é esse: o navegador confia em dezenas de CAs, e qualquer uma delas pode assinar um certificado para qualquer domínio. Se uma única CA for comprometida, o atacante consegue um certificado válido para o Google, o Gmail ou o seu banco. Era exatamente esse o cenário de 2011. A DigiNotar também emitia certificados usados pelo governo holandês, o que aumentou o estrago.

O que aconteceu na DigiNotar

A auditoria da consultoria Fox-IT (relatório "Operation Black Tulip") reconstruiu o caso. A invasão começou em junho de 2011. O invasor entrou pela DMZ externa, se moveu pela rede interna e chegou aos servidores de certificação. Segundo o relatório final, ele controlou os oito servidores de CA, inclusive o que emitia certificados qualificados para o governo.

• Certificados falsos: a Fox-IT identificou 531 certificados fraudulentos (a contagem pode estar incompleta), para domínios como Google, Microsoft, Twitter e serviços de agências de inteligência.
• Alvo principal: o certificado falso de *.google.com foi usado em ataques de man-in-the-middle contra usuários no Irã. A Fox-IT estimou cerca de 300 mil usuários expostos, em sua maioria de Gmail, número que mede exposição e não contas comprovadamente invadidas.
• Logs adulterados: o serviço de log rodava nos próprios servidores comprometidos, então registros foram alterados e apagados.
• Autoria: segundo a investigação, a assinatura do invasor coincidia com a do ataque à CA Comodo em março de 2011.

As falhas básicas que a auditoria encontrou

Não foi um ataque sofisticado demais para a defesa. A Fox-IT apontou falhas de higiene que qualquer checklist de hardening cobriria:

• Todos os servidores de CA no mesmo domínio Windows, com uma única credencial dando acesso a todos.
• Senha fraca de administrador, passível de força bruta.
• Segmentação só no papel: a rede tinha 24 segmentos, mas regras de firewall permitiam o tráfego entre eles.
• Servidores web desatualizados e sem antivírus.
• Sem log central seguro, o que permitiu apagar rastros.

Parece familiar? É o mesmo padrão de Operação Aurora, de 2010: o invasor não precisa de nada exótico quando a rede interna é plana e as credenciais são fracas.

Como o ataque foi descoberto e o que veio depois

A DigiNotar disse ter detectado a intrusão em julho e revogado certificados, mas sem divulgar o caso, e ainda ficaram certificados fraudulentos fora da lista. O que expôs tudo foi o certificate pinning do Chrome: o navegador já sabia quais CAs podiam assinar certificados do Google e estranhou o certificado da DigiNotar. Foi esse alerta que o usuário iraniano reportou.

A reação veio rápida:

• Mozilla, Microsoft, Google e Apple removeram a DigiNotar da lista de CAs confiáveis.
• O governo holandês assumiu o controle operacional da empresa e passou a tratar os certificados que usava como inseguros.
• Em setembro de 2011, a subsidiária holandesa da Vasco, dona da DigiNotar, pediu falência. Uma CA vive de confiança, e sem ela o negócio acabou.

O que mudou na web depois da DigiNotar?

O caso acelerou duas defesas: Certificate Transparency, que obriga CAs a registrar publicamente cada certificado emitido, e o pinning/monitoramento de certificados nos navegadores. Hoje, um certificado falso do Google emitido por uma CA qualquer tende a aparecer nos logs públicos e ser denunciado rapidamente. Também ganharam espaço o registro CAA no DNS, que limita quais CAs podem emitir para o seu domínio, e a criptografia do próprio DNS, como no DNS sobre HTTPS no Windows 11.

O que você pode fazer

• Não ignore alerta de certificado. Aviso de "conexão não privada" em site conhecido, principalmente em rede alheia, é motivo para parar.
• Mantenha o navegador atualizado. A lista de CAs confiáveis e as proteções de pinning vêm nas atualizações.
• Evite Wi-Fi público sem VPN para login em contas importantes e ative 2FA no Gmail, que reduz o dano de uma senha capturada.
• Se você administra domínios: configure registro CAA e monitore os logs de Certificate Transparency para o seu domínio.

A lição maior

O Heartbleed mostrou que a criptografia pode falhar na implementação. A DigiNotar mostrou o outro lado: a criptografia funcionou perfeitamente, e quem falhou foi a organização que assinava a confiança. Um sistema em que qualquer elo pode responder por qualquer site é tão forte quanto o elo mais mal administrado.

Se quiser aprofundar a história de ataques a infraestrutura de internet, leia sobre o Heartbleed e o ataque ao Google em 2010.

Fontes: relatório Fox-IT "Operation Black Tulip" (interim, set/2011, e final), SecurityWeek, SEC (comunicado da Vasco), Mozilla Bugzilla (bug 684747) e Dark Reading.