Uma autoridade certificadora foi flagrada usando uma chave privada igual a 4

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: A Certificate Authority Just Got Caught Using a Private Key of 4 · Canal: Better Stack · 07:45 · Assistir no YouTube

Tópicos: Cibersegurança e segurança de software

Resumo

O vídeo relata que oito chaves privadas de certificados intermediários da eMudhra eram extremamente fracas: cada uma consistia em zeros seguidos por um único byte, e uma delas tinha o valor 4. Um pesquisador conseguiu recuperar todas em menos de um segundo, e a falha passou despercebida por meses, apesar de sinais de alerta. Embora os navegadores tenham bloqueado os certificados e não haja registros deles nos logs de transparência de certificados, muitas ferramentas e sistemas fora dos navegadores poderiam aceitá-los. O vídeo explica as medidas de correção e recomendações para atualizar certificados e software, além de destacar a importância de verificar o processo de geração das chaves.

Pontos-chave

O pesquisador Wayne informou Apple, Google, Microsoft e Mozilla sobre o comprometimento das chaves de oito certificados intermediários da eMudhra.
As chaves eram de curva elíptica P-384, mas continham 47 bytes de zeros seguidos por apenas um byte, tornando possível recuperá-las rapidamente.
Um script Python encontrou os valores das oito chaves em menos de um segundo: 4, 56, 66, 115, 155, 156, 230 e 237.
Segundo o relatório de incidente da eMudhra, uma alteração no procedimento de geração de chaves e um erro de seleção levaram ao uso dos pares fracos.
Em junho de 2025, assinaturas inválidas em listas de revogação já haviam sinalizado um problema, mas as listas foram assinadas novamente com as chaves fracas.
Os navegadores bloquearam os certificados, e nenhum certificado desses intermediários apareceu nos logs de transparência de certificados.
Ferramentas como curl, Python, node, Go e git podem confiar nos certificados instalados localmente sem verificar esses logs ou a revogação.
O vídeo recomenda atualizar o pacote de certificados de CA, atualizar certify para 2026.10.19 e Go para 1.27.3, além de reconstruir imagens de contêiner.
A principal lição é que uma chave fraca ainda pode passar por verificações estruturais; os processos precisam confirmar que a chave do certificado é a que deveria ter sido gerada.

Capítulos

Início	Capítulo	Resumo
00:00	A chave privada que valia 4	O vídeo apresenta a falha da eMudhra e explica como o pesquisador revelou o comprometimento de oito chaves.
01:33	Como as chaves fracas foram recuperadas	A explicação mostra por que chaves P-384 aleatórias são difíceis de quebrar e como os valores pequenos permitiram recuperar as oito chaves em menos de um segundo.
03:07	Sinais de alerta e riscos fora dos navegadores	O vídeo aborda as assinaturas inválidas ignoradas, a resposta dos navegadores e a vulnerabilidade de ferramentas que não verificam logs de transparência ou revogação.
04:39	Atualizações e consequências para a eMudhra	São descritas as atualizações de produtos e bibliotecas, a remoção de confiança na CA e o impacto potencial sobre certificados e dispositivos.
06:13	Lições e medidas de proteção	O vídeo destaca a necessidade de validar o processo de geração de chaves e recomenda atualizar certificados, Go e imagens de contêiner.

Citações

Uma autoridade certificadora basicamente levou aquela piada para produção. — 00:00

Todas as oito chaves foram recuperadas em menos de um segundo. — 02:05

Quase tudo fora do navegador não verifica esses logs nem a revogação. — 03:37

A criptografia não consegue avisar quando falta aleatoriedade. — 06:13

Conceitos e entidades

eMudhra (empresa): Autoridade certificadora cujos certificados intermediários foram emitidos com chaves privadas extremamente fracas.
Sectigo (empresa): Autoridade certificadora que assinou os certificados intermediários da eMudhra.
Wayne (pessoa): Pesquisador de segurança que notificou empresas de tecnologia sobre o comprometimento das chaves.
Scott Helm (pessoa): Pesquisador de segurança que demonstrou a aceitação de um certificado forjado por ferramentas em sistemas Linux e macOS testados.
P-384 (conceito): Curva elíptica usada nas chaves descritas no vídeo, cuja segurança depende de uma chave privada aleatória.
certificate transparency logs (conceito): Registros públicos nos quais certificados TLS confiáveis precisam ser registrados, conforme explicado no vídeo.
Cloudflare (empresa): Empresa que publicou atualizações para seus produtos após a descoberta do problema.
Go (ferramenta): Linguagem cuja biblioteca padrão recebeu uma versão emergencial para bloquear diretamente os oito certificados intermediários.

Tradução completa (pt-BR)

