Falha em eMudhra expõe 8 chaves e provoca bloqueios globais hoje

Segurança Digital

Vulnerabilidade na eMudhra permite emissão de certificados falsos, causando bloqueios em navegadores e sistemas globais.

Leia também: Proofpoint compra Varonis por US$ 6,3 bi e cria gigante de cibersegurança

O comprometimento das chaves privadas de oito certificados intermediários da autoridade certificadora eMudhra, revelado nesta semana, levou navegadores como Chrome e Firefox, além de Apple, Microsoft e mantenedores de bibliotecas de certificados, a dispararem bloqueios e atualizações de emergência para evitar a emissão fraudulenta de certificados TLS para qualquer site.

O que aconteceu com a eMudhra

O caso veio à tona na noite de 17 de outubro, quando um pesquisador identificado apenas como Wayne demonstrou que tinha posse das oito chaves privadas da eMudhra, seis delas usadas para certificados TLS de websites e duas para assinatura de código. Ele assinou mensagens com cada uma das chaves e enviou o material aos programas de raízes de confiança do Chrome e do Firefox, acompanhado do alerta: “We have a problem here – Wayne”.

De posse da evidência, o Chrome Root Program recebeu o relatório às 18h05 (UTC) de 17 de outubro e, às 19h45 (UTC) do mesmo dia, já tinha uma atualização do CRLSet bloqueando os seis intermediários TLS, impedindo que cadeias que passassem por essas chaves fossem aceitas pelo navegador. Pouco depois, a Mozilla recebeu o alerta às 20h06 (UTC) e concluiu a distribuição de um bloqueio via OneCRL às 22h59 (UTC), protegendo instalações padrão do Firefox sem exigir atualização manual.

A própria eMudhra revogou os oito certificados intermediários comprometidos. Em paralelo, as listas de confiança de outros grandes fornecedores também foram atualizadas: a Apple passou a bloquear as chaves em 19 de outubro e a Microsoft fez o mesmo em 20 de outubro, ampliando a proteção para usuários de seus sistemas operacionais e navegadores.

Entenda o contexto

Certificados intermediários são usados por autoridades certificadoras para assinar os certificados que os sites apresentam aos navegadores. Quem controla a chave privada de um intermediário consegue, na prática, fabricar certificados aparentemente válidos para qualquer domínio e montar ataques de interceptação e falsificação de páginas, com potencial de roubo de dados sensíveis em conexões TLS.

No incidente com a eMudhra, seis intermediários afetados eram voltados para TLS de websites e dois para assinatura de código, usada para garantir a integridade de softwares. Embora não haja, até agora, evidência de uso malicioso em larga escala das chaves roubadas, o simples fato de terem saído do controle da autoridade certificadora já é suficiente para exigir sua retirada imediata das cadeias de confiança.

Antes do bloqueio, não havia certificados TLS ligados a esses seis intermediários registrados em logs de Certificate Transparency, mecanismo usado por navegadores como o Chrome para monitorar emissões de certificados. Isso reduz a chance de que certificados fraudulentos tenham sido amplamente aceitos pelos principais navegadores, mas não elimina o risco em sistemas que não exigem esse tipo de registro.

Como os navegadores e sistemas reagiram

Chrome e Firefox recorreram a seus mecanismos próprios de revogação para reagir em questão de horas. O CRLSet, no caso do Chrome, e o OneCRL, no Firefox, são listas de revogação que os navegadores atualizam automaticamente em segundo plano, sem depender de atualização completa de versão ou intervenção do usuário.

No Chrome, o bloqueio foi feito com base na chave pública, não apenas nos certificados específicos, o que também atinge cópias cross-signed — versões dos mesmos certificados assinadas por outra autoridade, mas com a mesma chave. Já no Firefox, a política de bloqueio foi empurrada por meio das configurações remotas padrão, cobrindo a maior parte da base instalada.

Apple e Microsoft, responsáveis por grandes lojas de certificados em seus sistemas, seguiram com bloqueios próprios nos dias 19 e 20 de outubro. Com isso, conexões que tentarem se apoiar nas cadeias comprometidas tendem a ser automaticamente rejeitadas em navegadores e aplicativos que se baseiam nos repositórios de raízes de macOS, iOS e Windows.

