Des détournements DNS sur trois ccTLDs ont conduit à de faux certificats Google

Le 6 octobre, Google a révélé que des attaquants avaient compromis les registres de trois domaines de premier niveau nationaux (ccTLDs) afin d'obtenir des certificats HTTPS non autorisés pour plusieurs de ses domaines. Les extensions affectées étaient le .gh (Ghana), le .sl (Sierra Leone) et le .as (Samoa américaines). Bien que les systèmes internes de Google soient restés sécurisés, cette faille a permis aux acteurs malveillants d'usurper l'identité des services Google via des connexions chiffrées, posant un risque important pour la confidentialité des données des utilisateurs.

Ce qui s'est passé

Les attaquants ont pris le contrôle des enregistrements DNS faisant autorité pour les domaines sous ces trois ccTLDs. En modifiant ces enregistrements, ils ont démontré leur contrôle du domaine auprès des autorités de certification (CA), ce qui est la méthode standard de validation de la propriété avant l'émission d'un certificat TLS. Ce processus leur a permis de demander et d'obtenir des certificats valides pour des noms tels que google.com.gh, google.sl et youtube.as. Google a indiqué qu'il n'avait aucune raison de croire que les CA avaient agi de manière incorrecte, car elles ont suivi les procédures de validation standard basées sur les données DNS manipulées.

Les journaux de Transparence des Certificats (CT), qui servent de registre public de tous les certificats émis, ont révélé au moins 12 certificats non autorisés émis entre le 22 et le 27 septembre. Let’s Encrypt a émis 11 de ces certificats, tandis que ZeroSSL en a émis un. Les attaques se sont déroulées par vagues, avec les domaines .gh ciblés le 22 septembre, les .sl le 25 septembre et les .as le 27 septembre. Google a collaboré avec les CA respectives pour révoquer ces certificats et a utilisé la fonctionnalité CRLSets de Chrome pour les bloquer dans son navigateur. Cependant, les utilisateurs d'autres navigateurs sont restés vulnérables jusqu'à ce que les révocations se propagent mondialement.

Détails clés

• Registres affectés : La compromission concernait les ccTLDs du Ghana (.gh), de la Sierra Leone (.sl) et des Samoa américaines (.as).
• Nombre de certificats : Au moins 12 certificats non autorisés ont été émis pour sept noms de domaine distincts de Google et YouTube.
• Autorités émettrices : Let’s Encrypt a émis 11 certificats et ZeroSSL en a émis un ; tous étaient validés par domaine.
• Chronologie : Les certificats ont été enregistrés entre le 22 et le 27 septembre, avec des révocations effectuées entre le 26 septembre et le 1er octobre.
• Méthode de détection : Les certificats non autorisés ont été identifiés grâce aux journaux CT publics via des services comme ctlogs.dev et Cert Spotter.
• Impact plus large : Google a indiqué que d'autres marques mondiales et services en ligne ont également été ciblés, bien que les noms spécifiques n'aient pas été divulgués.

Contexte

Pour comprendre cet incident, il est utile de savoir comment les certificats TLS sont émis. Les CA s'appuient sur la Validation de Domaine (DV) pour confirmer que le demandeur contrôle le domaine. Cela se fait souvent en vérifiant la présence d'un enregistrement spécifique dans les paramètres DNS du domaine. Si un attaquant compromet le registre DNS, il peut insérer ces enregistrements de validation, trompant ainsi la CA pour qu'elle émette un certificat. Une fois émis, ce certificat permet à l'attaquant de créer un clone chiffré convaincant du site légitime, facilitant les attaques de type homme du milieu (man-in-the-middle) où les données des utilisateurs peuvent être interceptées.

Les journaux de Transparence des Certificats (CT) ont été introduits pour atténuer ces risques en rendant publiques toutes les émissions de certificats. Cela permet aux propriétaires de domaines et aux chercheurs en sécurité de surveiller les certificats non autorisés. De plus, les enregistrements CAA (Certification Authority Authorization) permettent aux propriétaires de domaines de spécifier quelles CA sont autorisées à émettre des certificats pour leurs domaines. Bien que les enregistrements CAA puissent empêcher l'émission non autorisée par des CA non listées, ils sont inefficaces si l'attaquant a un contrôle total sur le DNS et peut supprimer ou modifier l'enregistrement CAA lui-même.

Pourquoi c'est important

Pour les équipes qui hébergent leur propre logiciel ou gèrent leurs propres domaines, cet incident souligne la fragilité de la confiance dans l'écosystème DNS. Même si votre infrastructure interne est sécurisée, une compromission au niveau du registre peut entraîner l'émission de certificats non autorisés pour vos domaines. Cela signifie que compter uniquement sur la présence d'une icône de cadenas HTTPS valide ne suffit plus pour garantir l'authenticité du site. Les auto-hébergeurs doivent activement surveiller les émissions de certificats inattendues pour détecter les potentielles prises de contrôle tôt.

De plus, le temps de réponse pour la révocation a varié considérablement, certains certificats restant valides près d'une semaine après leur détection. Pendant cette fenêtre, les utilisateurs visitant les sites usurpés ont pu voir leurs données exposées. Pour les responsables IT, cela met en évidence l'importance de disposer de systèmes de surveillance indépendants qui ne dépendent pas des éditeurs de navigateurs pour protéger les utilisateurs. La détection proactive via la surveillance des journaux CT peut réduire la fenêtre d'exposition et permettre un signalement et une révocation plus rapides.

Ce que vous pouvez faire

• Surveiller les journaux CT : Mettez en place des alertes automatisées pour tout nouveau certificat émis pour vos domaines en utilisant des services de surveillance des journaux CT. Cela inclut les domaines mis en parking et les variantes régionales de ccTLD.
• Implémenter des enregistrements CAA : Publiez des enregistrements CAA stricts dans votre DNS pour restreindre les CA pouvant émettre des certificats pour vos domaines. Assurez-vous que ces enregistrements sont liés à votre compte CA spécifique lorsque possible.
• Revoir la sécurité DNS : Auditez les paramètres de sécurité de votre registrar de domaine et de votre fournisseur DNS. Activez l'authentification multifacteur et examinez les journaux d'accès pour toute activité inhabituelle.
• Signaler les certificats non autorisés : Si vous détectez un certificat non autorisé, déposez immédiatement un rapport de problème de certificat auprès de la CA émettrice. Elle est tenue d'enquêter et de répondre dans les 24 heures.
• Vérifier les domaines régionaux : Si vous opérez dans ou avez des domaines sous .gh, .sl ou .as, vérifiez-les spécifiquement.