00:00 Existe uma velha tirinha do XKCD em que uma função chamada get random number simplesmente retorna o número quatro, escolhido por uma rolagem justa de dado. Bem, nesta semana, uma autoridade certificadora basicamente colocou essa tirinha em produção. Uma das chaves privadas de CA da eMudhra, confiada por todos os principais navegadores e sistemas operacionais, acabou sendo literalmente apenas o número quatro. Então, neste vídeo, vou explicar como isso aconteceu, por que ninguém percebeu por 17 meses e por que provavelmente seu navegador está bem,

00:31 mas seu pipeline de CI talvez não esteja. Há bastante coisa para abordar, então vamos direto ao assunto. Em 17 de outubro, um pesquisador de segurança chamado Wayne informou à Apple, Google, Microsoft e Mozilla que as chaves privadas de oito certificados intermediários da eMudhra haviam sido comprometidas. Seis eram CAs emissoras de TLS, e duas eram CAs de assinatura de código. Todas foram criadas em abril de 2025 e, depois, assinadas pela

01:02 Sectigo, uma autoridade certificadora muito maior e mais antiga. E, para provar isso, Wayne assinou a mensagem “We have a problem here” com cada uma dessas chaves. Chrome e Firefox bloquearam os certificados em poucas horas, e Apple e Microsoft fizeram o mesmo nos três dias seguintes. Mas, para entender por que isso é tão grave, você precisa saber como essas chaves funcionam. São chaves de curva elíptica na curva P-384. A chave privada é apenas um número chamado D, e a chave pública no

01:33 certificado é D multiplicado por um ponto fixo na curva chamado G. É fácil ir de D à chave pública, mas voltar é considerado impossível, desde que D seja um número aleatório de 384 bits. Isso dá aproximadamente 10 elevado a 115 possibilidades. Então, ninguém vai conseguir encontrá-la por força bruta. Mas as chaves da eMudhra tinham 47 bytes de zeros, seguidos por um único byte. Um byte só tem 256 valores possíveis, então

02:05 quebrá-la significa apenas calcular 1 * G, 2 * G, 3 * G e assim por diante, parando quando o resultado finalmente corresponder ao certificado. Então, peguei os certificados que a Mozilla anexou ao anúncio e escrevi um pequeno script em Python que faz exatamente isso. E, como você pode ver, todas as oito chaves são descobertas em menos de 1 segundo. E os valores são 4, 56, 66, 115, 155, 156, 230 e 237. E o assustador é que nada nesses

02:36 certificados parece estar quebrado, porque uma chave de quatro ainda produz um ponto perfeitamente válido na curva e passa em todas as verificações estruturais. Então, como uma autoridade certificadora acaba com uma chave privada de quatro? Bem, de acordo com o relatório de incidente da e-Mudhra no rastreador de bugs da Mozilla, eles mudaram o procedimento habitual de geração de chaves para testar a exportação de chaves, e um bug nesse script criou um segundo par de chaves fraco no módulo de segurança de hardware. Os dois pares de chaves tinham

03:07 nomes parecidos, e alguém escolheu o par errado ao gerar as solicitações de certificado. Mas havia sinais de alerta muito antes. Em junho de 2025, a Sectigo informou que as listas de revogação da e-Mudhra tinham assinaturas inválidas. Isso aconteceu porque a e-Mudhra as assinou com as chaves fortes originais, que não correspondiam às chaves fracas no certificado. E, em vez de investigar o motivo, assinaram a lista de novo com as chaves fracas. Um comentarista no Hacker News chamou isso de a linha que separa um erro honesto de uma

03:37 negligência grave. E talvez tenha razão, porque, basicamente, isso significa que tudo isso poderia ter sido detectado 16 meses atrás, mas, infelizmente, aqui estamos. Agora, a boa notícia é que os navegadores estão bem. Nenhum certificado desses intermediários apareceu nos logs de transparência de certificados, que são os registros públicos onde todo certificado TLS confiável precisa ser registrado. E Chrome, Firefox e Safari rejeitam certificados que não estejam registrados. Mas a má notícia é que quase tudo fora do navegador não verifica esses

04:08 logs nem a revogação. Ferramentas como curl, Python, node, go e git confiam em qualquer pacote de CAs que esteja no disco. O pesquisador de segurança Scott Helm conseguiu falsificar um certificado de api.stripe.com e, em todas as máquinas Linux e Mac OS que testou, curl, Python e node aceitaram. Pense no que isso significa para todos os scripts de instalação canalizados para bash ou para todos os executores de CI que guardam credenciais de nuvem e chamadas de API entre servidores.

