Clés de l'AC eMudhra compromises, déclenchant des correctifs urgents pour les navigateurs et les environnements d'exécution

Le programme racine Chrome de Mozilla et Google a confirmé le 20 octobre que les clés privées de huit certificats d'autorité de certification (AC) intermédiaires d'eMudhra avaient été compromises. Cet incident de sécurité critique a entraîné des correctifs d'urgence immédiats dans les principaux navigateurs web et environnements d'exécution logiciels afin de prévenir d'éventuelles attaques de type homme du milieu (man-in-the-middle). Le compromis a été signalé par un chercheur le 17 octobre, conduisant à des actions de blocage rapides par Chrome et Firefox dans les heures suivant la vérification.

Ce qui s'est passé

Au cœur de cet incident se trouve le vol ou l'accès non autorisé aux clés privées appartenant à eMudhra, une autorité de certification indienne qui émet des certificats numériques sous la marque emSign. Ces clés spécifiques appartiennent à des certificats intermédiaires, utilisés pour signer les certificats des entités finales (sites web et logiciels). La possession de ces clés privées permet à un attaquant d'émettre des certificats TLS valides pour n'importe quel domaine, que les navigateurs considéreraient normalement comme légitimes. Le compromis affecte six intermédiaires utilisés pour le chiffrement TLS et deux utilisés pour la signature de code, couvrant les types de certificats à validation de domaine, à validation d'organisation et à validation étendue.

Un chercheur en sécurité, identifié uniquement sous le nom de Wayne, a signalé le problème aux opérateurs des programmes racines dans la soirée du 17 octobre. Wayne a démontré sa possession des clés en signant un message avec chacune des huit clés privées compromises. Chrome a vérifié les constatations et mis en œuvre un blocage via son mécanisme CRLSet à 19h45 UTC le 17 octobre. Mozilla a suivi, poussant un blocage OneCRL vers les installations Firefox à 22h59 UTC ce même jour. Ces mécanismes permettent aux navigateurs de révoquer la confiance accordée à des certificats spécifiques sans nécessiter une mise à jour complète du logiciel ou un redémarrage. Apple a bloqué les certificats le 19 octobre, et Microsoft a suivi le 20 octobre.

Crucialement, aucun certificat TLS chaînant aux six intermédiaires web affectés n'avait été enregistré dans les journaux Certificate Transparency avant que Chrome ne mette en œuvre son blocage. Cela suggère que, bien que les clés aient été compromises, elles n'ont peut-être pas été utilisées pour émettre des certificats frauduleux publiquement visibles et considérés comme fiables par défaut dans Chrome. Cependant, il reste inconnu comment les clés ont été exfiltrées, quand la violation s'est produite, ou si d'autres acteurs outre le chercheur rapporteur les possèdent. Go, le langage de programmation, a également publié des mises à jour de sécurité urgentes le 20 octobre pour rejeter les chaînes contenant ces clés, traitant le problème avec une sévérité maximale en raison de la menace potentielle pour l'intégrité de l'écosystème.

Détails clés

• Huit clés privées d'AC intermédiaires eMudhra ont été compromises, affectant à la fois les certificats TLS et de signature de code.
• Chrome et Firefox ont bloqué les certificats dans les heures suivant le rapport du 17 octobre, utilisant respectivement CRLSet et OneCRL.
• Aucun certificat TLS frauduleux chaînant aux intermédiaires affectés n'a été trouvé dans les journaux Certificate Transparency avant le blocage.
• Go a publié les versions 1.27.3 et 1.26.10 le 20 octobre pour rejeter strictement ces clés, obligeant les développeurs à reconstruire leurs applications.
• Mozilla a retiré la racine emSign ECC Root CA - G3 de son magasin de confiance NSS, ce qui peut causer des problèmes de connectivité pour les serveurs utilisant encore cette racine.
• Le bundle certifi de Python et les webpki-roots de Rust ont été mis à jour pour supprimer la racine affectée, nécessitant des mises à jour de paquets pour les services backend.

Contexte

