Uma chave de certificado da eMudhra era o número 4 e permitia falsificar qualquer site

A chave secreta por detrás de um dos certificados que atestam a identidade de um site era o número quatro. Não era um número aleatório comprido que, por acaso, começava por quatro: era simplesmente quatro. Outras sete chaves da mesma autoridade certificadora indiana, a eMudhra, eram quase tão pequenas, e qualquer pessoa que as tivesse podia emitir um certificado para qualquer site — de um banco a um serviço de email — que os programas que confiam na eMudhra aceitariam como legítimo.

São esses certificados que o cadeado do navegador verifica. Com um certificado falsificado, um atacante que se interponha entre si e a internet — numa rede Wi-Fi de um café, através de um router pirateado ou numa rede nacional hostil — pode fazer-se passar pelo site verdadeiro e ler ou alterar o que envia. O Chrome, o Firefox, o Safari e as plataformas da Microsoft já deixaram de confiar nos oito certificados. Mas muitos outros programas nos seus dispositivos ainda não o fizeram.

Uma chave normal deste tipo é um número aleatório com cerca de 384 bits, o que corresponde a aproximadamente 10 elevado a 115 possibilidades. As chaves da eMudhra tinham entre 3 e 8 bits: 4, 56, 66, 115, 155, 156, 230 e 237, segundo a lista publicada pela Ars Technica. O investigador de segurança Scott Helme escreveu que recuperou as oito a partir dos certificados públicos existentes no seu portátil, «e demorou menos de um segundo». Mais tarde, acrescentou que o Claude, da Anthropic, fez o mesmo com uma única instrução.

Ninguém precisou de roubar fosse o que fosse. Na resposta enviada à Mozilla, noticiada pelo BleepingComputer, a eMudhra atribuiu o problema a um erro no script utilizado durante o processo de geração das chaves: o script criou um segundo conjunto de chaves, fraco, e os funcionários escolheram-no por engano, porque os rótulos eram semelhantes. A empresa, que afirma ter emitido mais de 60 milhões de certificados digitais, disse à Mozilla que a maioria dos certificados intermédios afetados nunca chegou a ser utilizada em produção e que não encontrou provas de que tenham sido usados para assinar certificados destinados a utilizadores finais. Revogou os oito e suspendeu a emissão de certificados ao abrigo da raiz afetada.

Os navegadores são a parte fácil. O Chrome, o Firefox e o Safari distribuem silenciosamente listas de revogação aos utilizadores e exigem também que todos os certificados constem de registos públicos de transparência de certificados. Como nunca apareceu nesses registos nenhum certificado de site associado a estas chaves, os navegadores atualizados não estiveram, por defeito, expostos. A falha está em todo o resto. Ferramentas de linha de comandos, como o curl; linguagens como Python, Node e Go; clientes VPN; contentores Docker e dispositivos domésticos inteligentes têm as suas próprias listas de autoridades de confiança, raramente verificam a revogação e ignoram os registos de transparência. Helme criou um certificado falso para a API de pagamentos da Stripe e descobriu que o curl, o Python e o Node o aceitaram em todos os computadores com Linux e macOS que testou.

«Isto vai dar imenso trabalho a limpar, mais do que o Heartbleed», disse à Ars Technica Filippo Valsorda, responsável pela manutenção do código de criptografia da linguagem Go, recordando a falha do OpenSSL cuja resolução levou anos. Valsorda prevê «uma cauda muito, muito longa» de dispositivos IoT, contentores Docker, computadores Linux esquecidos e ferramentas sem manutenção que incluem a sua própria cópia das raízes de confiança. Para explorar as chaves, continua a ser necessário que o atacante esteja no percurso da rede, o que põe essa possibilidade ao alcance de governos, de quem comprometa a rede de um escritório ou de quem opere um ponto de acesso público. O Signal, o WhatsApp e o WireGuard não são afetados, uma vez que não dependem destes certificados para a sua encriptação, observa a Ars.

As chaves podiam ser recuperadas desde o dia em que os certificados foram criados, em abril de 2025, num período de cerca de 17 meses, e não há forma de saber se alguém as utilizou contra programas que não fazem a verificação de transparência. Em maio de 2025, todos os certificados foram também assinados cruzadamente pela raiz AAA Certificate Services da Sectigo, o que alargou o conjunto de sistemas que confiavam neles.

Para a maioria das pessoas, a solução passa por instalar as atualizações. Um investigador comunicou o problema aos fabricantes de navegadores a 17 de outubro. Nesse mesmo dia, a Mozilla bloqueou os certificados no Firefox no espaço de três horas; a 20 de outubro, lançou o Firefox 158.0.1, novas versões ESR e o NSS 3.131.1, que remove a raiz da eMudhra. Segundo o site do incidente, mantido pelo engenheiro da Mozilla Dennis Jackson, a Apple acrescentou proteções a 19 de outubro e a Microsoft a 20 de outubro, embora a Ars tenha constatado, quando publicou a notícia, que o Edge no Windows 10 ainda se ligava aos servidores de teste. Já estão disponíveis o Go 1.27.3 e o 1.26.10, o pip 26.2.2, o uv 0.13.4 e o certifi 2026.10.19; a Cloudflare atualizou as aplicações WARP e 1.1.1.1, e as distribuições Linux continuam a disponibilizar novos pacotes ca-certificates. O curl incluído no macOS continua a confiar nas chaves até que o respetivo ficheiro de certificados seja editado manualmente.

O Chrome confirmou que a raiz da eMudhra será removida do Chrome Root Store na versão 43. Até que todos os dispositivos estejam atualizados, oito bits separam muitos programas usados no dia a dia de uma imitação convincente de qualquer site.

Etiquetas: cibersegurança, Mozilla, Firefox, certificados TLS, eMudhra, encriptação