04:39 E nem mesmo a correção dos navegadores foi perfeitamente consistente, porque pessoas no Hacker News relataram que o Firefox no Android carregava os sites de teste do ataque sem nenhum aviso. E, em smart TVs, roteadores e outros dispositivos que nunca recebem atualizações, esses certificados continuarão sendo confiáveis até expirarem, em julho de 2039. Caramba. E sabe o que é ainda pior? Segundo nossas estatísticas, 80% das pessoas assistindo a este vídeo não estão inscritas no nosso canal. Então, se algo assim acontecer de novo no futuro, você não vai querer perder

05:10 isso. Então apertem o botão de inscrição, pessoal, para receberem as últimas análises de segurança. Mas, voltando à nossa história, a limpeza posterior foi bastante ampla. A Cloudflare lançou atualizações para o cliente warp, o app 1.1.1.1 e também o software de túnel, tudo em 20 de outubro, e disse que não encontrou sinais de exploração em seus serviços. E go lançou uma versão de emergência que bloqueia diretamente esses oito intermediários na biblioteca padrão.

05:41 A Mozilla está removendo totalmente a raiz da eMudhra, e Chrome fará o mesmo em 27 de outubro. Isso dá à eMudhra cerca de uma semana para transferir aproximadamente 30.000 certificados para outra hierarquia, antes que esses sites comecem a parar de funcionar. E o momento não poderia ser pior para eles, porque, apenas um mês atrás, a discussão pública da Mozilla sobre aceitar a própria raiz da eMudhra havia sido concluída, com a CA prevista para aprovação. Pessoas no tópico do Hacker News estão comparando isso à DigiNotar, a autoridade certificadora holandesa que faliu

06:13 após a violação de segurança de 2011. Então, acho que agora está claro o que vai acontecer com eles. Mas qual é a grande lição aqui? Bem, isso só mostra que a criptografia não pode avisar você quando falta aleatoriedade. Uma chave de quatro passa em todas as verificações, então a proteção real precisa ser um processo que confirme que a chave no certificado é aquela que você realmente pretendia gerar. E as equipes de segurança precisam tratar assinaturas incompatíveis como uma emergência. Mas, para se proteger, veja o que você deve fazer imediatamente.

06:44 Atualize o pacote de certificados de CA, atualize certify para 2026.10.19 e, se estiver usando Go, atualize para 1.27.3 e reconstrua suas imagens de contêiner. Depois, execute curl contra dvg3b.emudhra.wehaveaproblem.com e, se receber um erro de certificado, seu cliente está seguro. Então é isso, pessoal. Foi assim que uma velha piada de programação acabou se tornando realidade. Às vezes, a vida realmente

07:14 imita a arte, eu acho, mas não de um jeito bom. Então, imagine como esse desastre é grave. Durante 17 meses, qualquer pessoa poderia ter usado essas chaves para se passar por qualquer site, e a maior parte dos softwares fora do seu navegador teria acreditado. Mas, felizmente, finalmente estamos corrigindo esse problema. E me contem nos comentários se vocês tiveram que corrigir alguma coisa por causa disso e se têm alguma dica para desenvolvedores sobre como se manter seguros em situações assim. E, se vocês gostam desse tipo de análise técnica, mostrem isso clicando no botão de gostei abaixo do vídeo. E também não

07:45 se esqueçam de se inscrever no nosso canal. Aqui foi Andrus, da Better Stack, e vejo vocês nos próximos vídeos. >> [música]

Transcrição original

[00:00] There’s this old XKCD comic out there where a function called get random number just returns the number four chosen by a fair dice roll. Well, this week certificate authority basically shipped that comic into production. One of eMudhra’s CA private keys, which was trusted by every major browser and operating system, turned out to be literally just number four. So, in this video I’ll explain how that happened, why nobody noticed this for 17 months, and why your browser’s probably fine,

[00:31] but your CI pipeline might not be. There’s a lot to go over, so let’s dive into it. So, on October 17th, a security researcher named Wayne reported to Apple, Google, Microsoft, and Mozilla that the private keys for eight eMudhra intermediate certificates were compromised. Six of them were TLS issuing CAs, and two were code signing CAs. All of them were created back in April 2025, and then also signed by

[01:02] Sectigo, which is a much bigger and older certificate authority. And to prove it, Wayne signed the message “We have a problem here” with every single one of those keys. And Chrome and Firefox blocked the certificates within hours, and Apple and Microsoft followed over the next three days. But to understand why this is so bad, you need to know how these keys work. These are elliptic curve keys on the P-384 curve. The private key is just a number called D, and the public key in the

[01:33] certificate is D multiplied by a fixed point on the curve called G. Going from D to the public key is easy, but going backwards is considered impossible as long as D is a random 384-bit number. That gives you roughly 10 to the power of 115 possibilities. So, nobody is ever going to brute force it. But eMudhra’s keys were 47 bytes of zeros followed by just one single byte. A byte only has 256 possible values, so