Pour comprendre la gravité de la situation, il est nécessaire de distinguer les certificats racines des certificats intermédiaires. Un certificat racine est l'ancre ultime de confiance dans un navigateur ou un système d'exploitation. Les certificats intermédiaires agissent comme des ponts, signés par la racine, qui signent ensuite les certificats réels utilisés par les sites web. Cette hiérarchie permet aux AC de conserver leurs clés racines hautement sensibles hors ligne et sécurisées. Lorsqu'une clé intermédiaire est compromise, comme dans ce cas, les dommages sont plus facilement contenus qu'en cas de compromission d'une racine, mais cela permet toujours aux attaquants d'usurper l'identité de n'importe quel site web faisant confiance à cet intermédiaire.

Certificate Transparency (CT) est un système de registre public qui enregistre tous les certificats TLS émis. Il sert de piste d'audit, permettant aux propriétaires de domaines et aux navigateurs de détecter les certificats mal émis. Le fait qu'aucun journal CT n'existait pour les intermédiaires eMudhra compromis avant le blocage est un signe positif, indiquant qu'un abus à grande échelle a peut-être été prévenu ou est passé inaperçu par la surveillance publique. Cependant, de nombreux systèmes backend et clients anciens n'appliquent pas strictement la journalisation CT ni ne vérifient les listes de révocation comme CRLSet, les rendant vulnérables tant que leurs magasins de confiance ne sont pas explicitement mis à jour.

Pourquoi c'est important

Pour les équipes gérant des logiciels auto-hébergés, cet incident met en lumière la fragilité de la confiance implicite envers les autorités de certification tierces. Alors que les navigateurs web reçoivent des mises à jour automatiques de révocation, de nombreuses applications côté serveur, outils internes et microservices dépendent de bundles de confiance statiques ou de magasins de certificats au niveau du système qui ne se mettent pas à jour automatiquement. Par exemple, les applications Python utilisant le bundle certifi ou les binaires Go compilés avec des anciennes versions continueront à faire confiance aux clés compromises jusqu'à ce que les bibliothèques sous-jacentes soient mises à jour et que l'application soit redéployée. Cela crée une fenêtre de vulnérabilité pour les API internes et la communication service-à-service reposant sur l'authentification mutuelle TLS.

De plus, le retrait de la racine emSign ECC Root CA - G3 des magasins de confiance tels que NSS de Mozilla et certifi de Python signifie que tout service légitime utilisant encore des certificats chaînants à cette racine deviendra soudainement inaccessible. Il ne s'agit pas seulement d'un correctif de sécurité, mais potentiellement d'un incident de disponibilité. Les ingénieurs DevOps doivent vérifier si certaines de leurs dépendances externes ou intégrations partenaires utilisent des certificats eMudhra. Si c'est le cas, ces connexions échoueront jusqu'à ce que la partie distante réémette ses certificats sous une autre racine fiable. Cela souligne la nécessité d'une surveillance active de la validité des certificats et des changements d'émetteur, plutôt que de supposer une fiabilité « configurer et oublier ».

Ce que vous pouvez faire

• Mettez à jour toutes les installations Go vers la version 1.27.3 ou 1.26.10 immédiatement et reconstruisez tous les binaires affectés pour garantir que la nouvelle logique de rejet est active.
• Vérifiez vos environnements Python et mettez à jour le paquet certifi vers la version 2026.10.19 ou ultérieure pour retirer la racine non fiable de votre bundle.
• Auditez vos logs de serveur pour toute connexion à des services utilisant des certificats eMudhra, car celles-ci peuvent désormais échouer suite au retrait de la racine dans les magasins de confiance mis à jour.
• Vérifiez que vos systèmes de surveillance interne contrôlent les changements d'émetteur de certificats, et pas seulement les dates d'expiration, pour détecter précocement des migrations ou compromissions similaires.
• Assurez-vous que vos installations Firefox sont mises à jour vers la version 158.0.1, ESR 115.43.1 ou ESR 153.5.1 si elles ne peuvent pas recevoir les mises à jour Remote Settings automatiquement.
• Revoyez la gestion de vos dépendances pour les projets Rust et Node.js, en surveillant les mises à jour en attente pour webpki-roots et Node.js lui-même qui adressent ce compromis.