Domaine détourné : vérifier les certificats après le DNS

Le rétablissement après un détournement de domaine se poursuit une fois le DNS restauré. Recherchez les certificats inattendus dans Certificate Transparency, demandez à l’autorité de certification émettrice de révoquer ceux qui n’étaient pas autorisés, rétablissez une politique d’émission restrictive et confiez la surveillance à un responsable. Un site qui fonctionne et un blocage d’urgence dans un navigateur ne répondent chacun qu’à une partie des questions.

Le 6 octobre, Google a signalé une manipulation du DNS faisant autorité dans les espaces de noms .gh, .sl et .as, suivie de l’émission non autorisée de certificats pour Google et d’autres organisations. Google affirme que ses propres systèmes n’ont pas été compromis et ne donne aucune raison de mettre en cause les autorités de certification émettrices. Chrome a bloqué des certificats au moyen des CRLSets, tandis que Google coordonnait leur révocation avec les émetteurs. Il s’agit du récit de Google, pas d’une reconstitution publique complète des conséquences du cas. Compte rendu de Google.

Que reste-t-il à vérifier après la restauration du DNS ?

Rétablir la maîtrise du DNS n’invalide pas un certificat existant. Certification Authority Authorization, ou CAA, détermine quelles autorités peuvent émettre des certificats. CAA ne détermine pas comment un client valide un certificat déjà émis. Modifier cette politique ne peut pas annuler rétroactivement une émission. RFC 8659.

Votre site peut pointer vers le bon serveur et présenter son certificat habituel alors qu’un certificat émis pendant la prise de contrôle non autorisée reste non révoqué. Vérifiez séparément la maîtrise du domaine et le statut des certificats.

Commencez votre dossier de rétablissement par ces questions :

La même distinction s’applique aux signalements d’identifiants divulgués : empêcher de futurs accès et comprendre les activités passées sont deux décisions distinctes.

Reprenez la maîtrise du domaine et délimitez la période à examiner

Travaillez avec les bureaux d’enregistrement, les registres et les prestataires DNS concernés pour reprendre la maîtrise du domaine. Conservez les traces de modification disponibles et déterminez la période à examiner avant que les opérations courantes de nettoyage ne compliquent la reconstitution des événements.

Notez la couche que vous pensez touchée et le prestataire qui a confirmé le rétablissement. Un compte compromis chez un bureau d’enregistrement, des entrées faisant autorité modifiées et un incident au niveau du registre peuvent concerner des organisations différentes. Le compte rendu de Google porte sur la manipulation du DNS faisant autorité dans trois espaces de noms. Récit de Google.

Pour chaque domaine touché, consignez la délégation attendue, le prestataire DNS et les services qui en dépendent. Incluez les domaines régionaux, les noms utilisés pour des redirections et les domaines parqués. Un domaine sans site actif peut tout de même relever de votre enquête sur les certificats. Google recommande expressément de surveiller tous les domaines détenus, y compris les domaines parqués et régionaux, et prévient que son enquête pourrait en manquer certains. Conseils de Google aux propriétaires.

Justifiez la période examinée. Si vous connaissez la première modification non autorisée confirmée et l’heure de rétablissement confirmée par un prestataire, conservez ces deux repères. Si les traces sont incomplètes, précisez quelle borne reste incertaine. Une période choisie autour de la première alerte constitue un point de départ, pas la preuve qu’aucune activité antérieure n’a eu lieu.

Recherchez les certificats inattendus dans Certificate Transparency

Certificate Transparency, ou CT, rend les certificats et précertificats visibles dans des journaux publics auxquels seules de nouvelles entrées peuvent être ajoutées. Des services de surveillance examinent ces journaux et peuvent notifier leurs abonnés des entrées trouvées. CT fournit des preuves d’émission à examiner. Une entrée de journal ne prouve ni interception ni vol de données. Fonctionnement de CT.

Recherchez le domaine concerné dans crt.sh, un outil de recherche CT lié depuis les instructions de révocation de Let’s Encrypt. Ouvrez les résultats pertinents et comparez les noms couverts, l’émetteur, les dates de validité et les horodatages du journal à la période examinée. Considérez ensemble les informations du certificat et de sa journalisation, sans traiter le début de validité comme l’heure exacte d’émission.

Comparez ces résultats aux traces de déploiement et de renouvellement. Demandez au responsable du service si chaque certificat correspond à un renouvellement ordinaire, à un CDN ou à un autre déploiement autorisé. Téléchargez les certificats inexpliqués lorsque c’est possible pour que l’émetteur puisse examiner le même document.

Pour chaque résultat inexpliqué, conservez un relevé succinct des preuves :

• Les noms de domaine couverts par le certificat, y compris les noms alternatifs du sujet.
• L’émetteur, le numéro de série et l’empreinte du certificat.
• Les dates de validité et la référence du journal concerné.
• La nature de l’entrée observée : certificat ou précertificat.
• Les traces de déploiement ou de renouvellement utilisées pour la comparaison.
• La personne qui l’a examinée et sa conclusion.

