Teku e Besu atualizaram suas imagens Docker após o evento eMudhra, pois chaves de certificado fracas representavam risco para softwares que se conectam a serviços externos, incluindo algumas implantações de validadores Ethereum.
- Teku 26.10.3 e Besu 26.10.2 removem a confiança nos certificados afetados nas imagens Docker devido ao evento eMudhra.
- Teku indica que, por padrão, os nós da rede principal não são afetados; o grau real de exposição depende da conexão HTTPS e do tempo de execução Java utilizado pelo operador.
- Os riscos divulgados envolvem serviços e operadores de validadores imitados; nenhum aproveitamento foi relatado no aviso do Teku.
Para os operadores, a questão mais imediata é: ao se conectar a outros serviços, o próprio software aceitará certificados falsificados? A resposta depende da conexão utilizada e da instalação do Java, portanto, a atualização do cliente não significa que todos os validadores enfrentem o mesmo risco.
Atualização das imagens Docker do Teku e Besu
A equipe do cliente Ethereum já lançou uma atualização para corrigir um problema de certificado que se originou fora da blockchain. As alterações relacionadas envolvem como o software determina a autenticidade de serviços remotos.
O Teku 26.10.3 e o Besu 26.10.2 removem a confiança nas raízes de certificados afetadas de suas imagens Docker. Esta versão foi lançada devido à descoberta de chaves fracas relacionadas à autoridade certificadora eMudhra.
Para operadores de validadores, o problema reside no fato de que um atacante se passa pelo serviço ao qual o software está conectado. Dependendo do papel desse serviço, respostas falsificadas podem perturbar responsabilidades ou afetar para onde os pagamentos de taxas de bloco são direcionados.
Isso não significa que todos os validadores da Ethereum estejam expostos ao risco. O aviso de segurança do Teku afirma que os nós padrão da mainnet não são afetados e, até o momento, não há relatos de exploração.
A diferença está no método de instalação. Os operadores que utilizam um serviço HTTPS externo precisam verificar conexões que podem não estar presentes em implantações totalmente localizadas.
Essas atualizações aplicam-se a ambientes de instalação específicos. As imagens Docker corrigidas contêm modificações de tempo de execução embutidas no contêiner, enquanto o software instalado a partir de arquivos arquivados pode usar o Java fornecido separadamente pelo operador.
O evento afetou a infraestrutura ao redor dos validadores, mas as regras de consenso da Ethereum não foram alteradas.
Why do certificate issues become security risks?
Os certificados ajudam o software a determinar se está conectado ao serviço esperado. Autoridades certificadoras confiáveis endossam a identidade correspondente ao certificado do servidor.
Esse mecanismo é comum em sites HTTPS, mas também se aplica a aplicativos que não se comunicam por meio de navegadores. Serviços de backend também podem depender dessas verificações de identidade.
A autoridade certificadora pode usar certificados intermediários abaixo dos certificados raiz confiáveis. As chaves privadas associadas a esses certificados intermediários devem ser mantidas seguras, pois podem ser usadas para emitir mais certificados.
Neste incidente, o problema não era apenas que alguém obteve as informações de login normais do servidor. As chaves intermediárias afetadas podem ser recuperadas a partir de informações já públicas.
O grupo de segurança do Go afirmou que essa vulnerabilidade permite a recuperação da chave privada em nível de microssegundos. A descrição também indica que os atacantes podem, em seguida, criar certificados para domínios que não controlam.
Se uma aplicação vulnerável considerar que o certificado ainda pode ser rastreado até uma autoridade em que confia, ela poderá aceitá-lo. Assim, a falsificação de identidade poderá contornar as verificações originalmente destinadas a rejeitar impostores.
No entanto, os atacantes ainda precisam de alguma maneira de interceptar ou redirecionar a conexão da vítima. Chaves fracas não os colocam automaticamente entre cada usuário e cada servidor.
Essa condição reduz as maneiras pelas quais o ataque pode ocorrer, mas não torna a invalidação do certificado inofensiva. Sempre que o software tratar o impostor como um ponto final legítimo, a interceptação de rede se torna mais perigosa.
A pesquisa da Kudelski Security examinou os níveis de certificados afetados. O problema é que o software pode aceitar certificados emitidos por chaves que um atacante pode reproduzir.
eMudhra atribui chaves fracas a erros de processamento
O comunicado de evento da eMudhra afirma que um pesquisador relatou oito chaves intermediárias fracas em 17 de outubro. A empresa revogou essas oito chaves no dia seguinte.
A empresa afirmou que esses certificados intermediários foram gerados durante uma cerimônia de chaves em 30 de abril de 2025. Segundo a empresa, os passos defeituosos de wrap e unwrap geraram cópias fracas além das chaves fortes originais.
A empresa afirmou ter utilizado módulos de segurança de hardware certificados. Explicou que o falha foi atribuída a um passo nos processos periféricos, e não à ausência desse tipo de equipamento.
A empresa também afirmou que dos 7 certificados intermediários, nenhum foi usado em ambiente de produção, e o restante ainda não emitiu nenhum certificado. A empresa declarou que o incidente não resultou em invasão da infraestrutura nem em vazamento de dados.
Essas afirmações explicam a descrição da eMudhra sobre suas operações internas. No entanto, o fornecedor de software ainda precisa lidar com outra possibilidade: outras partes podem utilizar chaves recuperáveis.
O sistema de certificados não pode depender apenas da promessa da operadora original de não emitir mais nenhum conteúdo. Uma vez que outra pessoa também consiga reproduzir uma chave de assinatura, essa garantia não pode mais controlar todos os certificados que possam ser criados.
Portanto, as medidas de resposta ultrapassaram a empresa que gerou a chave. Fabricantes de navegadores, fornecedores de sistemas operacionais e equipes de linguagens de programação precisam considerar quais softwares seus usuários aceitarão.
Essas correções serão transmitidas aos usuários por meio de diferentes atualizações. O navegador pode receber a lista de bloqueio, enquanto outro aplicativo Java independente ainda pode continuar a usar o conjunto antigo de certificados confiáveis.
Chaves fracas e os aplicativos que aceitam essas chaves são duas partes diferentes do mesmo problema. A revogação de certificados resolve o problema no nível dos registros da instituição, mas os clientes ainda precisam de uma maneira confiável para identificar quais caminhos de confiança afetados devem ser rejeitados.
Serviços externos trazem diferentes riscos aos validadores
Os nós da Ethereum são compostos por software que desempenham funções diferentes. A documentação do cliente Ethereum distingue entre clientes de execução e clientes de consenso: o primeiro lida com a execução de transações e estado, enquanto o segundo segue o consenso de prova de participação.
O software do validador adiciona as responsabilidades de propor blocos e provar a cadeia. Os operadores podem executar esses componentes localmente ou conectar-se a parte deles por meio de serviços externos.
Teku é um cliente de consenso, Besu é um cliente de execução. Ambos usam Java, o que explica por que a confiança no certificado de execução está relacionada às suas versões.
Serviços fora da máquina local adicionam uma camada de verificação de identidade para esse arranjo. O software precisa confirmar que o ponto de resposta é o fornecedor esperado.
Por exemplo, os operadores podem usar serviços de assinatura remota em vez de manter as operações de assinatura no mesmo processo. Alguns podem depender de endpoints externos para fornecer dados ou serviços de construção de blocos.
O dano que um impostor pode causar depende do que o serviço é permitido fazer. Um serviço que apenas recebe dados de monitoramento apresenta riscos diferentes de um serviço de fornecimento de informações que participa de decisões de assinatura.
A rota da rede também é importante. As conexões que atravessam infraestruturas públicas têm oportunidades de interceptação diferentes em comparação com componentes limitados ao mesmo host ou a redes privadas estritamente controladas.
A rede privada não pode impedir que todos os falhos ocorram, mas pode reduzir a chance de atacantes obterem a localização necessária para interferir no tráfego.
Portanto, o nome do cliente sozinho não é suficiente para determinar se há exposição. O mesmo software pode ser implantado em ambientes que utilizam diferentes endpoints, bibliotecas de confiança e controles de acesso.
A questão real que precisa ser respondida é: qual conexão passou pelo caminho afetado para aceitar o certificado. Uma vez esclarecido isso, os operadores podem avaliar quais permissões o serviço imitado deveria ter tido no funcionamento do verificador.
Por que as imagens Docker e a instalação por arquivo compactado são diferentes?
As imagens Docker empacotam o aplicativo junto com seu ambiente necessário para execução, o que pode incluir o tempo de execução Java e os certificados confiados por esse tempo de execução.
Atualizar o Java no host não substitui automaticamente o Java nas imagens existentes. Os contêineres ainda podem continuar usando os arquivos embutidos neles.
Essa é a razão pela qual as notas de lançamento do cliente mencionam especificamente as alterações no Docker. A documentação do Teku afirma que sua imagem base Eclipse Temurin ainda não incluía a remoção correspondente, portanto, a imagem do cliente foi modificada diretamente.
As notas de lançamento do Besu também indicam que a remoção do certificado se aplica às imagens Docker e exige explicitamente que os usuários que instalaram manualmente verifiquem suas próprias versões do Java.
A instalação arquivada deixará essa responsabilidade com o operador. O cliente Ethereum pode já ter sido atualizado, mas seu tempo de execução separado ainda pode conter armazenamentos de certificados antigos.
Por outro lado, durante a manutenção, também ocorrem diferenças semelhantes. Substituir o tempo de execução do host afetará os processos que utilizam esse tempo de execução, mas não afetará outra instalação que use um caminho Java diferente.
O evento da Oracle recomenda que os usuários atualizem os ambientes de execução afetados ou sigam as alternativas fornecidas em sua documentação. Também solicita a reinicialização das instâncias em execução e a consideração separada de cada instalação independente.
Isso torna os processos em execução mais importantes do que as atualizações baixadas. O servidor pode conter arquivos corrigidos, mas os processos antigos continuarão em execução até serem substituídos ou reiniciados.
O armazenamento de certificados personalizado adicionou outra variação. Uma organização pode usar um repositório de certificados mantido para seus próprios serviços, em vez de apenas o repositório padrão fornecido pelo Java.
A tarefa real é descobrir o que o cliente realmente está usando. O método de instalação, a localização em tempo de execução e a configuração de confiança determinam conjuntamente se a correção lançada já chegou à conexão que precisa dela.
Diferenças na verificação de revogação em diferentes aplicativos
Revogação significa que o certificado não deve mais ser aceito. Mas isso não garante que cada aplicativo verifique as informações mais recentes de revogação antes de estabelecer uma conexão.
Diferentes aplicativos obtêm essas informações de maneiras distintas. Alguns consultam serviços online, outros utilizam listas de bloqueio fornecidas por fornecedores, e alguns dependem principalmente de certificados armazenados em bancos de confiança locais.
A resposta da equipe Go explica por que o fornecedor de tempo de execução pode precisar intervir diretamente. A equipe lançou uma atualização de segurança de emergência em 19 de outubro e afirmou que forneceu uma versão corrigida cerca de 7,5 horas após receber o aviso.
Essa ação bloqueia o caminho de certificados afetados envolvidos em aplicações que utilizam a validação Go relacionada. Usuários Java precisam obter proteção por meio de suas próprias configurações de tempo de execução e confiança.
O aviso do Teku afirma que o Java, por padrão, não verifica revogações. É por isso que, mesmo após a eMudhra ter revogado esses certificados intermediários, ainda é necessário remover a confiança localmente.
A remoção do certificado raiz e o bloqueio do certificado intermediário também podem atuar em níveis diferentes. O primeiro rejeita um caminho danificado específico, enquanto o segundo pode rejeitar cadeias de certificados mais amplas que levam ao certificado raiz removido.
A implementação correta cabe ao fornecedor e à organização que mantém o aplicativo. Adotar temporariamente uma abordagem que desative a verificação de identidade apenas remove a proteção, sem resolver o problema de confiança.
Serviços legítimos também podem precisar ser ajustados. Se seus certificados dependerem de caminhos que os clientes agora rejeitam, os provedores de serviço devem oferecer alternativas aceitáveis, em vez de esperar que os usuários restaurem a confiança insegura.
Isso também explica por que um evento de certificado pode durar vários dias. A detecção pode ser imediata, mas a proteção é implementada gradualmente por meio de processos distintos de lançamento e manutenção em navegadores, aplicativos empacotados e infraestrutura privada.
Para operadores de validadores, o resultado-chave é se as conexões relevantes já rejeitaram identidades não confiáveis. Anúncios de revogação em outros lugares do ecossistema de software não provam que o processo do nó alcançou esse resultado.
Are rewards and validator staking exposed in the same way?
As responsabilidades de staking, assinatura e pagamento de taxas dos validadores estão interligadas, mas são reguladas por mecanismos distintos. Um problema que afeta um desses aspectos não deve ser automaticamente descrito como um controle sobre todos eles.
Documentação de stake do Ethereum: os validadores recebem recompensas por cumprir suas responsabilidades e são punidos por estar offline ou por comportamentos inadequados comprováveis. As permissões de assinatura e de retirada desempenham papéis diferentes no sistema.
A chave do certificado pertence ao sistema de identidade usado para conexão. Não é a chave privada de assinatura do validador e não expõe diretamente as credenciais para retirada de ETH质押.
No entanto, o serviço imitado ainda pode afetar o comportamento dos validadores. Seu impacto depende de quais solicitações ou respostas esse serviço processa e quais verificações adicionais ainda permanecem.
A proposta de bloco inclui o destinatário das taxas relacionadas à execução. Se algum caminho puder modificar a proposta ou a configuração, podem ocorrer consequências sem a necessidade de controlar todo o stake.
O serviço de assinatura levantou outro conjunto de problemas, pois está envolvido na autorização das ações dos validadores. Suas próprias medidas de proteção, incluindo limites nas requisições e garantias contra assinaturas conflitantes, afetam o grau de dano que um atacante pode causar.
A omissão de responsabilidade causada por interrupção de serviço também é uma consequência possível. Mesmo sem transferir nenhum pagamento com sucesso, o atacante pode reduzir as recompensas simplesmente impedindo a resposta correta.
As implicações financeiras desses resultados não são as mesmas. Perder a oportunidade de propor um bloco, penalidades comuns por offline e penalidades de slashing não podem ser confundidas.
A descrição do aviso ao cliente refere-se a possíveis consequências sob configurações afetadas, mas não prova que cada operador tenha sofrido essas consequências, nem que quantia correspondente de ETH tenha sido roubada.
Para detentores que utilizam serviços de staking, o que realmente importa é a implementação real do serviço. O número de ETH gerenciados não indica quais serviços remotos ou repositórios de certificados o operador utiliza.
Os validadores também dependem de software externo à Ethereum.
As regras da rede Ethereum são apenas uma parte do que os operadores dependem. Hardware, tempo de execução, hospedagem, configuração e serviços externos afetam se o validador pode cumprir corretamente suas funções.
A autoridade certificadora está fora do protocolo Ethereum, mas sua falha torna-se relevante quando o software do validador depende dela para identificar serviços. Isso, por si só, é suficiente para trazer um problema de segurança geral da internet para a infraestrutura de staking.
A diversidade de clientes ainda tem valor, pois implementações diferentes podem reduzir a dependência de um único código-fonte. Mas isso não significa que cada dependência seja independente.
Dois clientes podem usar o mesmo tempo de execução de linguagem de programação. Diferentes operadores também podem usar o mesmo provedor de hospedagem, serviço de assinatura ou infraestrutura de construção de blocos.
Esses componentes compartilhados criam uma superfície de exposição comum, independentemente das diferentes implementações do software da Ethereum. Portanto, para entender a situação de implantação, não basta observar apenas o número de marcas de clientes.
A terceirização também traz trade-offs. Um serviço de assinatura dedicado pode melhorar a forma como as chaves são protegidas, mas também torna mais importante a autenticação da conexão com esse serviço.
Executar localmente também possui seus próprios requisitos de manutenção. Colocar os componentes no mesmo computador pode reduzir parte da exposição à rede, mas os operadores ainda precisam gerenciar atualizações de software e o acesso a esse computador.
Este evento não fornece automaticamente uma arquitetura mais segura em todos os cenários. Ele demonstra que é necessário compreender e manter as responsabilidades ao redor de cada conexão.
Essa diferença também é importante para usuários comuns de ETH. A correção de certificados na infraestrutura de nós não significa que cada carteira precise transferir fundos, nem que os saldos das contas Ethereum tenham mudado.
As ações relacionadas cabem aos operadores do software afetado. Eles são os únicos capazes de identificar os tempos de execução, endpoints e configurações de confiança envolvidos, e então aplicar as orientações fornecidas pelo fornecedor aos sistemas que estão estabelecendo essas conexões.
Os operadores precisam aplicar e verificar as atualizações
Essas publicações fornecem aos operadores um método para remover os caminhos de confiança afetados das imagens Docker suportadas. Os usuários arquivados precisam tratar os ambientes de execução individuais conforme as orientações de seus fornecedores Java.
A disponibilidade do patch é apenas o primeiro passo. O ambiente atualizado ainda precisa ser executado e manter a configuração esperada e os serviços funcionando corretamente.
Para provedores de serviço, uma interrupção causada por certificados recentemente rejeitados pode exigir a troca de certificados nos endpoints. Ao restaurar o serviço, deve-se manter a verificação de identidade, em vez de contorná-la.
As divulgações futuras podem aprofundar ainda mais os impactos. Os operadores podem identificar configurações que aceitaram a cadeia de certificados afetada ou relatar eventos envolvendo serviços específicos.
Por enquanto, os relatórios de notificação do Teku não foram explorados e distinguem o uso padrão da mainnet das conexões externas afetadas. Esta é a evidência mais clara disponível para descrever a superfície de exposição atual da Ethereum.
Os operadores afetados têm motivos para atualizar. Qualquer perda financeira depende de qual serviço o atacante se passou, se o tráfego foi interceptado e o que o validador permitiu que esse serviço fizesse.
O que precisa ser observado?
- Atualização do cliente: Monitore as versões do Teku e Besu e confirme que está executando a versão corrigida.
- Certificado Java: consulte o guia do fornecedor para o runtime Java e o repositório de certificados utilizados em cada instalação.
- Links externos: revisar links HTTPS que apontam para serviços de assinatura remota, dados e construção de blocos.
- Notificação de segurança: Fique atento às confirmações de ataque ou explicações adicionais divulgadas pela equipe do cliente e pelo fornecedor Java.
Perguntas frequentes
O que é o evento eMudhra?
Este incidente envolve chaves privadas fracas associadas ao certificado intermediário da autoridade certificadora eMudhra. Pesquisadores descobriram que essas chaves podem ser recuperadas a partir de informações públicas, permitindo potencialmente que terceiros criem certificados para domínios que não controlam. Softwares que confiam na cadeia de certificados afetada podem aceitar essas identidades falsificadas. No entanto, os atacantes ainda precisam de alguma forma interceptar ou redirecionar conexões para se passar pelos serviços-alvo.
O consenso da Ethereum falhou?
Não. Os problemas relatados envolvem como o software verifica a identidade de serviços externos, e não as regras pelas quais a Ethereum chega a um consenso na blockchain. A atualização do cliente altera a confiança nos certificados no ambiente de software afetado. Algumas implantações de validadores ainda podem enfrentar riscos operacionais se serviços externos forem impersonados. Essa possibilidade depende da conexão e do papel do serviço, e não significa que as regras de consenso da Ethereum tenham sido comprometidas.
Quais clientes foram atualizados?
Teku 26.10.3 e Besu 26.10.2 atualizaram suas imagens Docker para remover os certificados afetados. Teku é um cliente de consenso e Besu é um cliente de execução, ambos utilizando Java. A forma de instalação é importante, pois essa alteração se aplica ao ambiente fornecido nessas imagens. Operadores que instalaram os arquivos dos clientes e fornecem seu próprio tempo de execução Java devem consultar as diretrizes específicas para esse tempo de execução.
Will all validators be affected?
Não. O aviso do Teku afirma que os nós da rede principal padrão não são afetados. O risco depende de se uma determinada implantação realizou conexões HTTPS externas relevantes e se sua verificação de certificado aceita o caminho de confiança afetado. Diferentes operadores podem executar o mesmo cliente em serviços diferentes, versões do Java e bibliotecas de certificados. Portanto, o nome do cliente ou a quantidade de ETH stakeada não indica se um determinado validador está exposto.
O update do Docker cobre todos os métodos de instalação?
Não. A imagem Docker corrigida atualizará o ambiente embutido nessa imagem, mas a instalação arquivada pode usar o Java fornecido separadamente pelo operador. Outros contêineres ou serviços também podem ter seus próprios ambientes de execução. O operador precisa identificar qual método de instalação está sendo usado pelos processos em execução e seguir as instruções do fornecedor. Arquivos corrigidos no servidor não protegem processos que ainda estão sendo executados em ambientes antigos.
Foi confirmado o aproveitamento?
No momento descrito neste artigo, as notificações do Teku não relataram nenhuma exploração. A divulgação relacionada descreve uma vulnerabilidade e suas possíveis consequências, e não prova que atacantes já a tenham utilizado para validadores. Essa distinção é importante ao discutir perdas. A existência de um possível caminho para imitar um serviço não equivale à manipulação das responsabilidades de assinatura, ao desvio de pagamentos de taxas ou à roubo de ETH stakeado.
Will validator deposits be automatically exposed?
Não. A chave de assinatura do certificado é diferente da chave de assinatura do validador e também diferente dos credenciais para controle de saques. A recuperação da chave do certificado afetada não expõe automaticamente as chaves necessárias para sacar os ETH depositados. O serviço impostor ainda pode comprometer responsabilidades ou afetar as informações usadas pelos validadores, dependendo da forma de implantação. Os possíveis impactos devem ser avaliados em relação a esse serviço, e não considerados como acesso automático a todo o depósito.
O que o operador deve fazer?
Os operadores devem seguir as notas de lançamento relevantes do Teku ou Besu, bem como as orientações da sua versão Java. É necessário identificar o tempo de execução e o repositório de certificados utilizados por cada processo afetado, incluindo os fornecidos dentro dos contêineres. Após aplicar as atualizações recomendadas, deve-se confirmar que os serviços atualizados estão em execução e que as conexões necessárias ainda funcionam corretamente. Desativar a verificação de certificados para restaurar conexões falhas remove a proteção que essas verificações deveriam fornecer.