Compromisso do eMudhra CA: oito chaves privadas, sendo que uma delas é a 4

‍TL;DR

A eMudhra, uma autoridade certificadora reconhecida por todos os principais navegadores, gerou as chaves privadas de oito dos seus certificados de assinatura de tal forma que uma delas é simplesmente o número 4, o que a torna tão fácil de adivinhar quanto uma chave pode ser. Uma chave gerada corretamente requer cerca de 10^115 tentativas para ser descoberta. Estas chaves exigiram, no máximo, 256 tentativas, o que é suficiente para que qualquer pessoa capaz de interceptar o seu tráfego se faça passar por qualquer site.

• Quem é afetado: Os navegadores já bloquearam os certificados. Servidores, pipelines de CI, imagens do Docker e ferramentas de linha de comandos, tais como curl e git podem continuar a confiar neles, porque nunca verificam se um certificado foi revogado.
• O que fazer: atualize o seu pacote de CA e recompile as suas imagens. Os passos seguem-se abaixo.
• Como o « Aikido » ajuda: o « Aikido » identifica as imagens do « container » que ainda contêm os pacotes de certificados afetados como problemas «Críticos» ou «Elevados».

Quem é afectado

A maioria dos utilizadores de navegadores está protegida. O Firefox e o Chrome bloquearam os certificados desde 17 de outubro, os dispositivos da Apple desde 19 de outubro e as plataformas da Microsoft desde 20 de outubro, utilizando as listas de revogação que os respetivos fornecedores disponibilizam aos utilizadores.

Os oito certificados afetados são autoridades de certificação intermédias, ou seja, certificados de assinatura que fazem parte de uma cadeia que remonta a uma raiz de confiança. Quem detiver a chave privada de uma autoridade intermédia pode assinar um certificado válido para qualquer domínio. Estes oito fazem parte de uma cadeia que remonta à emSign ECC Root CA - G3, que a Mozilla removeu do seu repositório de confiança e que o Chrome prevê fazer o mesmo a 27 de outubro.

A vulnerabilidade está presente num software que realiza a sua própria verificação de certificados:

• Ferramentas de linha de comandos. No macOS, a funcionalidade integrada curl, git, python3, Perl, ruby e openssl verificar em relação a /etc/ssl/cert.pem sem verificar se houve revogação, e esse ficheiro não é atualizado automaticamente. O conteúdo desse ficheiro e, consequentemente, as suas ferramentas Linux dependem do certificados CA pacote da sua distribuição.
• Contentores e CI. Uma imagem inclui o pacote de certificados com o qual foi criada. Muitas imagens ainda incluem o pacote antigo.
• Ambientes de execução de linguagens. Go, Java, Node.js, Python certifi, O webpki-roots do Rust e outros incluem as suas próprias raízes e cada um precisava da sua própria versão.
• IoT: Os dispositivos da Internet das Coisas incluem certificados CA no seu firmware e, devido à dificuldade em atualizá-los, provavelmente permanecerão vulneráveis durante anos.
• Assinatura de código. Seis dos oito certificados intermédios destinavam-se ao TLS e dois eram autoridades de certificação (CA) de assinatura de código consideradas de confiança pela Microsoft, pelo que um atacante também poderia assinar malware em nome de qualquer editor. A Microsoft bloqueou-os desde 20 de outubro.

A utilização de um certificado falsificado continua a exigir a presença de um ponto de acesso na rota de rede, como uma rede Wi-Fi hostil ou um router comprometido. O site que noticiou o incidente refere ainda que os oito certificados intermédios não constavam dos registos de transparência de certificados antes do bloqueio, pelo que os clientes que aplicam a transparência (Firefox, Chrome, Edge e Safari) não poderiam ter sido atacados. Os clientes que não aplicam essa transparência poderiam ter sido alvo de ataques, e o site afirma não saber se os atacantes utilizaram as chaves defeituosas contra eles.

O que fazer agora