Distinguez les précertificats des certificats. Un précertificat participe au processus de journalisation CT et ne constitue pas lui-même un certificat de serveur utilisable. Un résultat identifié comme précertificat doit conserver cette qualification dans votre demande d’escalade et votre signalement. N’en déduisez pas que vous avez observé un serveur présenter ce certificat. Explication des précertificats par CT.

La surveillance CT présente des limites de délai et de couverture. Le processus de journalisation prévoit un délai maximal d’intégration, et votre service de surveillance ne voit que les journaux qu’il examine. Ne promettez pas de détection instantanée et ne considérez pas l’absence d’alertes comme une enquête complète. Le projet CT publie un répertoire des services de surveillance, mais y figurer ne garantit ni l’exhaustivité ni l’adéquation à vos besoins.

Demandez la révocation à l’autorité de certification émettrice

Signalez l’émission non autorisée à l’autorité qui a émis le certificat et suivez sa procédure de révocation documentée. La restauration du DNS, un certificat de remplacement et un blocage d’urgence dans un navigateur sont des événements distincts. Aucun ne doit tenir lieu de réponse de l’émetteur.

Envoyez les identifiants et les preuves recueillis, expliquez pourquoi l’émission n’était pas autorisée et conservez la demande ainsi que les réponses ultérieures. Si plusieurs noms figurent dans un même certificat, signalez-le dès le départ. L’aide de l’émetteur peut être nécessaire : ne supposez pas que la maîtrise d’un seul domaine suffit pour la procédure envisagée.

Let’s Encrypt documente un exemple utile : après avoir repris la maîtrise du domaine, un propriétaire peut demander la révocation depuis un autre compte autorisé en prouvant qu’il maîtrise tous les identifiants du certificat. Détenir la clé privée de l’attaquant n’est donc pas la seule façon de prouver son autorisation. Il s’agit de la procédure de Let’s Encrypt ; consultez les instructions de l’émetteur réel pour votre cas. Documentation de Let’s Encrypt sur la révocation.

Suivez chaque demande jusqu’à obtenir un résultat documenté. « E-mail envoyé à la CA » décrit une action encore en attente. Une réponse de l’émetteur et des preuves du statut du certificat permettent une conclusion mieux étayée. Notez le certificat concerné par le résultat pour éviter qu’une réponse sur un numéro de série ne clôture par erreur plusieurs entrées inexpliquées.

Que démontre un blocage dans Chrome ?

Les CRLSets de Chrome permettent le blocage d’urgence de certificats et contiennent une partie des révocations recueillies dans les listes des autorités de certification. Ils ne reproduisent pas toutes les révocations de certificats. Google a traité le blocage dans Chrome et la coordination avec les CA comme deux mesures distinctes. Documentation de Chromium sur les CRLSets, réponse de Google au cas signalé.

Google prévient que ses interventions ne protègent pas de manière fiable les utilisateurs d’autres navigateurs. Si vous vérifiez le comportement de navigateurs ou de clients API, consignez les clients, versions ou environnements examinés, l’heure et le résultat observé. Distinguez ce périmètre de vérification de la réponse de l’émetteur concernant la révocation.

Rétablissez CAA sans empêcher les renouvellements légitimes

CAA est une règle d’émission à revoir après la restauration du DNS. Elle ne peut pas empêcher une émission non autorisée tant qu’un attaquant maîtrise la politique DNS elle-même, ni révoquer un certificat existant. Google recommande de rétablir des règles CAA restrictives, avec des liaisons aux comptes et aux méthodes de validation prises en charge, pour limiter les émissions ultérieures utilisant des données de validation en cache. Conseils de Google.

Ces données en cache comptent, car la fin de la prise de contrôle non autorisée du DNS ne met pas nécessairement fin à toutes les possibilités d’émission créées pendant cette période. Traitez cette vérification comme une tâche de configuration propre au prestataire. Ne supposez pas qu’une entrée CAA générique comble cette lacune sans vérifier comment votre émetteur prend en charge les restrictions pertinentes.

La RFC 8657 définit deux paramètres : accounturi lie l’autorisation à l’URI d’un compte, et validationmethods limite les méthodes de validation autorisées par cette entrée. Leur effet dépend de leur prise en charge explicite par l’autorité de certification nommée. Une hypothèse non vérifiée sur l’un de ces paramètres peut laisser votre restriction sans effet. RFC 8657.

Avant de modifier les entrées de production, identifiez vos émetteurs légitimes et les comptes utilisés pour les émissions en production. Confirmez l’URI exacte du compte auprès de l’émetteur ou dans le système de gestion des certificats. L’adresse e-mail utilisée par une personne pour se connecter ne remplace pas cet identifiant de compte. Incluez le processus de renouvellement ainsi que la dernière émission manuelle, car ils peuvent dépendre de systèmes différents.

Examinez la politique dans son ensemble :

