Chrome bloque les certificats après des détournements des registres .gh, .sl et .as

L'équipe de Chrome chez Google est intervenue la semaine dernière pour bloquer des certificats HTTPS non autorisés émis pour des domaines sous les extensions .gh, .sl et .as. Le fournisseur du navigateur a agi après que des attaquants ont compromis ces registres spécifiques de domaines de premier niveau à code pays (ccTLD), leur permettant de modifier les enregistrements DNS et de demander des certificats valides pour des sites ciblés. Cet incident met en lumière la fragilité du système mondial de noms de domaine et le besoin critique d'une surveillance proactive des certificats par les propriétaires de domaines.

Ce qui s'est passé

La faille de sécurité ne provenait pas de l'infrastructure de Google, mais au niveau des registres ccTLD tiers du Ghana (.gh), de la Sierra Leone (.sl) et des Samoa américaines (.as). Les attaquants ont pris le contrôle de ces registres et modifié les enregistrements DNS faisant autorité. Avec ce contrôle sur le DNS, ils ont pu passer les vérifications de validation de domaine exigées par les autorités de certification (CA). Par conséquent, les attaquants ont obtenu des certificats HTTPS non autorisés pour plusieurs domaines de Google ainsi que pour des domaines appartenant à d'autres organisations.

Dès la détection de l'anomalie, l'équipe Secure Web and Networking de Chrome a immédiatement déployé des CRLSets pour bloquer l'utilisation de ces certificats non autorisés dans le navigateur Chrome. Les CRLSets sont un mécanisme utilisé par Chrome pour révoquer des certificats qui restent techniquement valides mais dont on sait qu'ils sont compromis ou mal émis. L'équipe a également coordonné avec les CA émettrices pour garantir la révocation formelle des certificats, protégeant ainsi les utilisateurs d'autres navigateurs. Chrome a déclaré qu'il n'y avait aucune indication que les CA elles-mêmes aient agi incorrectement ; elles ont émis des certificats basés sur les données DNS manipulées fournies par les attaquants.

Une analyse plus approfondie des journaux publics Certificate Transparency (CT) a révélé que la surface d'attaque était plus large que prévu initialement. Plusieurs grandes marques mondiales et services en ligne très utilisés ont également été touchés par ces mêmes compromissions de registres. Chrome a bloqué proactivement les certificats pour ces entités supplémentaires afin de protéger les utilisateurs tout en contactant les organisations affectées lorsque cela était possible. Le fournisseur du navigateur a souligné que les utilisateurs de Chrome n'avaient aucune action manuelle à effectuer, car les protections étaient appliquées automatiquement.

Détails clés

• Espaces de nommage affectés : Les détournements ont spécifiquement ciblé les ccTLD .gh (Ghana), .sl (Sierra Leone) et .as (Samoa américaines).
• Vecteur d'attaque : La compromission des registres ccTLD tiers a permis aux attaquants de modifier les enregistrements DNS faisant autorité.
• Résultat : Les attaquants ont obtenu des certificats HTTPS non autorisés pour des domaines de Google et d'autres organisations.
• Réponse de Chrome : Les certificats non autorisés ont été bloqués via CRLSets, et les CA émettrices ont été contactées pour révocation.
• Impact plus large : Les journaux Certificate Transparency ont montré que d'autres marques et services mondiaux étaient probablement touchés.
• Implication des CA : Google n'a trouvé aucune preuve que les autorités de certification aient agi de manière inappropriée lors de l'émission.

Contexte

Pour comprendre cet incident, il est utile de savoir comment les certificats HTTPS sont émis. Lorsqu'un propriétaire de site web demande un certificat, la CA doit vérifier que le demandeur contrôle le domaine. Cela se fait souvent en vérifiant les enregistrements DNS. Si un attaquant contrôle le registre gérant ces enregistrements DNS, il peut rediriger les vérifications de validation vers ses propres serveurs, trompant ainsi la CA pour qu'elle émette un certificat. On parle alors de détournement DNS.

Certificate Transparency (CT) est un système de registre public conçu pour détecter ces émissions erronées. Chaque CA fiable doit consigner chaque certificat qu'elle émet dans ces journaux publics. Cela permet aux propriétaires de domaines et aux navigateurs de rechercher des certificats émis sans leur connaissance. Dans ce cas, les journaux CT ont été essentiels pour révéler l'étendue complète de l'attaque au-delà des seules propriétés de Google. Les CRLSets, quant à eux, sont une fonctionnalité spécifique à Chrome qui permet à Google de pousser des révocations d'urgence vers les navigateurs plus rapidement que le processus global de révocation standard.

Pourquoi c'est important

Pour les équipes qui exploitent leurs propres logiciels ou gèrent des domaines d'entreprise, cet incident sert de rappel sévère que vous ne contrôlez pas entièrement la sécurité de votre domaine si vous vous reposez uniquement sur le comportement par défaut des CA. Même si vos systèmes internes sont sécurisés, une compromission au niveau du registre peut entraîner l'émission de certificats valides pour votre domaine. Ces certificats peuvent être utilisés pour des attaques de type homme du milieu (man-in-the-middle), interceptant le trafic utilisateur et volant des identifiants. Se fier aux fournisseurs de navigateurs comme Google pour détecter ces problèmes est risqué, car leurs interventions peuvent ne pas couvrir tous les navigateurs ou tous les domaines affectés.

De plus, la dépendance au DNS pour la validation signifie que toute faiblesse dans la chaîne de confiance—du registrar au registre—peut compromettre votre sécurité HTTPS. Pour les applications auto-hébergées, où vous gérez peut-être votre propre DNS et vos certificats, il est crucial de comprendre les dépendances externes. Si votre domaine est hébergé sur un TLD compromis, vos mesures de sécurité internes peuvent être contournées avant même que le trafic n'atteigne votre serveur. La surveillance proactive n'est plus optionnelle ; elle constitue une couche de défense nécessaire contre les défaillances systémiques de l'infrastructure.

Ce que vous pouvez faire

• Surveiller les journaux Certificate Transparency : Mettez en place une surveillance automatisée pour tous vos domaines afin de recevoir des alertes chaque fois qu'un nouveau certificat est émis. Cela offre une détection quasi temps réel des émissions non autorisées.
• Publier des enregistrements CAA restrictifs : Utilisez les enregistrements DNS Certification Authority Authorization (CAA) pour spécifier exactement quelles CA sont autorisées à émettre des certificats pour vos domaines. Cela limite la surface d'attaque même si le DNS est compromis.
• Lier les comptes ACME dans CAA : Là où c'est pris en charge, restreignez l'émission de certificats à des liaisons de compte ACME spécifiques. Cela empêche les attaquants d'utiliser des données de validation mises en cache pour créer de nouveaux certificats après avoir repris le contrôle du DNS.
• Examiner les ccTLD régionaux : Si vous exploitez des domaines en .gh, .sl ou .as, ou d'autres extensions régionales, examinez immédiatement les entrées récentes des journaux CT pour toute activité inattendue.
• Auditer votre portefeuille de domaines : Assurez-vous que votre surveillance couvre tous les domaines, y compris ceux mis en veille ou hérités, car les attaquants ciblent souvent les actifs moins surveillés.
• Ne pas compter uniquement sur le blocage par le navigateur : Implémentez vos propres capacités de détection et de réponse, car les interventions côté navigateur ne garantissent pas la protection des utilisateurs hors Chrome ni la capture de chaque instance.