1. Atualize o seu sistema operativo e os seus navegadores. Isto aplica-se à maioria das pessoas.
2. Atualizar o pacote de CA nos servidores e nas imagens. O remendado certificados CA A versão depende da sua distribuição: o Ubuntu inclui 20260816ubuntu0.*, o Debian 12 é lançado 20250419~deb12u2, navios Alpine 20261020-r0, o Fedora é fornecido 2026.2.92_v9.0.319. A utilização de um único critério de corte de versão poderá levar à classificação errada de alguns destes casos, por isso verifique o tabela do local do incidente para a sua distribuição e ambiente de execução. Regenera o armazenamento de confiança ativo sempre que a sua distribuição assim o exigir.
3. Recriar imagens e reiniciar os serviços. Carregue uma imagem base nova (docker build --pull --no-cache) para que o pacote atualizado seja incorporado. Note-se que nem todas as imagens foram ainda atualizadas. Um processo « container » em execução mantém a versão antiga.
4. Teste isto. Execute os dois comandos abaixo. O resultado pretendido é uma falha de SSL com o código HTTP 000.
5. Cuidem dos que ficaram para trás. No que diz respeito às ferramentas integradas do macOS, que a Apple ainda não atualizou, o site dedicado ao incidente publica comandos de solução alternativa. Runtimes integrados, como o Node.js, o Go, o Java e certifi cada uma delas necessita da sua própria versão corrigida.

curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-emudhra.we-have-a-problem.com/
curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Um cliente que já não confia nos certificados intermédios comprometidos rejeita ambas as solicitações com um erro SSL e apresenta a seguinte mensagem: HTTP 000:

curl: (60) Problema com o certificado SSL: impossível obter local certificado do emitente
HTTP 000

A 200 significa que o cliente continua a confiar neles.

Para saber quais certificados CA versão que tem:

dpkg -s ca-certificates | grep Version   # Debian, Ubuntu
apk info ca-certificates                 # Alpine
rpm -q ca-certificates                   # Fedora, RHEL

Como o « Aikido » ajuda

Se for um cliente do Aikido , as imagens do container são verificadas automaticamente. A verificação abrange pacotes que incluem os seus próprios conjuntos de certificados, bem como o armazenamento de confiança fornecido pelo sistema, e gera um problema distinto para cada um deles.

No caso de pacotes com o seu próprio conjunto de certificados, como o certifi do Python anterior à versão 2026.10.18, a imagem recebe uma classificação de «Crítica». Quanto ao repositório de confiança do sistema, que ainda aceita cadeias de certificados que passem por intermediários comprometidos, recebe uma classificação de «Elevada». Cada classificação vem acompanhada de uma correção que segue os passos acima indicados, e as aplicações que incorporam as suas próprias raízes necessitam de atualizações separadas.

Lançámos também o Device Protection v1.10.20 como uma correção para este problema. Se utilizar o Device Protection, recomendamos que o atualize para esta versão.

O que aconteceu: oito teclas, e uma delas é o 4

A eMudhra é uma autoridade certificadora sediada na Índia: verifica quem gere um site e emite o certificado que aparece por trás do cadeado no navegador, sendo que os programas raiz do Firefox, do Chrome, da Apple e da Microsoft confiam nela. Uma autoridade certificadora intermédia é um certificado de assinatura que se liga a uma dessas raízes de confiança, e quem detém a sua chave privada pode assinar um certificado válido para qualquer domínio.

A 17 de outubro, um investigador conhecido como Wayne informou as equipas responsáveis pelos programas de base do navegador e do sistema operativo de que as chaves privadas de oito certificados da CA intermédia do eMudhra tinham sido comprometidas. Para o provar, Wayne assinou a mensagem«Temos aqui um problema» com cada uma das oito chaves. Os certificados datam de abril de 2025. O eMudhra gerou as chaves de forma incorreta, o que significa que qualquer pessoa pode recuperá-las a partir dos certificados públicos.

Uma chave privada é um número secreto que tem de ser impossível de adivinhar. Uma chave deste tipo, gerada corretamente, é escolhida a partir de um intervalo de cerca de 10^115 valores, ou seja, um 1 seguido de 115 zeros. De acordo com a análise da nossa equipa, cada uma destas oito chaves é inferior a 256, e uma delas é o 4.

