Rapports Google DNS kidnapping: certificats TLS pour google.com.gh, google.sl et google. comme

Google a rapporté le 6 octobre que les attaquants ont réussi à délivrer des certificats HTTPS non autorisés pour les noms de Google et YouTube après avoir compromis les enregistrements DNS faisant autorité de trois domaines de haut niveau avec code pays : .gh (Ghana), .sl (Sierra Leone) et .as (Samoa américaines). Selon les registres publics de Certificat Transparency (CT), entre le 22 et le 27 septembre, au moins douze certificats ont été ajoutés pour des variantes de ces noms (par exemple, google.com.gh, google.sl et google.as); Encryptons émis 11 et ZeroSSL émis un. Google précise que ses propres systèmes internes n'ont pas été violés; le chemin d'attaque était la manipulation de DNS dans ces ccTLD.

En termes techniques, ce qui s'est passé est un type classique d'enlèvement de zone DNS: les attaquants ont changé les enregistrements faisant autorité qui indiquent quels serveurs répondent pour un domaine. Les autorités de certification (Cans) vérifient le contrôle d'un nom de domaine avant de délivrer un certificat et une forme régulière de vérification est d'obliger le demandeur à placer un registre DNS spécifique ou à signifier un jeton sur une URL de domaine. En prenant le contrôle de la zone DNS, les attaquants ont pu répondre à ces tests et obtenir ainsi des certificats valides délivrés par Cans légitime. Avec un certificat valide en main, un attaquant capable d'intercepter le trafic (par exemple, dans un réseau Wi-Fi public ou par un routage malveillant) peut présenter le certificat et établir des connexions cryptées apparemment légitimes, ce qui permettrait de lire ou de traiter des données confidentielles.

Faits vérifiés : Google a bloqué les certificats non autorisés dans Chrome en utilisant CRLSet - le mécanisme de verrouillage rapide de certificat d'urgence du navigateur - et a travaillé avec les CA pour révoquer les certificats, selon sa déclaration. Les enregistrements CT montrent les entrées et les annulations; les recherches dans les services publics tels que Ctlogs.dev et des outils de suivi tels que Cert Spotter a confirmé la présence et la révocation subséquente des empreintes enregistrées. Google a également dit qu'il a détecté des indications que d'autres organisations - les marques et les services largement utilisés - ont été touchés par le même modèle, bien qu'ils ne les aient pas identifiés publiquement.

Ce qui est encore incertain et non confirmé par Google inclut si l'un de ces certificats ont été effectivement utilisés dans des attaques actives contre les utilisateurs pour lire des données, l'identité des attaquants, la méthode exacte par laquelle les enregistrements DNS de chaque ccTLD ont été commis et si les enregistrements ou les enregistrements de ces ccTLD ont été complètement remis. Google a également noté que, en raison de la complexité des enlèvements DNS, il ne peut garantir que son analyse a détecté tous les domaines touchés.

L'incident expose plusieurs vulnérabilités dans la chaîne de confiance de l'écosystème TLS/DNS. Premièrement, la délivrance de certificats fondés sur des tests de validation de domaine dépend de l'intégrité du système DNS : si le signal de contrôle peut être falsifié par un détournement de zone, l'AC peut légitimement délivrer un certificat à un attaquant. Deuxièmement, les AC peuvent réutiliser des contrôles préalables pour accélérer les émissions subséquentes; les règles du Baseline Requirements (CA / Browser Forum) fixent des délais pour que cette réutilisation soit réduite dans les années à venir, et certains fournisseurs comme Let's Encrypt ont déjà annoncé des changements dans leur temps de réutilisation. Ces détails expliquent pourquoi un contrôle de domaine temporaire peut donner lieu à des certificats valides pendant des jours.

Les conséquences réelles varient selon le rôle : pour les utilisateurs finaux, le risque principal est une attaque humaine en moyenne qui présente l'un de ces certificats et déchiffrements de trafic apparemment chiffré. Pour les opérateurs de domaine et les fournisseurs de services, la conséquence est la perte de contrôle et le remplacement possible des services; en outre, la nécessité de vérifier rapidement les registres de CT, de révoquer les certificats et de vérifier l'intégrité des zones DNS. Pour les AC, l'événement nécessite l'examen des procédures de validation et l'accélération des politiques qui réduisent la fenêtre de réutilisation des contrôles de domaine.

Google et les Cans ont pris des mesures concrètes et visibles: blocage dans Chrome à travers CRLSet et demandes de révocation aux émetteurs Cans. Cependant , Google a averti que les protections Chrome ne sont pas assez pour tous les navigateurs et que les propriétaires de domaine ne devraient pas se fier uniquement sur le navigateur pour protéger leurs utilisateurs .

Recommandations pratiques et spécifiques (qui devrait faire quoi): les propriétaires de domaine dans l'un de ces ccTLD ou avec des sous-domaines régionaux devraient immédiatement les registres de transparence des certificats d'audit pour toutes les variantes de leurs noms - y compris les domaines garés et régionaux - en utilisant les services de surveillance du CT et en examinant les certificats non sollicités. Publier une CAA(Autorisation de l'autorité de certification) strict que les limites que les AC peuvent délivrer des certificats pour leur domaine et, lorsque l'AC le permet, de l'attribuer à votre compte dans cette AC pour réduire les risques. Il signale immédiatement toute question non autorisée à l'AC émettrice au moyen d'un rapport de problème de certificat; les AC sont tenues d'enquêter et de réagir rapidement conformément aux règles du secteur.

En outre, et bien que Google l'ait déjà suggéré indirectement, les administrateurs DNS et les responsables du registre doivent vérifier les pouvoirs et l'accès à leurs comptes d'enregistrement et aux serveurs de noms faisant autorité : authentification multifactorielle active dans les comptes d'enregistrement, appliquer des verrous de transfert, examiner les changements dans les serveurs de noms et enregistrer les alertes SOA / changement série. Mettre en œuvre ou vérifier le DNSSEC dans ses zones dans la mesure du possible; le DNSSEC n'est pas une panacée et n'est pas toujours disponible pour tous les ccTLD, mais il ajoute une couche qui rend difficile le traitement des informations de délégation sur la route. Enfin, réduisez la fenêtre de confiance dans les validations de domaine lorsque votre CA le permet (p. ex. utilisez des CA qui ne réutilisent pas les vérifications à long terme).

Pour les utilisateurs finaux, la recommandation immédiate est de tenir les navigateurs et les systèmes à jour: Chrome a déjà bloqué les certificats affectés, mais d'autres navigateurs peuvent prendre plus de temps pour recevoir des retorations et des mises à jour. Évitez les réseaux Wi-Fi publics peu fiables et, si vous manipulez des informations sensibles, envisagez d'utiliser des réseaux privés ou VPN fiables au fur et à mesure que les enquêtes se poursuivent.

Enfin, cet incident souligne l'importance d'une surveillance constante: Certificat Transparence est un outil public qui permet de détecter les émissions inhabituelles, mais il ne fonctionne que si les propriétaires l'utilisent. La documentation et les ressources sur l'EC et la surveillance publique sont disponibles sur la page officielle du certificat Transparence et dans les services de surveillance tels que Cert Spotter; ceux qui gèrent des domaines doivent les intégrer dans leurs processus de sécurité. D'autres informations techniques sur le CT et les ressources pour commencer peuvent être trouvées à certificat-transparency.org et Documentation de Cert Spotter.