Comment signaler une vulnérabilité de sécurité concernant une autorité de certification approuvée?
Je suis tombé sur une énorme vulnérabilité de sécurité dans une autorité de certification qui est approuvée par tous les navigateurs et ordinateurs modernes.
Plus précisément, je peux obtenir un certificat signé valide pour un domaine que je ne possède pas. Si j'avais les moyens de devenir un homme au milieu, je serais en mesure de présenter un certificat SSL parfaitement valide.
Cette vulnérabilité n'a nécessité aucune injection SQL ni aucun codage de ma part. Je suis tombé assez figuré dessus.
Quelle est la bonne façon de signaler cela? Je veux être éthique et le signaler à l'autorité de certification fautive, mais je ne veux pas non plus qu'ils corrigent simplement la vulnérabilité, puis balaient tout sous le tapis. Ce problème semble être là depuis un certain temps, et je ne suis tout simplement pas assez intelligent pour être le seul à pouvoir le trouver.
Je crains que le seul contact avec l'AC entraînera une panique de leur part et, craignant un incident de type DigiNotar, fera tout pour empêcher le public de le découvrir.
Suis-je autorisé à contacter également certains acteurs majeurs, tels que d'autres autorités de certification ou d'autres sites tels que CloudFlare ou Google? (Je sais que CloudFlare a été prévenu de HeartBleed avant l'annonce publique.)
Remarque: je publie sous un compte pseudo pour (essayer de) rester anonyme pour l'instant.
Edit: Cette question est liée à ne autre question , mais je pense que cette vulnérabilité sort du cadre de cette question. Cela pourrait affecter essentiellement l'ensemble de l'internet (c'est-à-dire que tout le monde en ligne est un client), et ma question indique explicitement que le simple contact avec le `` développeur '' (la réponse acceptée pour la question liée) ne semble pas être la meilleure première étape pour moi.
Edit 2: J'ai pris contact avec certaines personnes, et elles m'ont conseillé d'éviter de parler davantage sur ce forum (désolé les gars!). Je mettrai à jour cette question plus tard, une fois la vulnérabilité entièrement corrigée et tous les certificats incorrects révoqués.
Edit 3: Les détails sont sortis. J'ai publié plus d'informations sur mon site personnel sur les spécificités de la vulnérabilité. L'histoire est toujours en cours, et vous pouvez lire la discussion entre Mozilla, Google et CA WoSign.
Edit 4: Comme promis, je mets à jour avec un lien vers un article écrit par Ars Technica concernant cet incident et d'autres incidents impliquant WoSign. Il semblerait que WoSign et StartCom (qui appartiennent désormais à la même société) soient gravement menacés de révocation de racine.
Une telle affirmation est généralement assez grave.
Tendre la main au fournisseur en question est une question responsable, vous devriez certainement envisager d'aviser les équipes de sécurité du magasin racine concernées, car elles sont responsables de la conception, de l'évaluation et de l'application des contrôles de sécurité pour éviter cela, et devront probablement travailler directement avec l'AC pour vérifier les problèmes.
En termes de divulgation responsable, vous devez également le signaler immédiatement à chacun des principaux opérateurs de magasin racine: Google, Microsoft, Apple, Mozilla. Recherchez simplement "<vendor> signaler un bogue de sécurité ", et le premier résultat vous le dira. Ce ne sont que quelques-uns des fournisseurs concernés - par exemple pas seulement l'autorité de certification.
Si vous ne savez pas comment procéder, si vous souhaitez rester anonyme ou si vous avez besoin d'aide pour la coordination, l'équipe de sécurité de Chromium est heureuse d'enquêter, de contacter l'autorité de certification appropriée et de se coordonner avec l'ensemble de l'industrie. Voir https://www.chromium.org/Home/chromium-security/reporting-security-bugs pour plus de détails.
Il semble que votre problème soit que cette vulnérabilité soit plus importante que vous ne savez quoi en faire.
Les règles de divulgation responsable, comme décrit ici , disent que vous devez contacter le vendeur et négocier une période de temps - entre 1 semaine et 6 mois, selon la profondeur des changements requis - dans laquelle ils peut implémenter un correctif, révoquer et republier des certificats, publier des bulletins de sécurité, etc., avant de rendre publiques vos conclusions. L'intention est qu'à la fin de la période négociée, vous obteniez votre reconnaissance publique, mais votre public ne peut plus faire de mal - si le vendeur a fait son travail correctement.
Si trouver un moyen de les contacter/négocier une période de divulgation responsable, rendre vos résultats publics à la fin, etc., est trop important pour vous, ou vous ne savez pas par où commencer, alors je vous suggère de contacter et de vous associer à un chercheur en sécurité bien connu qui a déjà établi des canaux de publication. Trouvez un grand nom qui a déjà publié des vulnérabilités similaires et appelez-les! Il semble que vous n'aurez aucun problème à attirer leur attention.
Félicitations aussi! J'ai hâte de voir votre nom sur un papier dans 6 mois!
Toutes nos félicitations! Cela ressemble à une découverte majeure.
Tout d'abord, générez une preuve. Le certificat SSL github.com sonne comme un bon début. Assurez-vous de conserver toutes les traces réseau dont vous avez besoin pour montrer exactement ce qui s'est passé.
Vous devez déterminer si vous avez enfreint des lois ou des conditions générales en faisant cela. Si l'AC n'a pas de prime de bogue, vous l'avez presque certainement fait. Dans ce cas, il est important que vous restiez anonyme. Une préoccupation ici est que vous avez peut-être déjà révélé votre identité lors du test. Par exemple, vous avez probablement dû payer pour ce certificat; comment avez-vous effectué le paiement? Si vous avez déjà enfreint la loi de manière non anonyme, cela exclut à peu près toute tactique de bras fort contre l'AC.
Bien qu'il soit louable que vous souhaitiez contacter l'AC, gardez à l'esprit que vous avez la possibilité de vendre cette vulnérabilité. Cela pourrait valoir 100 000 $ d'une organisation comme vupen. À vous de voir ce que vous en pensez.
Si vous voulez divulguer, vous pouvez le faire vous-même, mais je suis d'accord avec la recommandation de Mike de contacter un chercheur établi. Je pense que vous pourriez viser un peu plus haut qu'un chercheur universitaire. Une célébrité comme Bruce Schnier ou Dan Kaminsky serait intéressée par cela. Vous devrez leur faire confiance avec les détails et utiliser leur poids pour que le problème soit pris au sérieux.
En ce qui concerne CloudFlare obtenir une vue précoce de HeartBleed, il s'agit d'une pratique standard pour les principales vulnérabilités - que les principaux fournisseurs reçoivent une alerte précoce. Mais cela intervient beaucoup plus tard dans le processus. Dans le cas de HeartBleed, après que des correctifs ont été développés (mais pas rendus publics). Je ne sais pas comment cela s'appliquerait à cette vulnérabilité. Il semble que chaque certificat délivré par l'AC soit désormais suspect.
Quoi que vous choisissiez de faire, bonne chance!
En cas de doute, vous pouvez également contacter le CERT: https://forms.cert.org/VulReport/
Ils ont de l'expérience dans le traitement de vulnérabilités de sécurité, même très graves, et sont généralement considérés comme une partie de confiance. Au moins, ils peuvent confirmer que votre évaluation de la vulnérabilité est correcte et documenter votre rôle dans sa recherche.
Bien que le CERT vous conseille généralement de contacter le vendeur vous-même, pour un gros cas comme celui-ci, je suis sûr qu'il offrirait de l'aide.
Ryan Sleevi a de très bons conseils à ce sujet.
Avant de déclencher trop d'alarmes, je contacterais l'équipe de sécurité Chromium comme il l'a conseillé, juste pour m'assurer que vous ne comprenez rien.
Avez-vous vérifié votre vulnérabilité par rapport aux exigences de base du CAB Forum pour voir si l'exécution de votre vulnérabilité enfreint ces règles: https://cabforum.org/baseline-requirements-documents/ ?
Par exemple, je connais une pratique d'émission qui semble correspondre à votre résumé, mais l'AFAIK est totalement valide et n'est pas une vulnérabilité aux yeux du CAB Forum. Un certificat peut être généré pour un sous-domaine sans avoir de contrôle sur la racine. C'est à dire. vous pouvez obtenir un certificat pour test.google.com sans avoir à démontrer le contrôle de google.com.
Je vous recommande d'obtenir de la documentation et une démonstration de la vulnérabilité telle que vous en êtes consciente. Idéalement, si vous pouvez le faire vérifier entièrement par un tiers, qui a été informé de la situation.
Pour éviter des problèmes d'intégrité ou de répudiation par le fournisseur des conseils sur la vulnérabilité contre vous, une preuve supplémentaire par démonstration/exécution est nécessaire. Puisque nous prenons un certificat lié, la capture d'une chaîne de certificats démontrant un défaut serait idéale. Bien sûr, toute capture de session qui montre le vuln en action est utile.
Sans divulgation complète, je devine simplement de quelle preuve vous avez besoin de toute façon. Prenez la preuve de la documentation d'exploitation et semez-la dans des emplacements visibles publiquement comme GitHub, Pastebin, des listes de diffusion. Cela bloque l'incapacité de répudier si vos preuves sont solides.
Le problème restant est l'identité et la communication avec le vendeur et le public. Je ne prendrai pas la peine de révéler la révélation de votre identité personnelle, c'est à vous de décider. Les communications, si vous voulez être pratique et prêt à bousiller ou à ne pas agir avec l'expérience dans le cas où le tout explose ou va de travers, vous pouvez faire le contact.
Vous pouvez également demander à être représenté par la communauté, l'EFF ou tout au moins votre avocat. Quelqu'un pour protéger vos intérêts est conseillé et réfléchissez bien avant d'accepter l'aide de l'industrie d'une entreprise dans sa capacité commerciale. Je suis sûr que la communauté ici peut recommander des choix de représentation si vous sollicitez de tels conseils.
Un livre entier pourrait être écrit sur cet ensemble de sujets, j'ai essayé de le garder court et hors de TLDR; territoire.
De plus, je vous remercie pour le temps que vous avez passé à découvrir cette vulnérabilité potentielle. C'est vraiment nécessaire.
Les fournisseurs de systèmes d'exploitation et de navigateurs peuvent être un bon endroit pour signaler une telle vulnérabilité car ils gèrent les listes d'autorités de certification racine. Voici quelques liens pertinents:
- www.google.com/about/appsecurity/
- www.mozilla.org/en-US/about/governance/policies/security-group/bugs/
- www.Apple.com/support/security/
- technet.Microsoft.com/en-us/security/ff852094.aspx