Des attaquants ont obtenu des certificats HTTPS de confiance pour des domaines Google sans pirater les systèmes de Google. Ils ont plutôt compromis l'infrastructure de registres de domaines de fournisseurs tiers, exploitant une faiblesse dans la manière dont les identités des sites web sont vérifiées.
Dans une divulgation publiée le 6 octobre 2026, Google a déclaré que des attaquants avaient compromis l'infrastructure prenant en charge trois domaines nationaux : .gh (Ghana), .sl (Sierra Leone) et .as (Samoa américaines). En manipulant les enregistrements DNS faisant autorité, ils ont obtenu des certificats non autorisés pour des services Google et d'autres organisations. Google a bloqué les certificats identifiés dans Chrome et collaboré avec les autorités de certification émettrices pour les révoquer.
L'incident a mis en évidence un risque pour les entreprises qui exploitent des sites web régionaux. Une infrastructure de registre compromise peut saper la validation des certificats sans obliger les attaquants à pirater les systèmes de l'organisation concernée.
Comment les attaquants ont obtenu des certificats HTTPS non autorisés
Les autorités de certification (AC) délivrent des certificats HTTPS approuvés publiquement après avoir vérifié que les demandeurs contrôlent les domaines concernés. Les attaquants qui manipulent les enregistrements DNS faisant autorité peuvent satisfaire à ces vérifications sans l'autorisation des propriétaires légitimes des domaines.
Selon la divulgation de sécurité de Google, les certificats ont été délivrés dans le cadre de processus de validation établis, mais sans l'autorisation des propriétaires légitimes des domaines. Google a déclaré n'avoir aucune raison de penser que les autorités de certification émettrices avaient agi de manière indue.
Une enquête de The Hacker News a identifié 12 certificats couvrant sept noms de domaine Google et YouTube entre le 22 et le 27 septembre. Onze provenaient de Let's Encrypt et un de ZeroSSL. Les domaines concernés comprenaient google.com.gh, google.sl et google.as.
Les 12 avaient été révoqués au 7 octobre. Un représentant de Let's Encrypt a confirmé que des certificats pour des domaines Google et YouTube avaient été délivrés puis révoqués.
Google a utilisé le mécanisme CRLSet de Chrome pour bloquer les certificats non autorisés qu'il avait identifiés. Les journaux de transparence des certificats (CT) ont révélé d'autres organisations potentiellement touchées, ce qui a entraîné de nouveaux blocages et l'envoi de notifications.
Google a déclaré que les utilisateurs de Chrome n'avaient aucune mesure supplémentaire à prendre, tout en avertissant que les protections de son navigateur pouvaient ne pas détecter les domaines concernés et ne pouvaient pas protéger de manière fiable les utilisateurs d'autres navigateurs.
Les certificats auraient pu permettre d'usurper l'identité de sites web si les attaquants avaient également redirigé le trafic. Google n'a pas confirmé qu'ils avaient été utilisés pour intercepter des communications ou dérober des données.
Ce qu'a découvert eWeek : les détournements de registres révèlent les limites des contrôles des certificats
Restreindre les autorités émettrices de certificats ne garantit pas une protection lorsque les attaquants contrôlent le DNS faisant autorité. Les conclusions de Google révèlent un écart entre les politiques de certificats des entreprises et l'infrastructure externe utilisée pour vérifier le contrôle des domaines.
Les enregistrements d'autorisation des autorités de certification (CAA) limitent les AC autorisées à délivrer des certificats. Ils ne peuvent toutefois pas empêcher une délivrance pendant un détournement DNS actif. La documentation technique de Let's Encrypt décrit des restrictions propres aux comptes qui, lorsqu'elles sont prises en charge, peuvent fournir une protection supplémentaire une fois le contrôle DNS légitime rétabli.
La surveillance des journaux CT remplit une autre fonction : détecter les délivrances inattendues après leur survenue. Les 12 certificats identifiés dans les registres publics démontrent sa valeur pour les investigations, même si l'ampleur exacte des compromissions reste à déterminer.
La supervision des certificats s'étend également à l'infrastructure gérée par les fournisseurs cloud. La feuille de route de Google Cloud en matière de sécurité quantique examine la manière dont les responsabilités liées à la migration cryptographique sont réparties entre les fournisseurs et les clients.
Les entreprises devraient surveiller la délivrance de certificats pour leurs domaines régionaux et parqués, appliquer des politiques CAA restrictives et mettre en place des procédures d'enquête sur les certificats inattendus. De récentes évaluations red team de la CISA ont révélé d'autres faiblesses en matière de détection et de réponse dans les infrastructures critiques. De même, les mises à jour de Defender de Microsoft pour les agents d'IA locaux répondent au défi distinct que représente la découverte des actifs absents des inventaires de sécurité établis.
Google a bloqué les certificats qu'il avait identifiés, mais n'a pas pu garantir que tous les domaines concernés avaient été découverts. La surveillance des certificats des entreprises doit donc s'étendre au-delà de l'infrastructure gérée en interne.
Pour en savoir plus : à mesure que les exigences en matière de sécurité cryptographique évoluent, les organisations doivent également examiner le matériel prêt pour le quantique et ses capacités de sécurité revendiquées avant de considérer les assurances des fournisseurs comme des protections vérifiées.