Uma possível explicação para os valores baixos seria um erro clássico de conversão de tipos, em que o número aleatório grande foi acidentalmente convertido para um byte. Outra teoria apontava para um comportamento antigo do Go, em que uma conversão decimal truncava o número para um único byte.

Quatro é também o número da banda desenhada xkcd 221, em que uma função de números aleatórios devolve o valor 4 e um comentário garante que este foi escolhido através de um lançamento justo de um dado. Um atacante precisava, no máximo, de 256 tentativas para descobrir qualquer uma das oito chaves, em vez das cerca de 10^115 que deveria ter sido necessário, e um portátil consegue testar todas as 256 antes de terminares esta frase. Um cadeado de bicicleta de três dígitos tem 1 000 combinações, pelo que o cadeado da tua bicicleta dá mais trabalho a um ladrão do que estas chaves deram a um atacante.

‍

Por que é que os navegadores são corrigidos e o curl pode não ser

A Mozilla, a Google, a Apple e a Microsoft distribuem informações de revogação aos seus navegadores através de mecanismos como o OneCRL, o CRLite e o CRLSets, pelo que um intermediário malicioso pode ser bloqueado sem ser necessário aguardar uma atualização de software. A eMudhra também revogou os certificados, mas apenas um cliente que verifique a revogação é que tem conhecimento disso.

A maioria das ferramentas de linha de comandos e ambientes de execução não verifica. Mantêm uma lista de certificados raiz de confiança e aceitam qualquer certificado que esteja ligado a um desses, pelo que a única forma de impedir que confiem num certificado intermédio comprometido é disponibilizar uma nova lista. De acordo com o site dedicado ao incidente, muitos clientes fora do ecossistema dos navegadores ignoram completamente os dados de revogação, pelo que apenas uma atualização de software os protege.

O macOS é o exemplo mais claro. Os dispositivos da Apple bloqueiam os certificados ao nível do sistema operativo, mas o `curl` integrado lê /etc/ssl/cert.pem, que não sofreu qualquer atualização. Um navegador e um terminal no mesmo portátil podem não chegar a um consenso quanto à validade do mesmo certificado.

Os contentores introduzem um atraso próprio. Uma imagem do Docker congela o seu pacote de certificados de autoridade de certificação (CA) no momento da compilação; por isso, todas as imagens compiladas antes da correção e todas as imagens compiladas a partir de uma camada base antiga desde então continuam a confiar nos certificados intermédios comprometidos até que alguém as recompile. Alguns exemplos, a partir de 22 de outubro, incluem: grafana/grafana:mais recente, mysql:mais recente, jenkins/jenkins:mais recente & bitnami/postgresql:mais recente.

Como funciona a confiança nos certificados, em resumo

Um certificado é o cartão de identificação digital de um site. Quando abre um site HTTPS, o servidor envia o seu certificado e o seu cliente verifica se o nome corresponde ao do site, se as datas são válidas e se a assinatura provém de uma entidade em que confia.

O signatário é uma autoridade certificadora (CA). O seu sistema operativo ou navegador inclui uma lista integrada de autoridades certificadoras raiz em que confia. As autoridades raiz permanecem fora de linha e delegam o trabalho quotidiano a autoridades certificadoras intermédias, que assinam os certificados que os sítios Web utilizam efetivamente. Um certificado cuja cadeia de certificação passa por uma autoridade certificadora intermédia até uma autoridade raiz de confiança é aceite.

A chave privada de um certificado intermédio pode assinar um certificado válido para qualquer domínio; por isso, uma chave que tenha sido divulgada confere a autoridade da raiz até que os clientes sejam instruídos a deixar de confiar nela.

Cronograma

Atualizações e fontes

22 de outubro de 2026: Publicado pela primeira vez. O estado das correções muda diariamente, por isso consulte a tabela do site de incidentes relativa à sua distribuição e ao seu ambiente de execução.

Fontes:

• Compromisso do eMudhra Intermediate CA, site sobre o incidente gerido por Dennis Jackson e colaboradores
• Relatório de incidente da Mozilla, conforme indicado no site de incidentes

‍