Faille de sécurité d'eMudhra CA : huit clés privées, dont l'une est la 4

‍TL;DR

eMudhra, une autorité de certification reconnue par tous les principaux navigateurs, a généré les clés privées de huit de ses certificats de signature de telle manière que l'une d'entre elles n'est autre que le chiffre 4, ce qui en fait une clé on ne peut plus facile à deviner. Une clé correctement générée nécessite environ 10^115 tentatives pour être découverte. Celles-ci n'en ont nécessité que 256 au maximum, ce qui suffit à quiconque est en mesure d'intercepter votre trafic pour se faire passer pour n'importe quel site web.

• Qui est concerné : Les navigateurs ont déjà bloqué ces certificats. Les serveurs, les pipelines d'automatisation, les images Docker et les outils en ligne de commande tels que curl et git peuvent continuer à leur faire confiance, car ils ne vérifient jamais si un certificat a été révoqué.
• Que faire : mettez à jour votre ensemble de certificats d'autorité (CA) et générez à nouveau vos images. Vous trouverez les étapes à suivre ci-dessous.
• Comment « Aikido » peut vous aider : Aikido signale les images de conteneurs qui contiennent encore les ensembles de certificats concernés comme présentant des problèmes « critiques » ou « élevés ».

Qui est concerné ?

La plupart des utilisateurs de navigateurs sont concernés. Firefox et Chrome bloquent ces certificats depuis le 17 octobre, les appareils Apple depuis le 19 octobre et les plateformes Microsoft depuis le 20 octobre, en s'appuyant sur les listes de révocation que leurs éditeurs transmettent aux utilisateurs.

Les huit certificats concernés sont des autorités de certification intermédiaires, c'est-à-dire des certificats de signature qui s'inscrivent dans une chaîne menant à une racine de confiance. Quiconque détient la clé privée d'une autorité intermédiaire peut signer un certificat valide pour n'importe quel domaine. Ces huit certificats s'inscrivent dans la chaîne menant à « emSign ECC Root CA - G3 », que Mozilla a supprimée de son magasin de confiance et que Chrome prévoit de faire de même le 27 octobre.

La vulnérabilité se trouve dans un logiciel qui effectue lui-même la vérification des certificats :

• Outils en ligne de commande. Sous macOS, la fonctionnalité intégrée curl, git, python3, perl, rubis et openssl vérifier par rapport à /etc/ssl/cert.pem sans vérifier s'il a été révoqué, et ce fichier ne se met pas à jour automatiquement. Le contenu de ce fichier, et par conséquent vos outils Linux, dépendent de la certificats CA paquet de votre distribution.
• Containers et CI. Une image contient le bundle CA utilisé pour sa création. De nombreuses images intègrent encore l'ancienne version.
• Moteurs d'exécution de langages. Go, Java, Node.js, Python certifi, « webpki-roots » de Rust et d'autres projets regroupent leurs propres certificats racine, et chacun nécessitait sa propre version.
• IoT: les appareils connectés à l'Internet des objets intègrent des certificats CA dans leur micrologiciel et, en raison de la difficulté à les mettre à jour, risquent de rester vulnérables pendant des années.
• Signature de code. Six des huit certificats intermédiaires concernaient le protocole TLS et deux étaient des autorités de certification (CA) de signature de code reconnues par Microsoft ; un pirate aurait donc pu signer des logiciels malveillants sous n'importe quel nom d'éditeur. Microsoft les a bloqués depuis le 20 octobre.

L'utilisation d'un certificat falsifié nécessite tout de même un point d'accès sur le chemin réseau, tel qu'un réseau Wi-Fi malveillant ou un routeur compromis. Le site consacré à l'incident indique également que les huit certificats intermédiaires n'apparaissaient pas dans les journaux de transparence des certificats avant le blocage ; par conséquent, les navigateurs qui appliquent la transparence (Firefox, Chrome, Edge et Safari) n'auraient pas pu être attaqués. Les navigateurs qui ne l'appliquent pas auraient pu être ciblés, et le site précise ne pas savoir si les attaquants ont utilisé les clés défectueuses à leur encontre.

Que faire maintenant

