Les clés faibles d'eMudhra permettent la falsification instantanée de certificats et un patching lent

Le 19 octobre 2026, Cloudflare a identifié une faille de sécurité critique impliquant eMudhra, une autorité de certification qui a généré huit clés privées intermédiaires avec une entropie négligeable. Au lieu d'utiliser des nombres complexes et imprévisibles, eMudhra a utilisé des entiers simples comme 4, 56 et 237, permettant à quiconque de reconstituer les clés privées à partir des certificats publics. Cette vulnérabilité sans précédent permet aux attaquants de falsifier des certificats TLS valides pour n'importe quel domaine, contournant ainsi les protections de chiffrement standard pour les clients non corrigés.

Ce qui s'est passé

Le problème central découle d'une erreur catastrophique dans le processus de génération de clés d'eMudhra. Une autorité de certification est censée choisir un nombre massif et aléatoire pour servir de fondement à sa sécurité cryptographique. Dans ce cas, eMudhra a sélectionné des nombres à un ou deux chiffres. Comme ces valeurs sont très petites, un attaquant peut récupérer la clé privée de signature presque instantanément en utilisant uniquement le certificat public. Cela diffère fondamentalement des violations passées de CA, telles que DigiNotar ou TrustWave, où les clés volées étaient des actifs protégés accessibles uniquement à certains acteurs malveillants. Ici, les clés sont mathématiquement triviales à dériver par n'importe qui disposant d'outils de base.

Cloudflare a réagi immédiatement en corrigeant ses systèmes à fort impact, y compris les proxys Pingora, dans les heures suivant la découverte. Ils ont employé l'analyse de code assistée par IA pour identifier tous les systèmes internes faisant confiance à ces clés faibles, attribuant des tickets de remédiation selon le niveau de risque. Pour surveiller l'exploitation réelle, Cloudflare a ajouté des journaux pour détecter les poignées de main impliquant les clés compromises. En une semaine, ils ont enregistré environ 22 000 tentatives de poignée de main. Bien que la plupart soient des tests bénins ou des configurations auto-signées, environ 160 tentatives impliquaient des certificats falsifiés nommant des domaines sans rapport, y compris des appareils IoT grand public. Ces falsifications sont apparues quelques heures seulement après la publication de la vulnérabilité, bien qu'aucune interception réussie du trafic Cloudflare n'ait été détectée.

Pour évaluer la vulnérabilité mondiale, Cloudflare a déployé des connexions de sonde via leurs pages de défi, testant si les navigateurs des visiteurs acceptaient les certificats signés par les clés faibles. Les données révèlent un retard inquiétant dans l'adoption des correctifs. Alors que les navigateurs de bureau modernes ont largement mis à jour, les systèmes embarqués comme Android WebView acceptent toujours les chaînes compromises à des taux de 30 à 40 %. De plus, plus de la moitié des sondes sur les principaux réseaux continuent de faire confiance aux certificats invalides, indiquant qu'une partie significative d'Internet reste exposée à des attaques potentielles de type homme du milieu (man-in-the-middle).

Détails clés

• eMudhra a utilisé des entiers extrêmement faibles (4, 56, 66, 115, 155, 156, 230, 237) pour huit clés privées intermédiaires.
• Les clés privées peuvent être récupérées instantanément à partir des certificats publics, permettant une falsification illimitée de certificats.
• Cloudflare a observé environ 22 000 tentatives de poignée de main utilisant les clés faibles dans la semaine suivant la divulgation.
• Des certificats falsifiés ont été créés dès le 20 octobre, moins d'une heure après la publication du rapport de bug par Mozilla.
• Plus de 50 millions de sondes indiquent que de nombreux navigateurs embarqués et bots font toujours confiance à la chaîne de certificats compromise.
• eMudhra a annoncé son retrait de l'activité de CA publique mais n'a pas publié le script de génération de clés défaillant.

Contexte

Les autorités de certification (CA) sont des tiers de confiance qui délivrent des certificats numériques pour vérifier l'identité des sites web. Ces certificats reposent sur la cryptographie à clé publique, où une clé privée signe les données et une clé publique les vérifie. La sécurité de ce système dépend entièrement du fait que la clé privée reste secrète et soit générée avec une haute entropie, ce qui signifie qu'elle est choisie dans un vaste pool de nombres possibles. Si le nombre est prévisible ou petit, la relation mathématique entre les clés publiques et privées devient facile à inverser.

Dans cet incident, le manque d'entropie signifiait que le "cadenas" protégeant le modèle de confiance d'Internet était effectivement laissé ouvert. Tout acteur pouvait générer un certificat valide pour un domaine cible, tel qu'un site bancaire ou un portail interne d'entreprise. Les clients qui n'appliquent pas la transparence des certificats (Certificate Transparency) ou ne vérifient pas les listes de révocation accepteront ces certificats falsifiés comme légitimes, permettant aux attaquants de déchiffrer et de modifier le trafic sans déclencher d'avertissements du navigateur.

Pourquoi c'est important

Pour les équipes gérant des infrastructures auto-hébergées ou des services internes, cet incident met en évidence la fragilité de la confiance implicite envers les CA externes. Même si votre organisation n'utilise pas directement eMudhra, les appareils de vos employés, les applications mobiles et les points de terminaison IoT pourraient toujours faire confiance aux certificats racines ou intermédiaires compromis. Si un attaquant falsifie un certificat pour votre domaine interne, les clients non corrigés pourraient se connecter à un serveur malveillant en croyant qu'il s'agit de votre service légitime. Ce risque est particulièrement aigu pour les systèmes hérités, les appareils embarqués et les bots automatisés qui ne reçoivent pas de mises à jour de sécurité régulières.

Le taux de correction lent parmi les navigateurs embarqués et les clients au niveau réseau suggère que les vulnérabilités de la chaîne d'approvisionnement persistent longtemps après la divulgation. Les responsables IT doivent supposer qu'une partie de leur base d'utilisateurs reste vulnérable à l'usurpation de certificats. Se fier uniquement aux mises à jour des navigateurs est insuffisant ; les organisations ont besoin d'une surveillance active pour détecter les utilisations anormales de certificats et garantir que leurs propres services rejettent explicitement les identifiants faibles ou révoqués. Cet événement souligne la nécessité de magasins de confiance dynamiques capables de révoquer rapidement les mauvais acteurs, plutôt que de compter sur des listes statiques qui mettent des mois à se propager.

Ce que vous pouvez faire

• Mettez à jour tous les systèmes d'exploitation, navigateurs et logiciels embarqués vers les dernières versions pour garantir que les racines faibles ne sont plus approuvées.
• Configurez les serveurs pour appliquer strictement la transparence des certificats et rejeter les certificats provenant de CA connues comme compromises.
• Surveillez les journaux pour les poignées de main TLS impliquant les clés intermédiaires d'eMudhra afin de détecter les tentatives d'interception potentielles.
• Auditez les applications internes et les appareils IoT pour confirmer qu'ils n'intègrent pas codés en dur la confiance pour les clés affectées d'eMudhra.
• Suivez les guides de remédiation collaboratifs, en particulier pour les développeurs macOS qui pourraient avoir besoin d'ajustements manuels du magasin de confiance.
• Implémentez des alertes automatiques pour les changements de certificats sur les domaines critiques afin de repérer rapidement les émissions non autorisées.