Une vulnérabilité a été identifiée dans le système de vérification de propriété de domaine de l'autorité de certification SSL.com, permettant d'obtenir un certificat TLS pour n'importe quel domaine ayant fourni un email à l'attaquant. Pour obtenir le certificat TLS, il suffisait d’avoir accès à l'email du domaine ciblé. Par exemple, cette vulnérabilité permettait d'obtenir un certificat TLS pour des domaines utilisés dans des services email publics tels que gmail.com, yandex.ru, yahoo.com, outlook.com et icloud.com.
La vulnérabilité offrait également la possibilité aux attaquants de mener des attaques ciblées contre des employés de sociétés renommées et des participants à de grands projets pour accéder à leurs emails et obtenir des certificats TLS pour des domaines connus. domaines. Par exemple, compromettre un employé de Google ayant l'email name@google.com permettait d'obtenir un certificat pour le domaine google.com.
La vulnérabilité était causée par une erreur dans la mise en œuvre du système de vérification de propriété de domaine par confirmation par email. Pour obtenir la confirmation par email, il est nécessaire d'ajouter dans la zone DNS du domaine pour lequel le certificat est demandé, un enregistrement DNS TXT « _validation-contactemail ». Par exemple, « _validation-contactemail.test.com DNS TXT name@example.com ». Après l'initiation de la vérification de domaine, un code de confirmation sera envoyé à l'email name@example.com, dont la saisie confirme la propriété du domaine « test.com » et permet d'obtenir un certificat TLS pour « test.com ».
Le cœur de la vulnérabilité réside dans le fait que, outre le domaine « test.com », pour lequel le certificat a été demandé, le marqueur de validation de propriété était également attribué pour le domaine « example.com », utilisé dans l'email. Le chercheur ayant découvert le problème a démontré l'obtention d'un certificat TLS fonctionnel pour le domaine aliyun.com, utilisé dans le service de webmail de la société chinoise Alibaba. Au cours d'une attaque de test, le chercheur a enregistré un domaine de vérification « d2b4eee07de5efcb8598f0586cbf2690.test.dcv-inspector.com » dans le service « dcv-inspector.com » et a demandé un certificat TLS pour celui-ci, en ajoutant l'enregistrement DNS : _validation-contactemail.d2b4eee07de5efcb8598f0586cbf2690.test.dcv-inspector.com DNS TXT myusername@aliyun.com
Après cela, il a demandé un certificat TLS sur le site SSL.com pour le domaine d2b4eee07de5efcb8598f0586cbf2690.test.dcv-inspector.com et a choisi la validation par email. L'autorité de certification SSL.com a envoyé un code de vérification à myusername@aliyun.com et après avoir entré ce code, elle a ajouté au registre des domaines vérifiés non seulement « d2b4eee07de5efcb8598f0586cbf2690.test.dcv-inspector.com », mais aussi « aliyun.com ». Après cela, le chercheur a réussi à obtenir un certificat TLS pour le domaine « aliyun.com », dont la propriété a été confirmée.
L'autorité de certification SSL.com a résolu le problème et a découvert 11 certificats pour lesquels une méthode de vérification vulnérable utilisant un domaine externe par email avait été utilisée. Il semble qu'il n'y ait pas de signes d'activité malveillante dans les cas identifiés et parmi les 11, un seul certificat, obtenu par le chercheur pour le site aliyun.com, a été révoqué pour le moment. Les autres certificats impliquaient les domaines medinet.ca, help.gurusoft.com.sg, banners.betvictor.com, production-boomi.3day.com, kisales.com et medc.kisales.com. SSL.com prévoit de publier un rapport sur l'incident d'ici le 2 mai.
Source : opennet.ru