1. Confirmez que chaque émetteur nommé prend en charge les liaisons envisagées.
2. Vérifiez l’URI du compte de production et les méthodes de validation autorisées.
3. Examinez séparément l’autorisation des certificats génériques, le cas échéant.
4. Examinez les alias, les noms délégués et la politique des sous-domaines.
5. Vérifiez chaque entrée d’autorisation pour repérer une possibilité alternative non souhaitée.
6. Vérifiez que les émissions et renouvellements légitimes fonctionnent toujours avec les restrictions prévues.

Let’s Encrypt documente la prise en charge des restrictions aux méthodes http-01, dns-01 et tls-alpn-01, ainsi que des liaisons aux comptes ACME. L’autorité vérifie CAA avant chaque émission et explique que les autorisations de plusieurs entrées s’additionnent. Sa documentation décrit aussi les dérogations des sous-domaines et la résolution des CNAME. Utilisez ces précisions si Let’s Encrypt est votre émetteur, sans supposer que toutes les autorités se comportent de la même manière. Documentation CAA de Let’s Encrypt.

Cette addition des autorisations mérite une vérification attentive. Une entrée très restrictive peut coexister avec une autre autorisation qui permet l’émission que vous vouliez interdire. Lire uniquement la nouvelle entrée ne suffit pas. Examinez la politique effective des noms couverts par votre certificat, y compris les délégations ou alias pertinents.

Conservez le test de fonctionnement avec la modification de configuration. Notez ce qui a été émis avec succès, par quel compte et quelle méthode, ainsi que le processus de renouvellement vérifié. Vérifiez le processus de renouvellement avant de valider la modification, pour que la politique ne bloque pas votre prochain certificat légitime.

Confiez la surveillance des certificats pour l’ensemble de vos domaines

Maintenez la surveillance après le rétablissement immédiat, avec un responsable capable de rapprocher les alertes des émissions connues et de joindre l’autorité émettrice. Google recommande de couvrir tous les domaines détenus, car une réponse centralisée peut manquer des noms touchés. Recommandation de Google sur la surveillance.

Définissez le périmètre de surveillance à partir de votre inventaire de domaines plutôt que de vos seuls sites actifs. Incluez les marques régionales, les redirections, les domaines parqués et les noms délégués à d’autres équipes. Pour chaque domaine, conservez le nom de l’exploitant attendu et le processus d’émission légitime. Une nouvelle alerte pourra ainsi être traitée même si la personne intervenue initialement est indisponible.

Décidez où arrivent les alertes et ce qui se passe si personne ne répond. Pour une petite équipe, un responsable principal clairement nommé et un remplaçant peuvent être plus utiles qu’une boîte partagée que personne ne lit. Votre procédure doit permettre de conserver l’entrée, de contacter le responsable du service et de signaler une émission inexpliquée à l’autorité compétente sans devoir improviser pendant l’incident.

La surveillance n’autorise pas les tests actifs contre toute destination associée à un domaine. Si l’enquête vous conduit à tester un service, vérifiez qui l’exploite et de quelle autorisation vous disposez. Notre guide du périmètre des analyses de sécurité explique pourquoi une relation DNS ne constitue pas à elle seule une permission.

Conservez les preuves du rétablissement avec le rapport

Clôturez le rapport sur la base de résultats explicites : maîtrise rétablie, preuves relatives aux certificats examinées, réponses des émetteurs documentées, politique d’émission vérifiée et travail restant attribué. Précisez les limites à côté des résultats pour qu’une autre personne puisse évaluer la décision sans refaire l’enquête.

Une note de clôture utile pourrait indiquer : « Le prestataire a confirmé le rétablissement de la maîtrise de ces domaines. Nous avons comparé ces résultats CT aux traces de déploiement et signalé deux entrées inexpliquées à leurs émetteurs. Les liens vers leurs réponses figurent ici. Nous avons vérifié la politique CAA indiquée et le processus de renouvellement. Nos tests clients ont couvert ces environnements ; l’examen distinct des activités reste confié à ce responsable. »

Remplacez chaque élément générique par vos preuves réelles, y compris les réponses d’émetteurs en attente et les lacunes dans la période examinée.

Dans Kit, un rapport de sécurité peut réunir un responsable nommé, des pièces jointes justificatives, des notes internes et des tickets liés auprès des prestataires ou pour la remédiation. Sa chronologie rassemble les changements de statut, les attributions et la correspondance. Vous pouvez consigner la cause initiale, les mesures correctives et les enseignements restants dans une analyse après incident. Gardez les travaux techniques de rétablissement et leurs résultats liés à ce dossier.

Votre équipe dispose ainsi d’un endroit pour examiner la transmission du dossier et la décision de clôture. Consultez le processus de gestion des rapports de sécurité de Kit, puis comparez-le à votre procédure actuelle : la prochaine personne chargée du dossier peut-elle identifier le responsable, trouver les preuves relatives aux certificats et voir quelles conclusions sur le rétablissement restent à vérifier ?