[02:05] cracking it just means computing 1 * G, 2 * G, 3 * G, and so on and so forth, and stopping when the result finally matches the certificate. So, I grabbed the certificates that Mozilla attached to its announcement and wrote a tiny Python script that does exactly that. And as you can see, all eight keys come back in under 1 second. And their values are 4, 56, 66, 115, 155, 156, 230, and 237. And the scary part is that nothing about

[02:36] these certificates looks broken because a key of four still produces a perfectly valid point on the curve and passes every structural check. So, how does a certificate authority end up with a private key of four? Well, according to e-Mudhra’s incident report on Mozilla’s bug tracker, they changed their usual key ceremony to test exporting keys, and the bug in that script created a second weak key pair on their hardware security module. The two key pairs had similar

[03:07] names, and someone picked the wrong one when generating the certificate requests. But, there were warning signs much earlier. In June 2025, Sectigo reported that e-Mudhra’s revocation lists had invalid signatures. That happened because e-Mudhra signed them with the original strong keys which didn’t match the weak keys in the certificate. And instead of investigating why, they re-signed the list with the weak keys. One commenter on Hacker News called that the line between an honest mistake and gross

[03:37] negligence. And they might have a point because basically, it means all this whole thing could have been caught 16 months ago, but unfortunately, here we are. Now, the good news is that browsers are fine. No certificates from these intermediates ever showed up in certificate transparency logs, which are the public logs that every trusted TLS certificate has to be recorded in. And Chrome, Firefox, and Safari all reject certificates that aren’t logged. But the bad news is that almost everything outside the browser doesn’t check those

[04:08] logs or revocation at all. Tools like curl, Python, node, go, and git trust whatever CA bundle is sitting on disk. Security researcher Scott Helm managed to forge a certificate from api.stripe.com and on every Linux and Mac OS machine he tested, curl, Python, node all accepted it. Think about what that means for all the installation scripts piped into bash or all the CI runners holding cloud credentials and server to server API

[04:39] calls. And even the browser fix wasn’t perfectly consistent because people on Hacker News reported Firefox on Android loading the attack test sites with no warnings at all. And for smart TVs, routers, and other devices that never get updates, these certificates will stay trusted until they expire in July 2039. Yikes. And you know what’s even worse? According to our stats, 80% of the people watching this video are not subscribed to our channel. So if something like this happens again in the future, you don’t want to miss out on

[05:10] it. So hit that subscribe button, folks, so you get updated with the latest security breakdowns. But getting back to our story, so basically the post cleanup has been quite huge. Cloudflare shipped updates to its warp client, its 1.1.1.1 app, and also their tunnel software all on October 20th and said it found no signs of exploitation on its services. And go pushed an emergency release that blocks these eight intermediates directly in its standard library.

[05:41] Mozilla is removing eMudhra’s root entirely and Chrome will follow on October 27th. That gives eMudhra about a week to move roughly 30,000 certificates to another hierarchy before these sites start breaking. And the timing couldn’t be worse for them because only a month ago Mozilla’s public discussion on accepting eMudhra’s own root had wrapped up with the CA slated for approval. People in the Hacker News thread are comparing this to DigiNotar, the Dutch certificate authority that went bankrupt

[06:13] after its 2011 breach. So, I guess the writing is on the wall now for them. But, what is the big lesson here? Well, this just goes to show you that cryptography can’t warn you when your randomness is missing. A key of four passes every check, so the real protection has to be a process that confirms that that key in the certificate is the one you actually meant to generate. And security teams need to treat mismatched signatures as an emergency. But, to protect yourself, here’s what you should do immediately.

[06:44] Update your CA certificates package, bump certify to 2026.10.19, and if you’re using Go, bump it to 1.27.3, and rebuild your container images. Then, run curl against dvg3b.emudhra.wehaveaproblem.com, and if you get a certificate error, then your client is safe. So, there you have it, folks. That is how an old programming joke turned out to be true. Life sometimes does indeed really

[07:14] imitate art, I guess, but not in a good way. So, imagine how bad this disaster is. For 17 months, anyone could have used these keys to pretend to be any website, and most software outside your browser would have believed them. But, thankfully, finally, we’re fixing this issue. And let me know in the comments if you’ve had to patch anything because of this, and if you have any tips for developers on how to stay safe in these situations. And if you like these types of technical breakdowns, please let me know by smashing that like button underneath the video. And also, don’t

[07:45] forget to subscribe to our channel. This has been Andrus from Better Stack, and I will see you in the next videos. >> [music]