1. Mettez à jour votre système d'exploitation et vos navigateurs. Cela concerne la plupart des utilisateurs.
2. Mettez à jour le pack de certificats d'autorité de certification (CA) sur les serveurs et dans les images. Le correctif certificats CA La version dépend de votre distribution : Ubuntu est fourni avec 20260816ubuntu0.*, Debian 12 est disponible 20250419~deb12u2, navires Alpine 20261020-r0, Fedora est livré 2026.2.92_v9.0.319. Un seuil basé sur une seule version entraînera une classification erronée de certains d'entre eux ; veuillez donc vérifier le tableau du lieu de l'incident pour votre distribution et votre environnement d'exécution. Régénérez le magasin de confiance actif lorsque votre distribution l'exige.
3. Recréer les images et redémarrer les services. Téléchargez une image de base récente (docker build --pull --no-cache) afin que le bundle mis à jour soit intégré. Notez que toutes les images n'ont pas encore été mises à jour. Un conteneur en cours d'exécution conserve l'ancienne version.
4. Testez-le. Exécutez les deux commandes ci-dessous. Vous devez obtenir une erreur SSL avec le code HTTP 000.
5. Occupez-vous des retardataires. En ce qui concerne les outils intégrés à macOS, qu’Apple n’a pas encore mis à jour, le site consacré à l’incident publie commandes de contournement. Les environnements d'exécution intégrés tels que Node.js, Go, Java et certifi chacune nécessite sa propre version corrigée.

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/

Un client qui ne fait plus confiance aux certificats intermédiaires compromis rejette les deux requêtes en affichant une erreur SSL et affiche le message suivant : HTTP 000:

curl : (60) Problème de certificat SSL : impossible d'obtenir certificat d'émetteur certificat d'émetteur
HTTP 000

A 200 cela signifie que le client leur fait toujours confiance.

Pour savoir lesquels certificats CA version dont vous disposez :

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

Comment « Aikido » peut vous aider

Si vous êtes client d'Aikido , les images de conteneurs sont vérifiées automatiquement. La vérification porte à la fois sur les paquets qui intègrent leurs propres ensembles de certificats et sur le magasin de certificats fourni par le système, et un ticket distinct est créé pour chacun d'entre eux.

Pour les paquets disposant de leur propre bundle, comme « certifi » de Python avant la version 2026.10.18, une image se voit attribuer un niveau de risque « Critique ». Quant au magasin de confiance du système, qui continue d’accepter des chaînes passant par les intermédiaires compromis, il se voit attribuer un niveau de risque « Élevé ». Chaque problème s’accompagne d’un correctif correspondant aux étapes décrites ci-dessus, et les applications qui intègrent leurs propres certificats racine nécessitent des mises à jour distinctes.

Nous avons également publié la version 1.10.20 de Device Protection sous forme de correctif pour résoudre ce problème. Si vous utilisez Device Protection, nous vous recommandons d'effectuer cette mise à jour.

Ce qui s'est passé : huit touches, dont l'une est le 4

eMudhra est une autorité de certification basée en Inde : elle vérifie l'identité de l'exploitant d'un site web et délivre le certificat qui s'affiche sous le cadenas du navigateur ; elle bénéficie de la confiance des programmes racine de Firefox, Chrome, Apple et Microsoft. Une autorité de certification intermédiaire est un certificat de signature qui s'enchaîne à l'une de ces racines de confiance, et toute personne détenant sa clé privée peut signer un certificat valide pour n'importe quel domaine.

Le 17 octobre, un chercheur connu sous le nom de Wayne a signalé aux équipes chargées des programmes de base des navigateurs et des systèmes d’exploitation que les clés privées de huit certificats d’autorité de certification intermédiaire eMudhra avaient été compromises. Pour le prouver, Wayne a signé le message «Nous avons un problème ici » avec chacune des huit clés. Ces certificats datent d’avril 2025. eMudhra a généré ces clés de manière incorrecte, ce qui signifie que n’importe qui peut les récupérer à partir des certificats publics.

Une clé privée est un nombre secret qui doit être impossible à deviner. Une clé de ce type, générée correctement, est choisie parmi un ensemble d'environ 10^115 valeurs, soit un 1 suivi de 115 zéros. D'après l'analyse de notre équipe, chacune de ces huit clés est inférieure à 256, et l'une d'entre elles est égale à 4.

