O script interno em Python relacionado ao comprometimento de chaves da eMudhra em outubro levou à revogação de mais oito autoridades certificadoras intermediárias (ACs), embora não tenha enfraquecido as chaves delas.
Cada AC intermediária tem sua própria chave privada, usada pela empresa para assinar os certificados que emite. As oito ACs comprometidas em outubro tinham outro problema: segundo a empresa, uma única linha do script reduziu cada chave a um byte.
O script também recuperou dos módulos de segurança de hardware (HSMs) da empresa as chaves RSA das oito ACs recém-revogadas. A eMudhra afirma que não pode demonstrar que essas chaves foram tratadas de acordo com as próprias regras. A empresa revogou as ACs no fim da semana passada.
Antes, a empresa havia afirmado que essas ACs não foram afetadas. “De acordo com nossa avaliação do código, as ACs emissoras RSA seguiram um caminho diferente e, portanto, não foram impactadas”, escreveu em 19 de outubro no rastreador de bugs da Mozilla.
Das oito ACs, seis emitiam certificados para sites (TLS) e duas, certificados para assinatura de código. A empresa havia colocado quatro delas em produção em maio. A lista da eMudhra registra 195 certificados emitidos por essas ACs, dos quais 29 eram para domínios da própria empresa.
Segundo o relatório completo do incidente, publicado nesta semana no mesmo rastreador de bugs, os dois problemas começaram durante uma cerimônia de geração de chaves em 30 de abril de 2025. Naquele dia, a empresa gerou 16 chaves de AC em HSMs da Utimaco, incluindo as oito envolvidas no comprometimento de outubro.
As chaves seriam transferidas para HSMs da Crypto4A instalados nas unidades da empresa nos Estados Unidos e na União Europeia. Como a transferência entre HSMs de fabricantes diferentes é limitada, a equipe de operações de infraestrutura de chaves públicas (PKI) da eMudhra escreveu o script em Python para proteger cada chave durante o transporte e recuperá-la depois.
A transferência de ida e volta realizada naquele dia foi um teste prático do processo. Para isso, o modo aprovado pela FIPS do HSM de origem foi desativado, como uma exceção autorizada.
Após a transferência, o script leu cada chave privada do HSM para a memória do computador usado na cerimônia e reconstruiu a chave a partir dessa cópia. No caso das oito chaves ECDSA, “uma única linha nessa leitura de retorno truncou o valor privado, mantendo apenas seu primeiro byte”, diz o relatório.
A chave reconstruída recebeu um rótulo quase idêntico ao da original. Isso permitiu que a cópia enfraquecida fosse enviada para assinatura e certificação.
Segundo o The Hacker News, foi possível calcular as oito chaves a partir dos certificados públicos. O menor valor, da EM OV TLS CA - G3C, é 4; o maior, 237.
Nenhuma etapa da cerimônia testou a força das chaves ou comparou a chave certificada com a primeira chave gerada. As chaves fracas ainda produziam assinaturas válidas, e seus certificados passaram pelas verificações de lint e por dois ciclos de auditoria WebTrust sem serem detectados.
Segundo a empresa, os HSMs funcionaram corretamente durante todo o processo. A falha, portanto, estava no script interno e nos controles do procedimento.
O relatório aponta que assinaturas inválidas em listas de revogação de certificados (CRLs), detectadas em junho de 2025, foram um sinal inicial do mesmo problema. Na ocasião, a empresa corrigiu a falha assinando novamente as listas com as chaves correspondentes aos certificados, que eram as chaves fracas.
De acordo com o relatório, as oito chaves RSA passaram pela mesma etapa de leitura de retorno, contrariando a resposta anterior da empresa, que havia afirmado que elas seguiram um caminho diferente. No início da semana passada, a eMudhra afirmou que suas respostas anteriores refletiam apenas as informações reunidas até então pelas equipes, inclusive sobre os caminhos do script percorridos por cada conjunto de chaves.
O script não encurtou essas chaves, e todas as assinaturas ainda podem ser verificadas com a chave certificada. No entanto, partes privadas delas, como o expoente privado e um dos números primos, passaram pela memória de um processo Python no computador usado na cerimônia.
Por isso, a empresa “não pode demonstrar de forma conclusiva que esse material de chave estava em conformidade com a seção 6.2.6 da CPS”, sua própria regra para transferir chaves para dentro e para fora de um HSM. Os registros e arquivos do computador não permitem comprovar de forma confiável como o material foi tratado.
A empresa chegou a essa conclusão no início de novembro, após conversar com programas de raízes de navegadores. As oito ACs RSA foram revogadas no fim da semana passada com o código de motivo cessationOfOperation, e não com o código keyCompromise, usado na revogação das primeiras oito ACs, em 18 de outubro.
Participantes da discussão no rastreador de bugs questionaram por que a empresa escolheu esse código em vez de keyCompromise.
Dos 195 certificados na lista da empresa, 130 foram emitidos pela EM DV TLS CA - G2C, 63 pela EM OV TLS CA - G2C e dois pela AC de assinatura de código EM OV CS CA - G2C.
Além de domínios da própria eMudhra, os certificados incluíam domínios de várias universidades e faculdades, de um condado e de outras organizações. O certificado mais recente foi emitido na semana passada, poucos dias antes da revogação das ACs. Segundo a empresa, todos os titulares receberam novos certificados.
A eMudhra afirma que o processo de proteção e recuperação das chaves foi usado apenas nessa ocasião e que, nas demais cerimônias, as chaves foram geradas diretamente nos HSMs.
Participantes da discussão também pediram que o script seja publicado e questionaram como as chaves privadas puderam sair dos HSMs da empresa.
A KPMG, contratada pela eMudhra para fazer uma análise independente, deve concluir o trabalho até 4 de dezembro. O inventário de todas as chaves de AC da empresa deve ficar pronto em 30 de novembro.
A empresa diz não ter conhecimento de nenhum caso de uso indevido. Segundo um site de divulgação mantido por Dennis Jackson, que investigou as chaves para a Mozilla, quem tivesse uma das chaves comprometidas em outubro poderia se passar por qualquer site.
Navegadores que aplicam a Transparência de Certificados não poderiam ter sido enganados. Não se sabe se alguém usou as chaves contra programas que não fazem essa verificação.
O que os titulares de certificados emSign precisam verificar
A eMudhra, que vende certificados sob a marca emSign, está deixando o mercado de certificados TLS confiáveis publicamente, após o anúncio feito em 22 de outubro.
Os titulares podem localizar certificados afetados na lista da empresa ou pesquisando os registros de Transparência de Certificados pelos emissores TLS G2C revogados.
Toda emissão na hierarquia G1 deve ser encerrada antes de 16 de novembro, enquanto os clientes restantes, principalmente uma federação universitária da América do Norte, migram para outro provedor.
A Microsoft começará a remover as 10 raízes restantes da eMudhra, incluindo a emSign Root CA - G1, em 16 de novembro, segundo uma atualização publicada no início desta semana em sua nota sobre a resposta de segurança. Os certificados vinculados a essas raízes deixarão de ser confiáveis por padrão no Windows e no Edge. A mudança também será aplicada a alguns outros produtos da Microsoft, de acordo com seus próprios cronogramas.
Segundo o cronograma de descontinuação da empresa indiana, Chrome e Firefox deixarão de confiar em certificados G1 emitidos após 16 de novembro. A Apple encerrará a confiança em todos os certificados G1, inclusive os mais antigos, em 30 de novembro.
O macOS 27.2.1, 26.7.3 e 15.8.3 impedem que ferramentas de linha de comando incluídas no sistema, como curl e git, aceitem certificados TLS emitidos pelas ACs comprometidas, informou a Apple em uma nota de suporte publicada no início desta semana. Essas versões também removem cinco raízes, entre elas a emSign Root CA - G1, do arquivo /etc/ssl/cert.pem. Por isso, ferramentas que dependem desse arquivo podem deixar de verificar alguns sites vinculados a essas raízes.
Publicidade
Vibecoding cria 10x mais sistemas, 20x mais vulneráveis. E quem ganha com isso é a galera do hacking ético e pentest. Quer ser pago para invadir sistemas? Então você tem que aprender com a Solyd que são os melhores do Brasil. Saiba mais...