La semaine dernière, DigiCert a révélé un problème de conformité affectant 83 267 certificats en raison d'un bogue de vérification de contrôle de domaine (DCV), ce qui a entraîné des exigences de révocation. Ce problème a des conséquences importantes pour les organisations, qui doivent rapidement réémettre ces certificats sous peine d'interruptions de service et de perte de confiance des utilisateurs.
À l'heure où nous écrivons ces lignes, Censys a constaté que 26 373 certificats concernés étaient encore utilisés sur des hôtes publics, dont près de 99 % ont été révoqués. Cet incident nous rappelle une fois de plus qu'il est toujours difficile de trouver un équilibre entre la conformité et le temps de réponse pour les organisations, et suit de près le récent retrait d'Entrust.
Dans ce blog, nous examinons les détails de l'incident, ainsi que le point de vue de Censyssur sa portée, et nous identifions les principales entreprises et industries touchées.
Résumé
- Le 28 juillet 2024, DigiCert a signalé un problème de conformité dû à un bogue dans son processus de vérification du contrôle des domaines (DCV). processus de vérification du contrôle de domaine (DCV). Le Certification Authority Browser Forum (CA/B) demande à DigiCert de révoquer les certificats concernés dans un délai de 24 heures afin de maintenir sa conformité en tant qu'autorité de certification de confiance.
- L'incident a provoqué d'importantes perturbations, les organisations s'efforçant de remplacer les certificats dans les délais impartis. En particulier, Alegeus, une société de technologie financière dans le secteur de la santé, a demandé une ordonnance du tribunal pour retarder le processus de révocation, invoquant de graves répercussions opérationnelles et une perturbation potentielle de l'accès des clients.
- DigiCert est actuellement le quatrième Autorité de Certification (AC) la plus active dans notre base de données, et a rapporté que 83 267 certificats uniques ont été affectés par ce problème. En utilisant les données de Censys , nous avons déterminé que 33,201 d'entre eux étaient utilisés sur le web public au 30 juillet. En l'espace d'une semaine, le nombre de certificats affectés en cours d'utilisation a diminué de près de 7,000et s'établit désormais à 26,373 au 6 août.
- Notre analyse des domaines enregistrés montre que la Technologie et des télécommunications ont été les plus touchés en termes de nombre de certificats affectés.
- Au 6 août 2024, 98.82% des certificats de feuilles uniques affectés par cet incident et que nous observons en cours d'utilisation sur des hôtes en contact avec le public ont été révoqués. DigiCert a déclaré que tous les clients concernés sont sont tenus de réémettre les certificats concernés d'ici ce vendredi 9 août à 20:30 UTC.
- Cet incident survient peu de temps après qu'Entrust ait été retiré de la liste des autorités de certification de confiance. Entrust ait été retirée de la liste des autorités de certification de confiance le mois dernier. le mois dernier, ce qui met en évidence les obstacles permanents auxquels les organisations sont confrontées en matière de gestion efficace des certificats. Trouver un équilibre entre les exigences de conformité des autorités de certification et le fait de donner aux utilisateurs suffisamment de temps et de ressources pour répondre de manière adéquate à de tels incidents reste un défi difficile à relever.
- Détection avec Censys:
- Censys Les clients d'ASM peuvent identifier les services qui utilisent activement un certificat affecté dans leur espace de travail en recherchant un nouveau risque de faible gravité nommé "Certificat affecté par l'incident de révocation de DigiCert de juillet 2024"
- Les utilisateurs de notre fonction de recherche peuvent trouver les hôtes dont les certificats sont concernés en interrogeant les éléments suivants labels=digicert-revoked-dcv. Pour affiner les résultats pour vos domaines spécifiques, ajustez cette requête pour filtrer sur services.tls.certificates.leaf_data.names. Veuillez noter que cette détection d'étiquette vient d'être déployée, et qu'elle peut donc prendre jusqu'à 48 heures à partir de maintenant pour se propager complètement.
La question
Le 28 juillet 2024, DigiCert a émis un rapport d'incident initial révélant qu'un sous-ensemble de ses certificats n'était pas conforme en raison d'un bogue dans son processus de vérification du contrôle des domaines (DCV). En conséquence, DigiCert disposait de 24 heures pour révoquer et réémettre tous les certificats concernés afin de rester en conformité avec les autorités de certification racine telles que Google et Mozilla.
DigiCert exploite deux systèmes principaux pour l'émission de certificats : un système à haut volume pour traiter les demandes des CDN et des fournisseurs de cloud et un système à faible volume pour les utilisateurs nécessitant une gestion de configuration plus élevée. Ce problème n'a affecté que les certificats émis par le système à faible volume, tandis que le système à fort volume n'a pas été affecté. Étant donné que le système à faible volume s'adresse aux clients qui ont besoin de configurations précises, ces certificats sont probablement utilisés dans des environnements hautement sécurisés.
La cause première du problème provient du processus de DigiCert pour vérifier la propriété du nom de domaine, connu sous le nom de Domain Control Validation (DCV). La DCV peut être effectuée par différentes méthodes telles que le courrier électronique, le HTTP ou le whois, mais le bogue en l'occurrence était lié à la DCV basée sur le DNS.
Dans le cas d'un DCV basé sur le DNS, les clients doivent créer un enregistrement DNS spécifique (et temporaire) dont la valeur correspond au contenu demandé par l'autorité de certification (DigiCert). Par exemple, la documentation de DigiCert sur le DCV est disponible sur le site de DigiCert, la documentation DCV de DigiCert de DigiCert décrit deux méthodes pour ce processus :
- Option 1
- Allez sur le site de votre fournisseur de DNS et créez un nouvel enregistrement CNAME.
- Dans le champ du nom d'hôte (ou équivalent), entrez _dnsauth.
- Dans le champ du type d'enregistrement (ou équivalent), sélectionnez CNAME.
- Dans le champ hôte cible (ou équivalent), entrez [valeur_aléatoire].dcv.digicert.com pour faire pointer l'enregistrement CNAME vers dcv.digicert.com.
- Option 2
- Allez sur le site de votre fournisseur DNS et créez un nouvel enregistrement CNAME.
- Dans le champ hostname (ou équivalent), entrez la valeur aléatoire que vous avez copiée à partir de votre compte CertCentral.
- Dans le champ du type d'enregistrement (ou équivalent), sélectionnez CNAME.
- Dans le champ hôte cible (ou équivalent), entrez dcv.digicert.com pour faire pointer l'enregistrement CNAME vers dcv.digicert.com.
Disons que notre défi aléatoire DigiCert est le suivant _FOOBAR. Pour l'"Option 1", l'enregistrement DNS résultant apparaîtrait comme suit :
_dnsauth IN CNAME _FOOBAR.dcv.digicert.com. ; _dnsauth.example.com.
L'"option 2" serait légèrement différente :
_FOOBAR IN CNAME dcv.digicert.com. ; FOOBAR.example.com.
DigiCert peut alors effectuer une requête DNS pour le nom de domaine donné, vérifier la valeur correcte dans la réponse et confirmer ainsi que l'utilisateur qui demande le certificat est propriétaire de ce nom de domaine.
Ce processus fonctionne bien, mais il est important de noter le trait de soulignement qui précède la valeur aléatoire (défi) qui nous a été donnée. La raison en est décrite dans une recommandation d'un projet de l'IETF décrivant les meilleures pratiques en matière de DCV utilisant le DNS :
“The RECOMMENDED format is application-specific underscore prefix labels. Domain Control Validation records are constructed by the provider by prepending the label “_<PROVIDER_RELEVANT_NAME>-challenge” to the domain name being validated (e.g. “_foo-challenge.example.com”). The prefixed “_” is used to avoid collisions with existing hostnames.” – draft-ietf-dnsop-domain-verification-techniques-02 Section 5.1.1
Cela signifie essentiellement que l'utilisation d'un trait de soulignement avant le nom permet d'éviter les conflits lorsque la chaîne aléatoire générée pour le VCD pourrait correspondre par inadvertance à un enregistrement DNS existant. Bien que les traits de soulignement soient techniquement contraires aux normes RFC du DNS, la plupart des résolveurs DNS les acceptent. Les traits de soulignement ne sont généralement pas utilisés pour la résolution générale, mais sont plutôt réservés aux systèmes d'automatisation.
DigiCert a également décrit cette fonctionnalité dans un billet de blog du 29 juillet 2024de la même manière. Bien que le trait de soulignement ne soit qu'une recommandation dans le projet de l'IETF, il s'agit d'une exigence pour les autorités de certification, il s'agit d'une exigence pour les autorités de certification. Cependant, le faible volume d'émission de certificats de DigiCert n'est pas suffisant, le système d'émission de certificats de DigiCert, dont le volume est faible, n'a pas appliqué cette exigence.
L'idée que cette fonction n'est en place que pour éviter les enregistrements DNS déjà existants peut sous-estimer d'autres risques de sécurité, potentiellement plus importants, lorsque le trait de soulignement n'est pas utilisé. Un utilisateur de Bugzilla a souligné dans une réponse à DigiCert que cette vérification du trait de soulignement n'a pas pour seul but d'éviter les collisions potentielles de noms. Dans certaines circonstances, un utilisateur malveillant pourrait exploiter cette omission pour créer un certificat pour un domaine qu'il ne possède pas.
"La raison d'être du trait de soulignement est que les services qui permettent aux utilisateurs de créer des enregistrements DNS dans des sous-domaines (par exemple, les services DNS dynamiques) peuvent empêcher les utilisateurs d'enregistrer des sous-domaines commençant par un trait de soulignement et être à l'abri d'une émission de certificat non désirée." - Commentaire n°10
Cet utilisateur a signalé un scénario dans lequel un produit ou un service permet aux utilisateurs de contrôler un enregistrement DNS d'un nom de domaine parent qu'ils ne possèdent pas. Prenons l'exemple d'un produit qui permet aux utilisateurs d'enregistrer des comptes, chaque compte ou nom d'utilisateur étant associé à un enregistrement DNS contrôlable. Un exemple fourni concerne les services DNS dynamiques, où les utilisateurs peuvent automatiquement mettre à jour certains enregistrements publics sur la base de l'adresse DHCP qui leur a été attribuée, en utilisant le nom d'utilisateur comme sous-domaine. Par exemple, si un utilisateur obtient un bail DHCP de 192.168.1.2il peut mettre à jour nomd'utilisateur.certain-service-dyndns.com pour qu'il pointe vers cette adresse IP.
Si c'était le cas, vous pourriez techniquement enregistrer un nouveau compte sur ce service avec le nom d'utilisateur correspondant à la chaîne de caractères aléatoire fournie par DigiCert. Ensuite, vous pourriez mettre à jour l'enregistrement DNS Nomd'utilisateur.certain-service-dyndns.com avec une valeur CNAME de dcv.digicert.com. Cela vous permettrait de passer le contrôle DCV de DigiCert, ce qui conduirait à l'émission d'un certificat valide.
Une personne a souligné que noip[.]com pourrait être un bon exemple de cible de ce problème, qui pourrait potentiellement permettre à un attaquant d'obtenir un certificat valide pour ddns[.]net.
“No-IP (https://www[.]noip.com) allows the creation of arbitrary labels under their domains like ddns[.]net, enabling users to easily create subdomains such as <some_arbitrary_string>.ddns.net and map them as CNAMEs to any target.” – Comment #15
Et cela semble bien être le cas ; dans les deux captures d'écran suivantes, nous montrons que nous pouvons créer un sous-domaine arbitraire de notre choix avec la valeur CNAME de dcv.digicert.com sans erreur si nous excluons le trait de soulignement qui précède, mais que nous échouons si nous incluons un trait de soulignement.
 |
 |
| Sans le trait de soulignement qui précède. |
Avec le trait de soulignement qui précède. |
 |
Techniquement, un pirate aurait pu créer des certificats valides pour n'importe lequel des noms de domaine préconfigurés énumérés à gauche (ddns[.]net, gotdns[.]ch) |
Un service qui met en œuvre une telle fonctionnalité devrait refuser automatiquement tout nouveau compte ou enregistrement dont le préfixe contient un trait de soulignement, les traitant ainsi comme des mots-clés réservés (comme noip le fait ci-dessus). Cependant, étant donné que DigiCert n'appliquait pas le préfixe de soulignement, tout accès de modification DNS sur ces systèmes pouvait être exploité pour obtenir un certificat valide pour le nom de domaine parent.
En bref, le trait de soulignement est essentiel non seulement pour éviter les collisions de noms, mais aussi pour fournir une couche de sécurité supplémentaire aux services qui permettent aux utilisateurs de modifier des domaines protégés. Il permet de mettre en place des mécanismes de filtrage pour empêcher les utilisateurs (non) autorisés d'exploiter les enregistrements DNS pour obtenir des certificats valides.
Implications dans le monde réel.
Cet incident a suscité un vif émoi parmi les particuliers et les entreprises, provoquant le chaos dans les équipes d'ingénieurs du monde entier, qui se sont toutes empressées de mettre à jour leurs hôtes avec de nouveaux certificats. À tel point qu'une entreprise de technologie financière spécialisée dans le secteur de la santé l'industrie de la santé, Alegeusa déposé une requête en justice afin d'obtenir une une ordonnance restrictive temporaire à l'encontre de DigiCert pour tenter de retarder la révocation.
"La recertification des sites web d'Alegeus exige qu'Alegeus se coordonne avec chacun de ses clients et ne peut être réalisée pour tous les sites web d'Alegeus dans les délais prescrits par DigiCert. En conséquence, Alegeus a demandé trois jours pour terminer la recertification des sites web d'Alegeus. DigiCert a refusé. - Page 3.8
Il s'agit en fait d'affirmer que le délai court n'était pas suffisant pour Alegeus et que l'un des meilleurs moyens de prolonger le délai était d'en faire une question juridique. Leur raisonnement semble légitime :
"Si DigiCert révoque les certificats de sécurité des sites web d'Alegeus, cela causera à Alegeus des dommages graves et irréparables dont le montant sera déterminé lors du procès. - Page 9
Et si nous lisons l'appel de la chaîne de courriels originale envoyée par Alegeus à DigiCert le 29 juillet 2024, nous pouvons consolider leur raison encore plus en lisant à quel point la situation est désastreuse :
"Le retrait des certificats tel qu'il est proposé entraînera d'importants problèmes d'accès pour nos clients et leurs participants, ce qui signifie que des millions de participants à des régimes et de consommateurs ne pourront pas accéder aux fonds réservés et conçus pour payer les prestations de soins de santé jusqu'à ce que les problèmes d'accès soient résolus. - Page 3
Cela signifie essentiellement que sans une extension appropriée de la date limite, des vies humaines réelles peuvent être affectées. Je pense qu'il convient de souligner ici que si les autorités de certification elles-mêmes n'ont aucun problème avec ces délais serrés, leurs clients n'ont pas toujours le même luxe - des incidents de ce type peuvent être assez troublants pour le consommateur. Il est évident que la meilleure façon de procéder est de ne pas avoir eu lieu, mais nous en sommes là.
Références
CensysLe point de vue de la Commission
Part de marché de DigiCert
Selon l'avis d'incident initial de DigiCert, cela a affecté "environ 0,4 % des validations de domaines applicables" - replaçons ce chiffre dans le contexte du monde réel.
DigiCert est une importante autorité de certification (AC). Elle se classe au quatrième rang des autorités de certification les plus actives dans notre base de données, ayant émis environ 54,1 millions de certificats, soit près de 7 % de l'ensemble des certificats de confiance actuellement émis.
Sur forum Bugzilla de Mozillaun représentant de DigiCert a joint des fichiers CSV contenant des liens vers 83 267 certificats de feuilles qui seraient affectés par ce problème de DCV.
Le 30 juillet, quelques jours après la révélation de l'incident, nous avons identifié plus de 455 999 adresses IPv4 distinctes (réparties sur des hôtes physiques et virtuels) utilisant 33 201 de ces 83 267 certificats affectés.
Une semaine plus tard, le 6 août, 26 373 certificats affectés restaient en ligne, soit une baisse de 6 828 certificats en une semaine.
Le tableau ci-dessous résume ces statistiques hebdomadaires de notre point de vue.
| Date |
Hôtes physiques IPv4 |
Hôtes physiques et virtuels |
Certificats de feuilles actives |
Domaines uniques |
| 7/30/2024 |
456002 |
4085959 |
33201 |
30528 |
| 8/6/2024 |
241343 |
3599368 |
26373 |
24693 |
Impact sur l'industrie et les entreprises :
Nous avons analysé les noms de domaine associés à ces certificats actifs observés le 30 juillet, en les classant en fonction du nombre d'hôtes uniques et en classant les entreprises et les secteurs d'activité correspondants pour les certificats comportant dix hôtes ou plus (soit un total de 2 262 noms de domaine uniques). Il convient de noter que seuls les domaines enregistrés ont été pris en considération, et non les sous-domaines (ex : www.censys.com et community.censys.com sont tous deux évalués comme "censys.com ").
| Entreprise |
Compte du domaine |
Nombre d'hôtes |
Certificats de feuilles uniques |
% du total des certificats de feuilles affectés |
| Vodafone |
19 |
6165 |
2178 |
16.10% |
| Bloomberg |
6 |
3685 |
630 |
4.66% |
| ABB |
5 |
601 |
250 |
1.85% |
| Yahoo |
6 |
6283 |
223 |
1.65% |
| Hitachi |
1 |
260 |
215 |
1.59% |
| Poste Italiane |
1 |
332 |
200 |
1.48% |
| Groupe Atlas World |
1 |
315 |
196 |
1.45% |
| Bouygues Telecom |
5 |
425 |
148 |
1.09% |
| Groupe Qt |
1 |
191 |
146 |
1.08% |
| Engie |
3 |
463 |
142 |
1.05% |
Vodafone se distingue avec plus de 2 100 certificats de feuilles uniques affectés, ce qui indique qu'elle fait probablement largement appel à DigiCert pour ses besoins en matière de certificats. Bloomberg, ABB, Yahoo et Hitachi sont les cinq premières entreprises touchées parmi celles que nous avons pu attribuer à un propriétaire.
| L'industrie |
Compte du domaine |
Nombre d'hôtes |
Certificats de feuilles uniques |
% du total des certificats de feuilles affectés |
| Technologie |
916 |
184276 |
3001 |
22.23% |
| Télécommunications |
65 |
81456 |
2652 |
19.64% |
| Services financiers |
192 |
21259 |
1017 |
7.53% |
| Les médias |
102 |
15308 |
1007 |
7.46% |
| Soins de santé et produits pharmaceutiques |
156 |
7679 |
708 |
5.24% |
| Gouvernement |
80 |
3987 |
687 |
5.09% |
| Utilitaires |
22 |
1694 |
568 |
4.21% |
| Assurance |
54 |
5817 |
565 |
4.18% |
| L'éducation |
133 |
12997 |
510 |
3.78% |
| Fabrication |
61 |
7218 |
495 |
3.67% |
| Vente au détail |
80 |
12495 |
421 |
3.12% |
| Transport et logistique |
50 |
1712 |
314 |
2.33% |
| Divertissement |
95 |
13127 |
286 |
2.12% |
| Biens de consommation |
51 |
4689 |
139 |
1.03% |
| Publicité et marketing |
35 |
1922 |
107 |
0.79% |
| Ingénierie et construction |
16 |
741 |
106 |
0.79% |
| Recrutement et emploi |
14 |
1202 |
99 |
0.73% |
| Aérospatiale |
3 |
178 |
96 |
0.71% |
| Juridique |
6 |
172 |
88 |
0.65% |
| Automobile |
30 |
783 |
82 |
0.61% |
Les données révèlent également que les secteurs de la technologie et des télécommunications sont les plus touchés par cet incident de révocation. Le secteur de la technologie compte le plus grand nombre de certificats de feuilles uniques (3 001), suivi de près par celui des télécommunications (2 652). Les certificats numériques sont couramment utilisés dans ces secteurs pour sécuriser les grands réseaux et les infrastructures de communication.
Les secteurs des services financiers, des médias, des soins de santé et des produits pharmaceutiques sont parmi les plus touchés. Nos recherches sur l'incident l'incident Entrust en juilletlorsque Entrust a été retiré de la liste des autorités de certification de confiance, les services financiers ont été identifiés comme le secteur le plus touché.
Combien de ces certificats sont révoqués ?
Selon la page d'incident mise à jour par page d'incident mise à jour par DigiCerttous les certificats concernés doivent être remplacés avant le 9 août 2024, à 20:30 UTC. À ce jour, 98,82 % des certificats de feuilles concernés ont été révoqués, ce qui représente une augmentation significative par rapport au 30 juillet 2024, date à laquelle seulement 5 % d'entre eux avaient été révoqués.
| Date |
Total des certificats de feuilles actifs |
# Révoqué |
Révoqué |
| 30 juillet |
33201 |
1652 |
4.98% |
| 6 août |
26373 |
26061 |
98.82% |
Que peut-on faire ?
- Les clients concernés devraient avoir reçu une notification de DigiCert et il leur est recommandé de prendre des mesures immédiates pour réémettre et installer de nouveaux certificats via leur compte DigiCert CertCentral.
- Censys Les clients ASM verront apparaître un nouveau risque de faible gravité nommé "Certificat affecté par l'incident de révocation de DigiCert de juillet 2024" lié à ce problème, qui peut être utilisé pour détecter les certificats affectés dans leurs espaces de travail.
- Les clients de la recherche peuvent utiliser la requête labels=digicert-revoked-dcv pour trouver les hôtes qui utilisent l'un des certificats concernés. Pour restreindre les résultats afin de filtrer vos domaines, modifiez cette requête et remplacez "votredomaine.com". Notez que nous venons juste de mettre en place cette détection d'étiquette, il se peut donc que cela prenne plus de 48 heures à partir du moment où nous écrivons ces lignes pour se propager.
Références :