Une explication possible de ces petites clés serait un bug classique de conversion de type, dans lequel le grand nombre aléatoire aurait été accidentellement converti en octet. Une autre théorie faisait référence à un ancien comportement de Go, selon lequel une conversion décimale tronquait le nombre à un seul octet.

Le chiffre 4 apparaît également dans le dessin xkcd n° 221, où une fonction de génération de nombres aléatoires renvoie 4 et où un commentaire affirme qu'il a été choisi en lançant un dé impartial. Un pirate avait besoin d’au plus 256 tentatives pour trouver n’importe laquelle des huit clés, contre les quelque 10^115 qu’il aurait dû en faire, et un ordinateur portable peut essayer les 256 combinaisons avant même que vous n’ayez fini de lire cette phrase. Un antivol de vélo à trois chiffres offre 1 000 combinaisons ; le verrou de votre vélo donne donc plus de travail à un voleur que ces clés n’en ont donné à un pirate.

‍

Pourquoi les navigateurs sont corrigés et pourquoi ce n'est peut-être pas le cas de curl

Mozilla, Google, Apple et Microsoft transmettent les informations de révocation à leurs navigateurs via des mécanismes tels que OneCRL, CRLite et CRLSets, ce qui permet de bloquer un intermédiaire malveillant sans avoir à attendre une mise à jour logicielle. eMudhra a également révoqué les certificats, mais seul un client qui vérifie la révocation peut s'en rendre compte.

La plupart des outils en ligne de commande et des environnements d'exécution n'effectuent pas cette vérification. Ils disposent d'une liste de certificats racine de confiance et acceptent tout certificat s'inscrivant dans la chaîne de confiance de l'un d'entre eux ; par conséquent, le seul moyen de les empêcher de faire confiance à un certificat intermédiaire compromis est de leur fournir une nouvelle liste. Selon le site dédié à cet incident, de nombreux clients hors de l'écosystème des navigateurs ignorent complètement les données de révocation ; seule une mise à jour logicielle permet donc de les protéger.

macOS en est l'exemple le plus flagrant. Les appareils Apple bloquent ces certificats au niveau du système d'exploitation, mais la commande « curl » intégrée lit /etc/ssl/cert.pem, qui n'a fait l'objet d'aucune mise à jour. Un navigateur et un terminal installés sur le même ordinateur portable peuvent ne pas s'accorder sur la validité d'un même certificat.

Les conteneurs introduisent un délai supplémentaire. Une image Docker fige son ensemble de certificats de signature (CA) au moment de la compilation ; ainsi, toutes les images compilées avant le correctif, ainsi que toutes celles compilées depuis à partir d’une ancienne couche de base, continuent de faire confiance aux intermédiaires compromis jusqu’à ce que quelqu’un les recompile. Voici quelques exemples au 22 octobre : grafana/grafana:dernière version, mysql : dernière version, jenkins/jenkins : dernière version & bitnami/postgresql : dernière version.

Fonctionnement du système de confiance des certificats, en bref

Un certificat est la carte d'identité numérique d'un site web. Lorsque vous ouvrez un site HTTPS, le serveur envoie son certificat et votre client vérifie que le nom correspond bien au site, que les dates sont valides et que la signature provient d'une entité de confiance.

Le signataire est une autorité de certification (CA). Votre système d'exploitation ou votre navigateur intègre une liste des autorités de certification racines auxquelles il fait confiance. Les autorités de certification racines restent hors ligne et délèguent les tâches quotidiennes à des autorités de certification intermédiaires, qui signent les certificats réellement utilisés par les sites web. Un certificat dont la chaîne de certification remonte, via une autorité intermédiaire, jusqu'à une autorité de certification racine de confiance est accepté.

La clé privée d'un intermédiaire peut signer un certificat valide pour n'importe quel domaine ; ainsi, une fuite de cette clé permet d'abuser de l'autorité de la racine jusqu'à ce que les clients reçoivent l'ordre de ne plus lui faire confiance.

Chronologie

Mises à jour et sources

22 octobre 2026 : première publication. L'état des correctifs évolue quotidiennement ; veuillez donc consulter le tableau du site dédié aux incidents correspondant à votre distribution et à votre environnement d'exécution.

Sources :

• eMudhra Intermediate CA Compromise, site consacré à cet incident, géré par Dennis Jackson et ses contributeurs
• Rapport d'incident de Mozilla, accessible via le lien figurant sur la page dédiée aux incidents

‍