Comment un détournement de code de pays a brisé la chaîne de confiance d'Internet

Je me souviens avoir été assis dans un centre de données sans fenêtre en 2011 lorsque la nouvelle de DigiNotar est tombée. À l'époque, une seule autorité de certification compromise aux Pays-Bas avait permis à des attaquants de forger des identifiants frauduleux pour Google. C'était comme une trahison fondamentale des mathématiques qui assurent la sécurité du web. Avancez jusqu'à la fin de 2026, et l'industrie fait face à une version du même cauchemar, bien que le point d'entrée ait changé. Un appareil de sécurité de plusieurs milliards de dollars a été mis en échec par l'équivalent numérique d'un serrurier volant les passe-partout d'une quincaillerie de petite ville.

Google a récemment confirmé que des attaquants ont détourné trois domaines de premier niveau de code de pays (ccTLD) : .gh (Ghana), .sl (Sierra Leone) et .as (Samoa américaines). En prenant le contrôle de ces espaces de noms, les acteurs ont modifié les enregistrements DNS faisant autorité pour des cibles spécifiques de haute valeur. Ce contrôle leur a permis de contourner les vérifications de validation automatisées que les autorités de certification utilisent pour vérifier la propriété. Le résultat a été l'émission de certificats TLS non autorisés pour plusieurs domaines Google et d'autres grandes marques mondiales. C'est le paradoxe architectural de la sécurité moderne : une entreprise peut dépenser des millions en "zero trust" et en clés de sécurité matérielles, pourtant son identité numérique reste liée à la sécurité administrative d'un registre distant.

La mécanique du contournement du contrôle de domaine

Pour comprendre pourquoi cela s'est produit, nous devons examiner comment un site web prouve son identité. Lorsqu'une organisation demande un certificat TLS, l'autorité de certification (CA) émettrice doit vérifier que le demandeur contrôle réellement le domaine. La norme de l'industrie pour cela est la Validation de Contrôle de Domaine (DCV). La CA demande au demandeur d'effectuer une tâche spécifique, comme l'hébergement d'un fichier unique à une URL précise ou, plus couramment, la création d'un enregistrement DNS spécifique. Si la CA voit l'enregistrement correct sur les serveurs de noms faisant autorité, elle émet le certificat.

Dans cet incident, les attaquants n'ont pas eu besoin de pirater Google. Ils ont piraté l'infrastructure TLD elle-même. Une fois qu'ils ont contrôlé les serveurs de noms pour .gh, .sl et .as, ils ont pointé les enregistrements DNS des sous-domaines ciblés vers leurs propres serveurs. Lorsque la CA a effectué le contrôle automatisé, le serveur des attaquants a fourni la réponse correcte. La CA a suivi son protocole parfaitement, mais elle parlait à un imposteur. Le système est un coffre-fort numérique qui ne fonctionne que si le videur à la porte sait réellement à quoi ressemble le vrai propriétaire.

Pourquoi les blocages par navigateur sont une solution temporaire

Google a mis à jour Chrome pour bloquer immédiatement ces certificats non autorisés. C'est une mesure réactive qui protège des millions d'utilisateurs, mais elle souligne une faiblesse systémique. Le processus de révocation d'un certificat est notoirement lent. Les méthodes traditionnelles comme les listes de révocation de certificats (CRL) ou le protocole d'état de certificat en ligne (OCSP) échouent souvent en raison de préoccupations liées à la confidentialité ou de la latence du réseau. Par conséquent, les éditeurs de navigateurs se sont tournés vers des listes de blocage codées en dur pour fournir une protection immédiate.

Du point de vue du risque, cette intervention est un pansement. Google a admis que les interventions de Chrome ne protègent pas les utilisateurs sur d'autres navigateurs, et la société ne peut pas non plus être certaine d'avoir identifié chaque domaine affecté. Si un attaquant possède un certificat valablement signé qu'un navigateur n'a pas encore bloqué, il peut effectuer une attaque de l'homme du milieu (man-in-the-middle). Il peut intercepter le trafic, décrypter les données sensibles et présenter une icône de cadenas "sécurisé" à la victime. L'intégrité de la connexion a disparu, et l'utilisateur n'a aucun moyen de voir la différence.

La matière noire du réseau d'entreprise

Le DNS est souvent la matière noire de la sécurité en entreprise. Il est invisible, omniprésent et fréquemment négligé jusqu'à ce que quelque chose se brise. De nombreuses organisations traitent leurs relations avec les TLD comme une simple question de facturation plutôt que comme une dépendance de sécurité critique. Lorsque vous enregistrez un domaine dans un TLD de code de pays, vous placez votre confiance dans la sécurité du registre de cette nation, la stabilité de son gouvernement et sa résilience technique.

En examinant le paysage des menaces, cet incident démontre que les attaquants remontent la chaîne d'approvisionnement. Au lieu d'attaquer un périmètre endurci, ils ciblent les composants décentralisés de l'infrastructure centrale d'Internet. Une brèche au niveau du TLD est furtive car elle ne déclenche pas d'alarmes internes. Les serveurs de l'organisation vont bien, les employés ne cliquent pas sur des liens de phishing et le pare-feu est silencieux. Pourtant, l'identité de la marque est forgée ailleurs.

