Falha na eMudhra expõe chaves de 8 autoridades e derruba CAs

Segurança Digital

Vulnerabilidade na eMudhra compromete certificados importantes e ameaça a segurança de emissões TLS e de código.

Leia também: Startup de IA ASI capta US$ 325 mi e vale US$ 3 bi

Uma falha grotesca na geração de chaves criptográficas na autoridade certificadora eMudhra permitiu que um pesquisador de segurança recuperasse instantaneamente as chaves privadas de oito certificados intermediários usados para emitir certificados TLS e de assinatura de código em todo o mundo. A descoberta levou Apple, Google, Microsoft e Mozilla a bloquear de forma emergencial essas CAs nos navegadores, mas deixou exposto o enorme passivo de softwares e sistemas que não verificam revogação nem transparência de certificados.

Chave de autoridade certificadora era literalmente o número 4

O pesquisador Ian Carroll descobriu que as chaves privadas de oito autoridades intermediárias da eMudhra, todas baseadas em criptografia de curva elíptica P-384, não eram números aleatórios gigantes, como manda o padrão, mas valores minúsculos como 4, 56 e 115. Na prática, isso derruba o principal pilar de segurança da infraestrutura de chaves públicas.

Na curva P-384, a chave privada é um único número, chamado d, e a chave pública é obtida multiplicando d por um ponto fixo da curva, conhecido como G. “These are elliptic-curve keys on the P-384 curve. The private key is just a number, d. The public key, the thing that goes in the certificate for the world to see, is d × G, where G is a fixed point on the curve that everyone uses and ‘×’ means adding G to itself d times using the curve’s special arithmetic”, explicou Carroll.

Em condições normais, d deve ser um número aleatório de 384 bits, o que gera cerca de 2³⁸⁴ possibilidades — um espaço tão grande que torna inviável tentar todos os valores. Nos certificados da eMudhra, porém, a chave privada era composta por 47 bytes de zeros seguidos de apenas 1 byte significativo. Ou seja, havia só 256 candidatos possíveis. Bastava calcular 1 × G, 2 × G, 3 × G e assim por diante até, no máximo, 255 vezes para encontrar o valor correto.

Foi o que Carroll fez: ele baixou os certificados públicos e, em menos de um segundo, em um laptop comum, recuperou as oito chaves privadas intermediárias.

Entenda o contexto

Os oito certificados comprometidos eram intermediários criados em abril de 2025 para a eMudhra: seis autoridades emissoras TLS (validação de domínio, de organização e estendida, duas gerações de cada) e duas autoridades de assinatura de código. Em maio de 2025, todas foram ainda cross-sinadas pela raiz AAA Certificate Services, da Sectigo, o que ampliou o alcance de confiança dessas chaves em sistemas e navegadores.

Com as chaves privadas de intermediárias em mãos, um atacante poderia forjar certificados aparentemente válidos para qualquer site ou software, simulando conexões HTTPS legítimas e assinaturas de código confiáveis. Isso abre espaço para ataques de interceptação de tráfego, roubo de credenciais, espionagem corporativa e distribuição de malware disfarçado de atualização oficial.

Carroll resume a gravidade de forma direta: “Normally when a CA key is compromised, someone stole it! There’s a thief, there’s a moment it happened, and you can at least reason about who now has access to that key. Here, nobody had to steal anything. The key was effectively public from the day the certificate existed.”

Segundo o pesquisador, qualquer pessoa que tivesse olhado para um desses certificados em qualquer momento desde a emissão, há 17 meses, poderia ter repetido o procedimento e chegado às chaves privadas em milissegundos, sem acesso especial e sem equipamento sofisticado.

Como a falha ficou escondida por 17 meses?

A vulnerabilidade passou despercebida por 17 meses porque, do ponto de vista estrutural, os certificados pareciam perfeitamente válidos. A chave pública gerada a partir de d = 4, por exemplo, é um ponto matematicamente correto na curva P-384 e passa por todas as verificações automáticas de formato e consistência usadas em auditorias e ferramentas de validação.

O único jeito de notar algo errado era tentar o caminho inverso: assumir que d poderia ser pequeno e testar valores até encontrar coincidência com a chave pública. Como ninguém espera que uma autoridade certificadora use uma chave privada com apenas 8 bits efetivos de entropia, esse tipo de checagem não faz parte dos procedimentos normais.

Depois da publicação inicial do caso em uma discussão pública de políticas de segurança, a eMudhra informou, em relatório técnico anexado a um bug aberto pela Mozilla, que a origem do problema foi um erro em script usado na cerimônia de geração de chaves. De acordo com o relato, um segundo par de chaves fracas foi criado acidentalmente no módulo de segurança de hardware (HSM) e, por terem nomes semelhantes, um erro humano levou ao uso das chaves erradas na requisição de certificação.

