Teku et Besu ont mis à jour leurs images Docker après l'événement eMudhra, car une clé de certificat faible présentait un risque pour les logiciels se connectant à des services externes, y compris certains déploiements de validateurs Ethereum.
- Teku 26.10.3 et Besu 26.10.2 ont supprimé les certificats affectés de la confiance dans les images Docker en raison de l'événement eMudhra.
- Teku indique que les nœuds de réseau principal par défaut ne sont pas affectés ; le niveau réel d'exposition dépend des connexions HTTPS et du runtime Java utilisé par l'opérateur.
- Les risques divulgués concernent les services imités et les opérations de validateurs ; aucune exploitation n'a été signalée dans l'avis de Teku.
Pour les opérateurs, la question la plus immédiate est de savoir si leur logiciel acceptera des certificats falsifiés lors de la connexion à d'autres services. La réponse dépend des connexions utilisées et de l'installation Java, de sorte qu'une mise à jour du client n'implique pas que chaque validateur soit exposé au même risque.
Mise à jour des images Docker pour Teku et Besu
Les équipes de clients Ethereum ont publié une mise à jour pour corriger un problème de certificat originaire hors de la chaîne de blocs. Les modifications concernent la manière dont le logiciel détermine l'authenticité des services distants.
Teku 26.10.3 et Besu 26.10.2 ont supprimé la confiance dans les racines de certificats affectées depuis leurs images Docker. Cette publication découle de la découverte de clés faibles liées à l'autorité de certification eMudhra.
Pour les opérateurs de validateurs, le problème réside dans le fait qu’un attaquant se fait passer pour le service auquel le logiciel se connecte. Selon le rôle de ce service, des réponses falsifiées peuvent perturber les responsabilités ou affecter la destination des paiements de frais de bloc.
Cela ne signifie pas pour autant que chaque validateur Ethereum est exposé à un risque. L'avis de sécurité de Teku indique que les nœuds de la mainnet par défaut ne sont pas affectés et qu'aucune exploitation n'a été signalée à ce jour.
La différence réside dans la méthode d'installation. Les opérateurs utilisant un service HTTPS externe doivent vérifier les connexions qui ne sont pas nécessairement présentes dans les déploiements entièrement localisés.
Ces mises à jour s'appliquent à un environnement d'installation spécifique. L'image Docker corrigée contient les modifications d'exécution intégrées au conteneur, tandis que le logiciel installé à partir du fichier archive peut utiliser une version Java fournie séparément par l'administrateur.
Cet incident a affecté l'infrastructure autour des validateurs, mais les règles de consensus d'Ethereum n'ont pas changé.
Why do certificate issues become security risks?
Les certificats aident le logiciel à déterminer s'il est connecté au service attendu. Les autorités de certification de confiance endossent l'identité correspondant au certificat serveur.
Ce mécanisme est courant sur les sites HTTPS, mais s'applique également aux applications qui ne communiquent pas via un navigateur. Les services backend peuvent également dépendre de ces vérifications d'identité.
Les autorités de certification peuvent utiliser des certificats intermédiaires sous les certificats racines de confiance. Les clés privées associées à ces certificats intermédiaires doivent être conservées en toute sécurité, car elles peuvent être utilisées pour émettre davantage de certificats.
Dans cet événement, le problème ne se limite pas à quelqu'un ayant obtenu les informations de connexion ordinaires au serveur. Les clés intermédiaires affectées peuvent être récupérées à partir d'informations déjà publiques.
L'équipe de sécurité de Go a indiqué que cette vulnérabilité permet de récupérer la clé privée à l'échelle des microsecondes. Elle précise également que les attaquants peuvent ensuite générer des certificats pour des domaines qu'ils ne contrôlent pas.
Une application vulnérable pourrait l'accepter si elle considère que ce certificat peut toujours être remonté à une autorité de confiance. Ainsi, une identité falsifiée pourrait contourner les vérifications initialement conçues pour rejeter les imposteurs.
Cependant, les attaquants ont toujours besoin d'une méthode pour intercepter ou rediriger la connexion de la victime. Des clés faibles ne les placent pas automatiquement entre chaque utilisateur et chaque serveur.
Cette condition réduit les façons dont une attaque peut se produire, mais ne rend pas la falsification de certificat inoffensive. Dès que le logiciel considère l'impersonnateur comme un point de terminaison légitime, l'interception réseau devient plus dangereuse.
L'étude de Kudelski Security a examiné les niveaux de certificats affectés. Le problème réside dans le fait que le logiciel pourrait accepter des certificats délivrés par des clés que l'attaquant peut reproduire.
eMudhra attribue les clés faibles à une erreur de traitement
Le communiqué d'eMudhra indique qu'un chercheur a signalé huit clés intermédiaires faibles le 17 octobre. L'entreprise a révoqué ces huit clés le lendemain.
L'entreprise a déclaré que ces certificats intermédiaires ont été générés lors d'une cérémonie de clés le 30 avril 2025. Selon l'entreprise, les étapes défectueuses de wrap et unwrap ont généré des copies faibles en plus des clés fortes d'origine.
L'entreprise affirme avoir utilisé un module de sécurité matériel certifié. Elle attribue la défaillance à une étape des processus périphériques, et non à l'absence de ce type d'équipement.
L'entreprise a également indiqué que sept de ces certificats intermédiaires n'ont jamais été utilisés en production, et que le dernier n'a pas encore émis de certificat. L'entreprise affirme que cet incident n'a pas entraîné de compromission de l'infrastructure ni de fuite de données.
Ces affirmations expliquent la description des opérations internes d'eMudhra. Toutefois, le fournisseur de logiciels doit toujours faire face à une autre possibilité : d'autres parties pourraient exploiter des clés récupérables.
Le système de certification ne peut pas se fier uniquement à la promesse de l'opérateur original de ne plus émettre aucun contenu. Dès qu'une autre personne peut reproduire une clé de signature, cette garantie ne peut plus contrôler tous les certificats susceptibles d'être créés.
Par conséquent, les mesures de réponse dépassent l'entreprise ayant généré la clé. Les fabricants de navigateurs, les fournisseurs de systèmes d'exploitation et les équipes de langages de programmation doivent tous considérer quelles logiciels leurs utilisateurs accepteront.
Ces correctifs seront transmis aux utilisateurs via différentes mises à jour. Le navigateur peut recevoir une liste de blocage, tandis qu'une autre application Java indépendante peut continuer à utiliser l'ancien ensemble de certificats de confiance.
Les clés faibles et les applications acceptant ces clés constituent deux aspects distincts d'un même problème. La révocation du certificat résout le problème au niveau des enregistrements institutionnels, mais les clients ont également besoin d'un moyen fiable pour identifier les chemins de confiance affectés qu'ils doivent rejeter.
Les services externes présentent des risques différents pour les validateurs
Les nœuds Ethereum sont composés de logiciels assumant des rôles différents. La documentation des clients Ethereum distingue les clients d'exécution et les clients de consensus : le premier gère l'exécution des transactions et l'état, tandis que le second suit le consensus de preuve d'enjeu.
Le logiciel de validateur ajoute les responsabilités de proposer des blocs et de prouver la chaîne. Les opérateurs peuvent exécuter ces composants localement ou se connecter à certaines parties via des services externes.
Teku est un client de consensus, Besu est un client d'exécution. Les deux utilisent Java, ce qui explique pourquoi la confiance des certificats d'exécution est liée à leur publication.
Les services externes à votre machine locale ajouteront une vérification d'identité à ce dispositif. Le logiciel doit confirmer que le point de terminaison répondant à la demande est bien le fournisseur attendu.
Par exemple, les opérateurs peuvent utiliser un service de signature à distance plutôt que de garder les opérations de signature dans le même processus. Certains peuvent également compter sur des points de terminaison externes pour fournir des données ou des services de construction de blocs.
Le dommage que les imposteurs peuvent causer dépend de ce que le service est autorisé à faire. Un service qui ne reçoit que des données de surveillance présente un risque différent d’un service de fourniture d’informations impliqué dans des décisions de signature.
Le chemin réseau est tout aussi important. Les connexions traversant des infrastructures publiques offrent des opportunités d'interception différentes par rapport aux composants limités au même hôte ou à un réseau privé strictement contrôlé.
Le réseau privé ne peut pas empêcher tous les pannes, mais il réduit les chances pour un attaquant d'obtenir l'accès aux emplacements nécessaires pour perturber le trafic.
Ainsi, le nom du client seul ne permet pas de déterminer s'il est exposé. Le même logiciel peut être déployé dans des environnements utilisant des points de terminaison, des bibliothèques de confiance et des contrôles d'accès différents.
La véritable question à répondre est : quel lien a transmis le certificat via le chemin affecté. Une fois cela déterminé, les opérateurs peuvent évaluer quel niveau de privilèges le service impersonné aurait dû avoir dans le fonctionnement du vérificateur.
Pourquoi les images Docker et les installations d'archives sont-elles différentes ?
Les images Docker regroupent l'application ainsi que son environnement d'exécution requis, ce qui peut inclure l'environnement d'exécution Java et les certificats approuvés par ce dernier.
Mettre à jour Java sur l'hôte ne remplace pas automatiquement Java dans les images existantes. Les conteneurs peuvent continuer à utiliser les fichiers intégrés.
C'est la raison pour laquelle les notes de version du client mentionnent spécifiquement les changements Docker. Les notes de Teku indiquent que leur image de base Eclipse Temurin ne contenait pas encore cette suppression à l'époque, donc l'image du client a été modifiée directement.
Les notes de publication de Besu indiquent également que la suppression du certificat s'applique aux images Docker et exigent explicitement que les utilisateurs ayant installé manuellement vérifient leur distribution Java fournie.
L'installation archivée laisse cette responsabilité à l'opérateur. Le client Ethereum a peut-être été mis à jour, mais son environnement d'exécution individuel peut encore contenir un ancien magasin de certificats.
Inversement, des différences similaires peuvent se produire lors de la maintenance. Remplacer l’environnement d’exécution du serveur affecte les processus utilisant cet environnement, mais pas une autre installation utilisant un chemin Java différent.
L'événement d'Oracle recommande aux utilisateurs de mettre à jour les environnements d'exécution affectés ou de suivre les alternatives indiquées dans sa documentation. Il demande également de redémarrer les instances en cours d'exécution et d'examiner chaque installation indépendante séparément.
Cela rend les processus en cours d'exécution plus importants que les mises à jour téléchargées. Le serveur peut contenir des fichiers corrigés, mais les anciens processus continueront de s'exécuter jusqu'à ce qu'ils soient remplacés ou redémarrés.
Le stockage de certificats personnalisé ajoute une autre variante. Une organisation peut utiliser un dépôt de certificats qu'elle maintient pour ses propres services, au lieu de se limiter au dépôt fourni par défaut par Java.
La tâche réelle consiste à déterminer ce que le client utilise réellement. La méthode d'installation, l'emplacement d'exécution et la configuration de confiance déterminent ensemble si le correctif publié a bien atteint la connexion qui en a besoin.
Différences de vérification de révocation entre les applications
La révocation signifie que le certificat ne doit plus être accepté. Toutefois, cela ne garantit pas que chaque application vérifie les informations de révocation les plus récentes avant d'établir une connexion.
Les différentes applications obtiennent ces informations de manières variées. Certaines interrogent des services en ligne, d'autres utilisent des listes de blocage fournies par des fournisseurs, et certaines s'appuient principalement sur les certificats présents dans leur bibliothèque de confiance locale.
La réponse de l'équipe Go explique pourquoi le fournisseur d'exécution pourrait avoir besoin d'intervenir directement. L'équipe a lancé une publication de sécurité d'urgence le 19 octobre et a indiqué qu'une version corrigée avait été fournie environ 7,5 heures après la réception de la notification.
Cette action bloque le chemin de certificat affecté impliqué dans les applications utilisant les comportements de validation Go associés. Les utilisateurs Java doivent obtenir une protection via leurs propres paramètres d'exécution et de confiance.
Les notifications de Teku indiquent que Java ne vérifie pas par défaut la révocation. C'est pourquoi il est nécessaire de supprimer localement la confiance, même si eMudhra a déjà révoqué ces certificats intermédiaires.
La suppression du certificat racine et le blocage du certificat intermédiaire peuvent également agir à différents niveaux. La première rejette un chemin endommagé spécifique, tandis que la seconde peut rejeter des chaînes de certificats plus larges menant au certificat racine supprimé.
La mise en œuvre correcte relève du fournisseur et de l'organisation qui maintient l'application. Une mesure temporaire consistant à désactiver l'authentification ne supprime que la protection, sans résoudre le problème de confiance.
Les services légitimes peuvent également nécessiter des ajustements. Si leurs certificats dépendent d'un chemin que les clients rejettent désormais, les fournisseurs de services doivent proposer des alternatives acceptables, au lieu de compter sur les utilisateurs pour rétablir une confiance non sécurisée.
Cela explique également pourquoi un incident de certificat peut durer plusieurs jours. La détection peut être immédiate, mais la protection est mise en place progressivement à travers les processus de publication et de maintenance distincts des navigateurs, des applications empaquetées et des infrastructures privées.
Pour les opérateurs de validateurs, le résultat clé est que les connexions non fiables ont été rejetées. Les annonces de révocation ailleurs dans l'écosystème logiciel ne prouvent pas que le processus de nœud a atteint ce résultat.
Are rewards and validator staking exposed in the same way?
Les obligations de staking, de signature et de paiement des frais des validateurs sont interdépendantes, mais elles sont régies par des mécanismes différents. Un problème affectant l'une d'entre elles ne doit pas être automatiquement décrit comme un contrôle sur l'ensemble de ces éléments.
La documentation sur le staking d'Ethereum indique que les validateurs reçoivent des récompenses en remplissant leurs obligations et sont pénalisés en cas de déconnexion ou de comportement inapproprié prouvable. Les autorisations de signature et de retrait jouent des rôles distincts dans le système.
La clé de certificat appartient au système d'identité utilisé pour la connexion. Ce n'est pas la clé privée de signature du validateur et ne révèle pas directement les informations d'accès pour les retraits des ETH mises en staking.
Cependant, le service imité peut toujours influencer le comportement des validateurs. Son impact dépend des demandes ou réponses traitées par ce service, ainsi que des vérifications supplémentaires encore en place.
The block proposal includes the fee recipient for executing related payments. If a path can modify the proposal or configuration, it may lead to consequences without requiring control over the entire stake.
Le service de signature soulève un autre ensemble de problèmes, car il participe à l'autorisation des comportements des validateurs. Ses propres mesures de protection, notamment les limites sur les requêtes et les mécanismes de prévention des signatures conflictuelles, influencent le degré auquel un attaquant peut agir.
L'omission de responsabilité causée par une interruption de service est également une conséquence possible. Même sans transférer aucun paiement, un attaquant peut réduire les récompenses en empêchant la réponse correcte.
Les impacts financiers de ces résultats ne sont pas les mêmes. Les opportunités manquées de proposer un bloc, les pénalités courantes pour déconnexion et les sanctions de slashing ne doivent pas être confondues.
La notification client décrit les conséquences potentielles dans les configurations affectées, mais ne prouve pas que chaque opérateur a subi ces conséquences, ni qu'une quantité correspondante d'ETH a été volée.
Pour les détenteurs utilisant un service de staking, ce qui compte vraiment, c'est le déploiement réel du service. Le nombre d'ETH gérés ne révèle pas quels services distants ou quelles bibliothèques de certificats son opérateur utilise.
Les validateurs dépendent également de logiciels externes à Ethereum.
Les règles du réseau Ethereum ne constituent qu'une partie de ce sur quoi les opérateurs comptent. Le matériel, l'environnement d'exécution, l'hébergement, la configuration et les services externes influencent tous la capacité du validateur à remplir correctement ses fonctions.
L'autorité de certification se trouve en dehors du protocole Ethereum, mais sa défaillance devient pertinente lorsque le logiciel de validateur dépend d'elle pour identifier les services. Cela suffit à importer un problème de sécurité Internet général dans l'infrastructure de staking.
La diversité des clients reste précieuse, car différentes implémentations réduisent la dépendance à un seul codebase. Cela ne signifie pas pour autant que chaque dépendance est indépendante.
Deux clients peuvent utiliser le même environnement d'exécution de langage de programmation. Des opérateurs différents peuvent également utiliser le même fournisseur d'hébergement, le même service de signature ou la même infrastructure de construction de blocs.
Ces composants partagés créent une surface d'exposition commune, même si les logiciels Ethereum eux-mêmes diffèrent. Par conséquent, pour comprendre les déploiements, il ne suffit pas de compter le nombre de marques de clients.
L'externalisation comporte également des compromis. Un service de signature dédié peut améliorer la protection des clés, mais rend également la connexion d'authentification avec ce service plus cruciale.
L'exécution locale présente également ses propres exigences de maintenance. Bien que placer les composants sur la même machine réduise une partie de l'exposition réseau, l'opérateur doit toujours gérer les mises à jour logicielles et l'accès à cette machine.
Cet événement ne fournit pas automatiquement une architecture la plus sûre dans tous les cas. Il montre qu'il est nécessaire de comprendre et de maintenir les responsabilités entourant chaque connexion.
Cette distinction est également importante pour les utilisateurs ordinaires d'ETH. Le correctif de certificat dans l'infrastructure des nœuds ne signifie pas que chaque portefeuille doit transférer des fonds, ni que les soldes des comptes Ethereum ont changé.
Les actions pertinentes relèvent des opérateurs du logiciel concerné. Seuls eux sont en mesure d'identifier les environnements d'exécution, les points de terminaison et les paramètres de confiance impliqués, puis d'appliquer les instructions fournies par le fournisseur aux systèmes établissant ces connexions.
Les administrateurs doivent appliquer et vérifier les mises à jour.
Ces publications offrent aux administrateurs la possibilité de supprimer les chemins de confiance affectés à partir des images Docker prises en charge. Les utilisateurs archivés doivent traiter les environnements d'exécution individuels selon les instructions de leur fournisseur Java.
Le patch disponible n'est qu'une première étape. L'environnement mis à jour doit également être réellement exécuté et maintenir les configurations et services attendus en bon fonctionnement.
Pour les fournisseurs de services, une interruption causée par un certificat récemment rejeté peut nécessiter le remplacement du certificat sur le point de terminaison. Lors de la restauration du service, il est essentiel de conserver l'authentification de l'identité, et non de la contourner.
Les divulgations ultérieures pourraient affiner davantage les impacts. Les opérateurs pourraient identifier une configuration ayant accepté la chaîne de certificats affectée, ou signaler des événements impliquant un service spécifique.
Pour l'instant, les rapports de notification de Teku ne sont pas exploités et distinguent l'utilisation par défaut du mainnet des connexions externes affectées. Il s'agit de la référence la plus claire pour décrire la surface d'exposition actuelle d'Ethereum.
Les opérateurs affectés ont des raisons de mettre à jour. Toute perte financière dépend du service que l'attaquant a imité, de la interception du trafic, et de ce que le validateur a autorisé ce service à faire.
Que faut-il surveiller ?
- Mise à jour du client : Suivez les publications de Teku et Besu, et confirmez que vous utilisez la version corrigée.
- Certificat Java : consultez les instructions du fournisseur pour le runtime Java et la bibliothèque de certificats utilisés par chaque installation.
- Liens externes : vérifiez les liens HTTPS pointant vers des services de signature à distance, de données et de construction de blocs.
- Notification de sécurité : Soyez attentif aux confirmations d'attaques ou aux précisions publiées par l'équipe client et les fournisseurs Java.
Foire aux questions
Qu'est-ce que l'événement eMudhra ?
Cet incident concerne une clé privée faible associée au certificat intermédiaire de l'autorité de certification eMudhra. Les chercheurs ont découvert que ces clés pouvaient être reconstituées à partir d'informations publiques, permettant potentiellement à d'autres de générer des certificats pour des domaines qu'ils ne contrôlent pas. Les logiciels faisant confiance à la chaîne de certificats concernée pourraient accepter cette identité falsifiée. Toutefois, les attaquants doivent toujours disposer d'un moyen d'intercepter ou de rediriger les connexions pour se faire passer pour un service cible.
L'éthique de la consensus d'Ethereum a-t-elle échoué ?
Non. Les problèmes mentionnés dans le rapport concernent la manière dont le logiciel vérifie l'identité des services externes, et non les règles de consensus d'Ethereum sur la blockchain. La mise à jour du client modifie la confiance dans les certificats dans l'environnement logiciel concerné. Certains déploiements de validateurs peuvent toujours être exposés à des risques opérationnels en cas d'usurpation d'un service externe. Cette possibilité dépend de la connexion et du rôle du service, et ne signifie pas que les règles de consensus d'Ethereum ont été compromises.
Quels clients ont été mis à jour ?
Teku 26.10.3 et Besu 26.10.2 ont modifié leurs images Docker pour supprimer les certificats affectés. Teku est un client de consensus et Besu est un client d'exécution, tous deux utilisant Java. La méthode d'installation est importante, car ce changement s'applique à l'environnement fourni dans ces images. Les opérateurs ayant installé les archives des clients et fourni leur propre runtime Java doivent consulter les instructions spécifiques à ce runtime.
Will all validators be affected?
Non. Les notifications de Teku indiquent que les nœuds de réseau principal par défaut ne sont pas affectés. Le risque dépend de la présence ou non de connexions HTTPS externes concernées, ainsi que de la manière dont les vérifications de certificat acceptent les chemins de confiance affectés. Différents opérateurs peuvent exécuter le même client sur des services, des versions Java et des bibliothèques de certificats différents. Par conséquent, le nom du client ou le nombre d'ETH mis en staking ne permettent pas de déterminer si un validateur spécifique est exposé.
Docker update can cover all installation methods?
Non. L’image Docker corrigée met à jour l’environnement inclus dans l’image, mais l’installation archivée peut utiliser une version Java fournie séparément par l’opérateur. D’autres conteneurs ou services peuvent également disposer de leurs propres environnements d’exécution. L’opérateur doit identifier quelle méthode d’installation est utilisée par les processus en cours d’exécution et suivre les instructions fournies par le fournisseur. Les fichiers corrigés sur le serveur ne protègent pas les processus encore en cours d’exécution dans un environnement ancien.
Has it been confirmed that it was exploited?
Au moment mentionné dans cet article, les notifications de Teku n'ont pas signalé d'exploitation. La divulgation associée décrit une vulnérabilité et ses conséquences potentielles, et non la preuve qu'un attaquant l'a utilisée pour des validateurs. Cette distinction est cruciale lorsqu'on évoque des pertes. La simple existence d'un chemin possible d'usurpation de service ne signifie pas que les responsabilités de signature ont été manipulées, que les paiements de frais ont été détournés ou que des ETH stakées ont été volées.
Les dépôts de validateurs sont-ils automatiquement exposés ?
Non. La clé de signature du certificat est différente de la clé de signature du validateur et des identifiants de retrait. La récupération de la clé de certificat compromise ne révèle pas automatiquement les clés nécessaires pour retirer les ETH misés. Le service impersonné peut toujours perturber les responsabilités ou affecter les informations utilisées par les validateurs, selon la manière dont il est déployé. Il convient d’évaluer les conséquences potentielles liées à ce service, et non de le considérer comme un accès automatique à l’ensemble des dépôts.
Que devrait faire l'administrateur ?
Les administrateurs doivent suivre les notes de publication pertinentes de Teku ou Besu, ainsi que les instructions de leur version Java. Il est nécessaire d'identifier le runtime et le magasin de certificats utilisés par chaque processus affecté, y compris les composants fournis dans le conteneur. Après application des mises à jour recommandées, il convient de vérifier que les services mis à jour fonctionnent correctement et que les connexions requises restent opérationnelles. Désactiver les vérifications de certificats pour rétablir les connexions échouées supprime la protection que ces vérifications sont censées fournir.