Contexte de l'attaque
Des acteurs malveillants ont compromis les registres de trois domaines de premier niveau nationaux – .gh (Ghana), .sl (Sierra Leone) et .as (American Samoa). En prenant le contrôle des serveurs DNS autoritaires de ces zones, ils ont pu modifier les enregistrements d’adresses IP et les délégations de serveurs de noms pour un ensemble ciblé de domaines. Cette prise de contrôle a permis de satisfaire les vérifications automatisées de validation de contrôle de domaine (Domain Control Validation, DCV) exigées par les autorités de certification lors de la demande de certificats.
Mécanisme de délivrance des certificats
Les certificats TLS X.509 sont émis après qu’une autorité de certification (CA) ait reçu une preuve cryptographique que le demandeur contrôle le nom de domaine. La plupart des CAs utilisent des méthodes DCV basées sur DNS : elles interrogent un enregistrement TXT ou CNAME spécifique que le propriétaire doit publier. En manipulant les enregistrements DNS des ccTLDs, les attaquants ont pu créer ces enregistrements factices, trompant ainsi les CAs et obtenant des certificats valides pour « plusieurs domaines Google » et d’autres marques mondiales. Le processus de révocation, qui repose sur les listes de révocation (CRL) et le protocole OCSP, est lent, ce qui a conduit Google à intervenir directement au niveau du navigateur.
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 iodef "mailto:security@example.com"Réaction de Google et mesures d’atténuation
Google a publié une mise à jour de Chrome bloquant immédiatement tous les certificats identifiés comme non autorisés. En parallèle, l’entreprise a collaboré avec les CAs concernées pour révoquer les certificats contrefaits. Google recommande aux propriétaires de domaines de surveiller les journaux de transparence des certificats (Certificate Transparency) afin de détecter toute émission inattendue, et d’ajouter des enregistrements CAA restrictifs pour limiter les autorités pouvant délivrer des certificats pour leurs noms. Le texte indique que les utilisateurs de Chrome n’ont aucune action à entreprendre, mais souligne que les protections côté navigateur ne couvrent pas les navigateurs alternatifs.
Analyse des limites et perspectives
Cette attaque montre que la confiance exclusive dans les vérifications DNS constitue un point faible exploitable lorsqu’un registre ccTLD est compromis. Même avec le blocage de Chrome, les certificats non découverts restent actifs pour les navigateurs qui ne consultent pas les listes de blocage. La lenteur du processus de révocation expose les utilisateurs à un risque prolongé. À moyen terme, renforcer les exigences de validation – par exemple en combinant DNS avec des preuves basées sur l’hébergement HTTP ou le DNSSEC – pourrait réduire la surface d’attaque. De plus, l’adoption généralisée de CAA et la surveillance automatisée des logs CT sont essentielles pour détecter rapidement les abus similaires.