O episódio também expôs o papel de ferramentas de inteligência artificial na segurança ofensiva: Carroll relata que conseguiu fazer um agente de IA reproduzir o ataque com um único comando. “I can also confirm that a simple prompt in an AI agent allowed me to recover the private keys of the CA. Claude was able to recover the private keys with a single prompt”, escreveu.

Navegadores agem rápido, mas só eles

O pesquisador comunicou a falha no sábado, 17 de outubro, a Apple, Google, Microsoft, Mozilla e à própria eMudhra. Na mesma noite, o Chrome passou a bloquear os oito intermediários vulneráveis por meio do mecanismo CRLSet, que distribui listas de revogação emergenciais aos usuários. Poucas horas depois, a Mozilla fez o mesmo no Firefox, via OneCRL.

Na terça-feira, 20 de outubro, a Mozilla tornou pública a análise do incidente, anexou os certificados afetados e distribuiu uma atualização da biblioteca NSS removendo a raiz da eMudhra do armazenamento de confiança. O time do Chrome confirmou que a raiz também será excluída em uma próxima versão do Chrome Root Store.

A equipe do navegador do Google ressaltou ainda o papel da Transparência de Certificados (Certificate Transparency, CT) na contenção de danos. “Because Chrome enforces Certificate Transparency, and no TLS certificates chaining to these CAs ever showed up in CT, no forged certificate could have been trusted by default in Chrome”, escreveu o time. Na prática, isso significa que, até aqui, não há registro de certificados TLS falsos emitidos com essas chaves sendo aceitos nativamente pelos principais navegadores.

Esse alívio, porém, vale basicamente para softwares de navegação modernos que exigem CT e recebem listas de revogação em tempo quase real, como Chrome, Firefox e Safari.

Fora do navegador, ecossistema segue vulnerável

Em clientes TLS que não são navegadores — como bibliotecas de programação, ferramentas de linha de comando e serviços em segundo plano — o cenário é bem diferente. A grande maioria desses sistemas confia em pacotes locais de autoridades certificadoras, não checa listas de revogação por padrão e ignora completamente logs de CT.

Em testes descritos pelo pesquisador, ferramentas como curl, ambientes Python, Node, Go, Java, o próprio git e gerenciadores de pacotes aceitaram sem questionar certificados emitidos a partir das chaves comprometidas, incluindo para domínios de alto valor, como api.stripe.com, quando usadas em servidores de teste locais. Em máquinas Linux e macOS avaliadas, o handshake TLS foi concluído normalmente; no Windows, a cadeia foi aceita pela CryptoAPI sempre que a verificação de revogação não estava ativada manualmente.

Isso significa que, em data centers, ambientes corporativos, scripts de automação e dispositivos embarcados que não recebem atualizações frequentes do pacote de CAs, um atacante com acesso à rede poderia forjar certificados “perfeitamente válidos” à primeira vista, interceptando ou alterando tráfego supostamente protegido por HTTPS ou por assinaturas de código confiáveis.

Setores intensivos em tecnologia — como bancos, comércio eletrônico e empresas SaaS — estão entre os mais expostos, justamente por dependerem de integrações máquina a máquina que usam clientes TLS fora do navegador e raramente implementam checagem de CT ou mecanismos modernos de revogação, como CRLite.

Próximos passos: limpar as lojas de confiança

Com a remoção da raiz da eMudhra dos principais navegadores já em andamento, a atenção agora se volta aos bundles de autoridades certificadoras distribuídos em sistemas operacionais, distribuições Linux, runtimes de linguagem e aplicações corporativas. Será necessário atualizar esses conjuntos de CAs confiáveis para excluir as intermediárias afetadas e, em muitos casos, toda a cadeia da eMudhra.

Especialistas em segurança defendem também uma adoção mais ampla de mecanismos como Certificate Transparency fora do mundo dos browsers, além de políticas de revogação efetivas em clientes TLS genéricos. O caso reforça a importância de auditorias contínuas na geração de chaves por autoridades certificadoras e da validação independente das práticas dessas entidades por grandes fabricantes de software.

Enquanto isso, administradores de sistemas e equipes de segurança são orientados a revisar urgentemente quais raízes e intermediárias estão presentes nos repositórios de confiança de servidores, aplicações internas, appliances de rede e dispositivos IoT, e a aplicar as atualizações de fornecedores assim que forem disponibilizadas.

Fonte: matéria original