Outros mantenedores de bundles de certificados, como projetos de bibliotecas amplamente usadas por aplicações, começaram a remover raízes ou intermediários relacionados à eMudhra de seus pacotes. Em alguns casos, a solução é cortar completamente a confiança em raízes específicas, o que também desliga certificados legítimos que dependiam delas até que os donos dos sites migrem para novas cadeias.

Impacto para usuários e empresas

Para o usuário comum, o objetivo das correções é impedir que conexões HTTPS aparentemente seguras sejam, na verdade, mediadas por certificados falsos emitidos a partir das chaves roubadas. Com os bloqueios em vigor em Chrome, Firefox, Apple e Microsoft, a tendência é que a navegação cotidiana continue protegida, ainda que alguns sites que dependam da cadeia da eMudhra passem a exibir erros de certificado e fiquem temporariamente indisponíveis.

Empresas que usam certificados emitidos sob as raízes e intermediários da eMudhra, inclusive para assinatura de código, podem ser obrigadas a reemitir e reinstalar certificados, com custos operacionais e risco de interrupções de serviço. Plataformas de comércio eletrônico, serviços financeiros e aplicações que exigem alto grau de confiança nas conexões são especialmente sensíveis a esse tipo de ruptura.

Em paralelo, o episódio expõe uma fragilidade estrutural: boa parte dos softwares fora do ecossistema dos grandes navegadores não verifica revogação em tempo real e continua confiando em cadeias antigas até que seus bundles de certificados sejam atualizados. Nesses casos, a proteção só chega quando o fornecedor da biblioteca ou do sistema decide remover explicitamente as chaves ou raízes problemáticas.

Go lança correção rígida para cadeias comprometidas

A linguagem Go, mantida pelo Google, também reagiu de forma agressiva ao incidente. Em atualizações de segurança divulgadas hoje, Go passou a rejeitar automaticamente qualquer cadeia de certificados que contenha uma das oito chaves comprometidas, tanto em seu verificador próprio quanto quando delega a verificação aos sistemas de macOS e Windows.

Segundo a descrição técnica da mudança, “Go’s filter sits in the standard library and rejects any chain containing one of the eight keys, on Go’s own verifier and on the macOS and Windows system-verifier paths, and the change adds no setting to turn it off.” Na prática, desenvolvedores que recompilarem seus programas com as novas versões não terão como desativar esse filtro, o que força a remoção das cadeias comprometidas de qualquer ambiente controlado por aplicações escritas em Go.

A correção foi tratada como urgente, na categoria reservada a ameaças à integridade do ecossistema ou falhas já exploradas em ambiente real. Versões mais antigas de Go que já saíram do ciclo de suporte não recebem o ajuste, o que deixa a cargo de administradores a tarefa de atualizar runtimes ou revisar manualmente as cadeias de confiança nos ambientes afetados.

Próximos passos e dúvidas em aberto

Até agora, não há indicação de que outras autoridades certificadoras tenham sido afetadas pelo mesmo tipo de falha. Equipes de segurança ligadas a navegadores afirmam ter revisado os certificados de outras CAs presentes em suas lojas de raízes sem encontrar indícios de problemas semelhantes.

Permanece sem resposta, porém, a principal pergunta técnica: como e quando as oito chaves privadas saíram do controle da eMudhra, e se alguém além do pesquisador Wayne teve acesso a elas. Representantes do ecossistema de certificação digital dizem trabalhar com a CA e com demais programas de raiz para investigar a causa do vazamento e avaliar se novas medidas disciplinares ou mudanças de confiança em outras raízes da empresa serão necessárias.

Enquanto isso, a recomendação a administradores de infraestrutura é clara: onde houver mecanismos confiáveis de revogação automática, nenhuma ação adicional é necessária além de garantir que os sistemas estejam atualizados. Em ambientes que permitem bloquear intermediários de forma específica, a orientação é barrar imediatamente os oito certificados comprometidos; nos demais, considerar a remoção completa das raízes que os emitiram até que novas cadeias seguras estejam em operação.

Fonte: matéria original