Mise en œuvre de l'autorisation de l'autorité de certification

Google conseille aux propriétaires de domaines de publier des enregistrements DNS de type Certification Authority Authorization (CAA) comme contre-mesure. Un enregistrement CAA est une déclaration de politique qui indique au monde quelles CA spécifiques sont autorisées à émettre des certificats pour un domaine. Si un acteur malveillant tente d'obtenir un certificat auprès de la CA "A", mais que l'enregistrement CAA ne liste que la CA "B", la demande doit être refusée.

Cependant, les enregistrements CAA ne sont efficaces que s'ils sont restrictifs et si les CA les respectent. Plus important encore, si un attaquant détourne le DNS, il peut simplement supprimer ou modifier l'enregistrement CAA avant de demander le certificat frauduleux. Google suggère que ces enregistrements peuvent empêcher les attaquants de réutiliser des données de validation mises en cache, mais ils ne sont pas une solution miracle. Ce sont des outils granulaires qui ajoutent une couche de friction pour l'attaquant, mais ils reposent toujours sur l'intégrité du DNS lui-même.

L'importance des journaux de transparence des certificats

En coulisses, le moyen le plus efficace de repérer ce genre d'activité est de passer par les journaux de Certificate Transparency (CT). Le CT est un système de journaux publics, consultables uniquement en ajout, qui enregistrent chaque certificat TLS émis par les CA participantes. Chaque fois qu'un certificat est forgé pour votre domaine, il apparaît dans ces journaux.

De manière proactive, chaque équipe de sécurité devrait surveiller ces journaux pour ses domaines. Si un certificat apparaît provenant d'une CA que vous n'utilisez pas, ou à un moment où vous n'en avez pas demandé, vous êtes probablement face à un détournement en cours. J'utilise plusieurs outils automatisés qui m'alertent via Signal à l'instant même où un nouveau certificat est émis pour toute propriété que je gère. Cette visibilité forensique est le seul moyen de détecter un détournement au niveau du TLD avant qu'il ne se transforme en une violation massive de données.

Leçons de l'ère DigiNotar

Cet incident rappelle que le système de certificats présente des failles systémiques. En 2011, la brèche de DigiNotar était une situation de prise d'otage numérique pour le peuple iranien, dont le trafic était intercepté par son gouvernement à l'aide de certificats forgés. Bien que le détournement actuel de TLD semble axé sur les marques et les services, la vulnérabilité technique est identique. Nous utilisons toujours un modèle de confiance centralisé dans un monde décentralisé.

Le chiffrement est un coffre-fort numérique incassable seulement si les clés sont manipulées avec une intégrité absolue. Lorsque l'infrastructure qui valide ces clés est compromise, la porte du coffre est laissée grande ouverte. Les attaquants dans ce cas ont montré que vous n'avez pas besoin de briser le chiffrement pour gagner. Il vous suffit de convaincre le système que vous êtes le propriétaire légitime du coffre.

Conseils pratiques pour les responsables de la sécurité

La sécurité consiste souvent à gérer des dépendances que vous ne contrôlez pas. Bien que vous ne puissiez pas sécuriser l'infrastructure d'un registre TLD étranger, vous pouvez contrôler la manière dont votre organisation réagit à ces risques.

• Auditez votre portefeuille de domaines et identifiez les domaines enregistrés sous des ccTLD dotés de protocoles de sécurité moins stricts.
• Publiez des enregistrements CAA pour tous les domaines critiques afin de limiter les autorités pouvant émettre des identifiants.
• Mettez en place une surveillance en temps réel des journaux de Certificate Transparency pour détecter toute émission non autorisée en quelques minutes.
• Activez les extensions de sécurité DNS (DNSSEC) lorsque cela est possible pour ajouter des signatures cryptographiques à vos données DNS, rendant les détournements plus difficiles à exécuter.
• Révisez votre plan de réponse aux incidents pour inclure un protocole de révocation rapide des certificats et de coordination avec les éditeurs de navigateurs.

En tant que contre-mesure, ces étapes garantissent que même si le registre TLD échoue, votre équipe dispose de la visibilité nécessaire pour réagir avant que les dommages ne deviennent systémiques. L'objectif est de passer d'une posture réactive à une posture résiliente. La sécurité n'est pas un état que l'on atteint, mais un processus que l'on maintient.

Sources :

• Google Security Blog: Tracking Recent TLD Hijacks and Unauthorized Certificates
• NIST Special Publication 800-15: Minimum Interoperability Requirements for PKI Components
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
• RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record
• MITRE ATT&CK Framework: T1584.001 (Compromise Infrastructure: Domains)

Avertissement : Cet article est fourni à titre informatif et éducatif uniquement et ne remplace pas un audit professionnel de cybersécurité ou un service de réponse aux incidents.