Uma autoridade certificadora entregou a piada do XKCD
Uma revelação impressionante do pesquisador de segurança "Wayne" em 17 de outubro revelou uma falha profunda na infraestrutura de chave pública: oito certificados intermediários da eMudhra, incluindo autoridades de TLS e de assinatura de código, foram comprometidos. As chaves privadas subjacentes a esses certificados, confiadas pelos principais navegadores e sistemas operacionais por 17 meses, eram números inteiros trivialmente pequenos — um deles, literalmente, o número 4.
Essas chaves dependiam da curva elíptica P-384, que normalmente exige que um private scalar (d) seja um número de 384 bits grande e imprevisível, oferecendo aproximadamente $10^{115}$ possibilidades. Em vez disso, as chaves comprometidas da eMudhra apresentavam 47 bytes iniciais de zero, com o byte final contendo um valor pequeno o suficiente para ser alvo de força bruta em, no máximo, 255 candidatos.
Essa fraqueza catastrófica permitiu a recuperação imediata das chaves privadas. Os valores identificados foram:
- 4
- 56
- 66
- 115
- 155
- 156
- 230
- 237
Apesar de seu tamanho minúsculo, esses números inteiros ainda produzem pontos de chave pública matematicamente válidos na curva. Isso significa que os certificados passaram pelas verificações estruturais padrão, mascarando a fragilidade criptográfica subjacente. O Google Chrome e o Firefox bloquearam rapidamente esses certificados, com a Apple e a Microsoft seguindo o exemplo.
O erro deixou um rastro de papel — e um alarme ignorado
A causa relatada remonta a uma April 2025 key ceremony, onde a eMudhra modificou um script para testar exportações de chaves. Esse script gerou inadvertidamente pares de chaves extras fracos no Hardware Security Module (HSM). Os operadores, enganados por rótulos semelhantes, usaram essas chaves comprometidas para solicitações de certificado, em vez das chaves criptograficamente fortes pretendidas.
Crucialmente, um aviso surgiu em junho de 2025. A Sectigo, a entidade de assinatura cruzada, relatou assinaturas inválidas nas Listas de Revogação de Certificados (CRLs) da eMudhra. Essa incompatibilidade ocorreu porque a eMudhra tentou assinar as CRLs com suas chaves originais fortes, que não correspondiam às chaves fracas incorporadas nos certificados emitidos.
Em vez de investigar a discrepância subjacente, a eMudhra assinou novamente as listas de revogação usando as chaves fracas. Essa solução paliativa ocultou efetivamente o sintoma, permitindo que a falha de segurança fundamental persistisse por mais 16 meses.
Operacionalmente, este incidente destaca duas lições críticas. As cerimônias de chave exigem independent identity and strength checks em todo o material criptográfico gerado. Além disso, qualquer incompatibilidade de assinatura, particularmente em um contexto de infraestrutura de chave pública, deve desencadear uma resposta imediata ao incidente em vez de uma solução paliativa superficial.
Os navegadores tinham salvaguardas. Sistemas de build geralmente não têm
A Sectigo assinou de forma cruzada os intermediários da eMudhra, dando-lhes amplo alcance nos repositórios de confiança das plataformas. O pesquisador Wayne demonstrou controle ao assinar uma mensagem de prova, "We have a problem here", com cada uma das oito chaves comprometidas. Isso confirmou o comprometimento das chaves e destacou o potencial generalizado de uso indevido.
Navegadores como Google Chrome e Mozilla Firefox revogaram rapidamente os certificados, muitas vezes em poucas horas. Eles aplicam logs de Certificate Transparency (CT), registrando publicamente todos os certificados TLS confiáveis. Os navegadores normalmente rejeitam certificados que não estão presentes nesses logs, uma salvaguarda crítica que impediu a exploração direta pelo navegador.
No entanto, clientes que não são navegadores frequentemente carecem dessas defesas robustas. Ferramentas como curl, Python, Node, Go e Git frequentemente dependem de pacotes de CA locais, ignorando completamente verificações de CT ou revogação. Isso os deixa vulneráveis a ataques de machine-in-the-middle (MITM).
Os riscos práticos são substanciais. Um atacante utilizando uma dessas chaves falsificadas poderia visar:
- Chamadas de API
- Scripts de instalação
- CI runners
- Credenciais de nuvem
As duas chaves de assinatura de código comprometidas também levantaram preocupações sobre software falsificado, potencialmente distribuindo atualizações ou aplicativos maliciosos. Para mais detalhes técnicos, consulte o Mozilla Bugzilla: eMudhra Private Key Compromise of Intermediate Certificates.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
Corrija o trust store e, em seguida, teste todo o pipeline
Fornecedores de navegadores e operadores de plataforma agiram rapidamente para desconfiar dos certificados afetados. Apple, Google Chrome, Microsoft e Mozilla bloquearam os intermediários comprometidos em poucos dias, enquanto a Sectigo encerrou seu acordo de cross-signing com a eMudhra. O Go emitiu uma versão de emergência direcionada, a 1.27.3, bloqueando diretamente esses oito intermediários dentro de sua biblioteca padrão.
A cobertura de atualizações de dispositivos e software ainda pode variar, especialmente para sistemas embarcados. Para mitigar o risco, atualize seu sistema operacional e pacotes de CA imediatamente. Atualize runtimes de linguagem como Go para 1.27.3 e o pacote certifi do Python para 2026.10.19. Reconstrua imagens de contêiner e CI/CD runners para garantir que todas as dependências estejam atualizadas.
Teste seus clientes contra o endpoint de teste de incidente publicado, DV G3B eMudhra.we-have-a-problem.com. Se o seu cliente rejeitar a cadeia de certificados com um erro, ele está seguro. Esta etapa de validação é crucial para todos os sistemas que dependem da confiança em certificados.
O incidente destaca uma lição crítica de PKI: verificações de formato não podem provar aleatoriedade ou intenção. Automatize verificações de força de chave como parte das cerimônias de chave. Valide se as chaves públicas dos certificados correspondem precisamente às chaves HSM pretendidas, não apenas se são estruturalmente válidas. Monitore logs de Certificate Transparency (CT) e trate assinaturas de revogação inválidas — como o aviso da Sectigo de junho de 2025 — como emergências de segurança graves.
Perguntas Frequentes
O que havia de errado com as chaves privadas da eMudhra?
Oito certificados de CA intermediários usaram valores de chave privada minúsculos, incluindo 4, em vez de valores imprevisíveis de 384 bits. As chaves correspondentes poderiam ser recuperadas testando apenas algumas possibilidades.
Usuários comuns de navegadores estavam em risco?
Os requisitos de Certificate Transparency dos navegadores modernos ajudaram a bloquear certificados falsificados não registrados, embora as proteções e atualizações tenham variado. Softwares que não são navegadores frequentemente carecem de verificações equivalentes.
Por que os pipelines de CI eram uma preocupação?
Ferramentas e serviços em pipelines de build podem confiar em pacotes de CA locais sem verificar a Certificate Transparency ou a revogação de certificados, potencialmente aceitando um certificado de servidor falsificado.
O que os desenvolvedores devem fazer?
Atualize os trust stores do sistema operacional e do runtime da linguagem, reconstrua os contêineres afetados e teste o comportamento de validação de certificados de clientes que não são navegadores e CI runners.