Question:
Comment signaler une vulnérabilité de sécurité concernant une autorité de certification de confiance?
MotorStoicLathe
2015-06-10 18:56:41 UTC
view on stackexchange narkive permalink

Je suis tombé sur une énorme faille 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 Man In The Middle, je pourrais présenter un certificat ssl parfaitement valide.

Cette vulnérabilité ne nécessitait aucune injection SQL ni codage de ma part. Je suis tombé dessus au sens figuré.

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'elle corrige simplement la vulnérabilité et ensuite balaie 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 capable de le trouver.

Je crains que le seul contact avec l'autorité de certification entraînera une panique sur leur part, et eux, craignant un incident de type DigiNotar, feront 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 comme CloudFlare ou Google? (Je sais que CloudFlare a été informé de HeartBleed avant que l'annonce publique ne soit diffusée.)

Remarque: je publie sous un compte pseudonyme pour (essayer de) rester anonyme pour le moment.

Modifier: Cette question est liée à une autre question, mais j'estime que cette vulnérabilité sort du cadre de cette question. Cela pourrait affecter essentiellement tout Internet (c'est-à-dire que tout le monde en ligne est un client), et ma question indique explicitement que le simple fait de contacter le `` développeur '' (la réponse acceptée pour la question liée) ne me semble pas être la meilleure première étape.

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 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.

Édition 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. On dirait que WoSign et StartCom (qui appartiennent désormais à la même société) peuvent être gravement menacés de révocation root.

Les commentaires ne sont pas destinés à une discussion approfondie; cette conversation a été [déplacée vers le chat] (http://chat.stackexchange.com/rooms/24859/discussion-on-question-by-motorstoiclathe-how-do-i-report-a-security-vulnerabili).
Salut, est-ce que quelque chose est arrivé? S'il y a une URL d'un avis ou quelque chose, ce serait intéressant!
C'était toi? http://oalmanna.blogspot.co.uk/2016/03/startssl-domain-validation.html
@paj28 Non, ce n'était pas moi.Mais j'ai finalement contacté Ars Technica pour voir s'ils veulent faire quelque chose avec mes informations.Je mettrai à jour cette question avec plus de détails plus tard avec plus de détails.Soit avec un lien vers l'histoire, soit (si personne ne se soucie d'écrire une histoire (nouvelles de> 1 an maintenant)) avec des détails sur la vulnérabilité maintenant corrigée.
À tous ceux qui se demandent ce qui s'est passé: https://www.schrauger.com/the-story-of-how-wosign-gave-me-an-ssl-certificate-for-github-com
Woah.On dirait que _deux_ autorités de certification vont maintenant se méfier de Firefox, en partie à cause de cela.https://docs.google.com/document/d/1C6BlmbeQfn4a9zydVi2UvjBGv6szuSB4sMYUcVrR8vQ/preview
Huit réponses:
#1
+69
Mike Ounsworth
2015-06-10 19:37:59 UTC
view on stackexchange narkive permalink

Il semble que votre problème soit que cette vulnérabilité est plus grande que vous ne savez quoi faire.

Les règles de divulgation responsable, telles que décrites ici, indiquent que vous devriez contactez le fournisseur et négociez un délai - entre 1 semaine et 6 mois, selon la profondeur des changements requis - dans lequel ils peuvent mettre en œuvre un correctif, révoquer et réémettre des certificats, publier des bulletins de sécurité, etc., avant de partir public avec vos résultats. L'intention est qu'à la fin de la période négociée, vous obteniez votre reconnaissance publique, mais votre entrée en bourse ne peut plus faire de mal - si le fournisseur a fait son travail correctement.

Si vous cherchez comment les contacter / négocier une période de divulgation responsable, rendre public vos résultats à la fin, etc., c'est trop gros pour vous, ou vous ne savez pas par où commencer, alors je suggère de contacter et de collaborer avec 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 également! J'ai hâte de voir votre nom sur un papier dans 6 mois!

à la suggestion d'@paj28's, j'ai généralisé aux chercheurs au-delà des universités
Si vous avez besoin d'aide pour élaborer un accord de divulgation ou simplement pour contacter le fournisseur, je vous suggère de travailler avec un tiers responsable comme l'Electronic Frontier Foundation ou le SANS Institute.
Il existe une autre école de divulgation: la divulgation complète. Je ne suis pas nécessairement d'accord avec eux, mais il est bon de savoir que les gens ne sont pas tous d'accord pour dire qu'une divulgation responsable est responsable.
#2
+44
Ryan Sleevi
2015-06-10 21:00:48 UTC
view on stackexchange narkive permalink

Une telle réclamation est généralement assez sérieuse.

Bien que contacter le fournisseur en question soit une question responsable, vous devriez certainement envisager d'en informer les équipes de sécurité du magasin racine concernées, car elles sont responsables de la conception, évaluer et appliquer les contrôles de sécurité pour éviter cela, et devra probablement travailler directement avec l'autorité de certification pour déterminer les problèmes.

En termes de divulgation responsable, vous devez également le signaler immédiatement à chacun des principaux responsables opérateurs de magasins: Google, Microsoft, Apple, Mozilla. Il suffit de rechercher " <vendor> rapport de bug de sécurité", et le premier résultat vous le dira. Ce ne sont là que quelques-uns des fournisseurs concernés - par exemple pas seulement l'autorité de certification.

Si vous n'êtes pas sûr de savoir 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 se fera un plaisir d'enquêter, de contacter l'autorité de certification appropriée et de coordonner avec le industrie plus large. Voir https://www.chromium.org/Home/chromium-security/reporting-security-bugs pour plus de détails.

J'ai changé ma réponse acceptée pour celle-ci.Après tout ce qui s'est passé, c'est le conseil que j'aurais dû suivre à l'origine.S'il s'agit d'autorités de certification, les opérateurs du magasin racine doivent être contactés avec l'autorité de certification en question.
#3
+25
paj28
2015-06-10 20:00:01 UTC
view on stackexchange narkive permalink

Félicitations! Cela ressemble à une découverte majeure.

D'abord, générez une preuve. Le certificat SSL github.com semble être 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 T&C en faisant cela. Si l'autorité de certification n'a pas de prime de bogue, vous l'avez 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 puissante contre l'AC.

Bien qu'il soit louable que vous souhaitiez contacter l'AC, soyez indulgents sachez que vous avez la possibilité de vendre cette vulnérabilité. Cela pourrait valoir 100 000 $ de la part d'une organisation comme vupen. C'est à vous de décider 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 pour obtenir une vue précoce de HeartBleed, il s'agit d'une pratique standard pour les vulnérabilités majeures - que les fournisseurs clés obtiennent un alerte précoce. Mais cela arrive beaucoup plus tard dans le processus. Dans le cas de HeartBleed, après le développement de correctifs (mais non publiés). Je ne sais pas comment cela s'appliquerait à cette vulnérabilité. Il semble que chaque certificat émis par l'autorité de certification soit maintenant suspect.

Quoi que vous choisissiez de faire, bonne chance!

lol - "on pense que beaucoup d'acheteurs sont des forces de l'ordre et des renseignements" amicaux ", ce que la plupart des gens trouvent un peu plus acceptable" - pas pour les gens qui vivent dans les 195 autres pays!
@MikeOunsworth - J'avais essayé de mettre suffisamment de mises en garde dans cette phrase, mais clairement pas. Modifié pour supprimer. Même si j'ai le sentiment que les gens qui ont voté pour votre commentaire oublieraient leurs principes s'ils avaient réellement un exploit assez bon à vendre.
@paj28 S'ils accordent de l'importance à la vie privée et à la liberté comme moi, je ne vendrais jamais aucun exploit à des forces de l'ordre ou à des agences de renseignement, aucun argent ne peut acheter la liberté :)
@Freedom - bien sur vous. Le problème est bien sûr que le fait de respecter des principes ne les empêche pas d'acheter des exploits ailleurs ou de faire leurs propres recherches.
". Je ne sais pas comment cela s'appliquerait à cette vulnérabilité." - probablement l'équivalent serait de le publier aux fournisseurs de navigateurs, de systèmes d'exploitation, etc., afin qu'ils puissent émettre une mise à jour de routine supprimant silencieusement le certificat racine incriminé (après les certificats clients ont été mis à jour vers un nouveau qui n'est pas compromis) Peut ne pas être nécessaire si une autorité de certification a une trace papier permettant de déterminer si des certificats (autres que les OP) ont été émis de manière frauduleuse
@paj28 c'est pourquoi les citoyens qui devraient se battre pour rendre ce marché illégal, pourquoi devrait-il être légal de vendre des exploits au gouvernement et si vous vendez à des criminels, vous êtes un criminel? Je ne vois pas la différence et ce problème sera très difficile à résoudre en utilisant uniquement la technologie
@Freedom - Cela semble mériter une question à part entière. Si je comprends bien, dans la plupart des pays, il est généralement légal de vendre des exploits à des criminels, et l'utilisation d'exploits par les forces de l'ordre est généralement illégale. Peut-être que cela devrait être changé, mais il y aurait toutes sortes de répercussions, par exemple metasploit serait-il désormais illégal? Pour être honnête, je m'en fiche, la solution évidente est d'exercer un bon opsec et de faire pression pour que le logiciel soit plus sécurisé.
Votre lien ne fonctionne pas pour moi.
1. Veuillez ne pas vendre cette vulnérabilité. 2. Si vous devez émettre un certificat comme preuve de concept, faites-le en toute sécurité, comme décrit ici: https://www.agwa.name/blog/post/how_to_responsably_misissue_a_cert
@AGWA - Votre article de blog semble bon; J'ajouterais que vous devriez générer la clé privée sur une machine propre juste en cas de malware. En ce qui concerne la vente de la vulnérabilité, vous n'avez inclus qu'une demande. Les gens sont plus susceptibles de répondre à un argument raisonné.
@paj28: Une alternative est aussi de prouver qu'elle a été vendue tout en gardant les deux parties de la transaction inconnues. cela entraînerait la fin du système actuel basé sur l'autorité de certification.
#4
+18
jpa
2015-06-11 10:44:56 UTC
view on stackexchange narkive permalink

En cas de doute, vous pouvez également contacter le CERT: https://forms.cert.org/VulReport/

Ils ont de l'expérience dans la gestion de failles 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 contribution à sa recherche.

Bien que le CERT vous conseille généralement de contacter le fournisseur vous-même, pour un cas important comme celui-ci, je suis sûr ils offriraient de l'aide.

Je travaille pour le CERT. Nous serions heureux d'aider à coordonner cette vulnérabilité.
@EdMcMan en fonction du moment choisi (sauf si vous êtes la partie à qui il a parlé), il vous a peut-être manqué
#5
+4
Vincent L
2015-06-11 18:43:08 UTC
view on stackexchange narkive permalink

Ryan Sleevi a de très bons conseils à ce sujet.

Avant de déclencher trop d'alarmes, je contacterais l'équipe de sécurité de Chromium comme il l'a conseillé, juste pour m'assurer que vous ne vous méprenez sur rien.

Avez-vous vérifié votre vulnérabilité par rapport aux exigences de base du forum CAB 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 AFAIK est totalement valide et n'est pas une vulnérabilité aux yeux du Forum CAB. Un certificat peut être généré pour un sous-domaine sans avoir le contrôle de la racine. C'est à dire. vous pouvez obtenir un certificat pour test.google.com sans avoir à démontrer votre contrôle sur google.com.

Essayer d'obtenir un certificat pour security.stackexchange.com sans démontrer le contrôle de stackexchange.com serait un exemple similaire.
Vraiment? Mon dieu, je n'avais aucune idée. Comment un utilisateur peut-il valider le sous-domaine sur lequel il doit se trouver?
#6
+1
jCisco
2015-06-12 01:46:13 UTC
view on stackexchange narkive permalink

Je vous recommande d'obtenir la documentation et la démonstration de la vulnérabilité telle que vous en êtes conscient. Idéalement, si vous pouvez faire vérifier cela entièrement par un tiers, qui a été lu dans la situation.

Pour éviter les problèmes d'intégrité ou de répudiation du 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é, capturer une chaîne de certificats démontrant un défaut serait idéal. Bien sûr, toutes les captures de session qui montrent le vuln en action sont utiles.

Sans divulgation complète, je devine juste de quelle preuve vous avez besoin de toute façon. Prenez la preuve de la documentation de l'exploit et placez-vous 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 fournisseur et le public. Je ne vais pas déranger la révélation de votre identité personnelle, c'est à vous. Communications, si vous voulez être pratique et prêt à foirer ou à ne pas agir avec expérience dans le cas où tout cela explose ou se passe de travers, vous pouvez faire le contact.

Vous pouvez également demander une représentation, soit de la communauté, de l'EFF ou à tout le moins de 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 à titre commercial. Je suis sûr que la communauté ici peut recommander quelques choix sur la 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 en dehors de TLDR; territoire.

Également sur une note latérale, merci pour le temps que vous avez passé à découvrir cette vulnérabilité potentielle. C'est absolument nécessaire.

#7
  0
Gary Belvin
2015-06-11 17:30:09 UTC
view on stackexchange narkive permalink

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é 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
#8
-2
user78343
2015-06-11 01:45:44 UTC
view on stackexchange narkive permalink

Vous pouvez également le signaler à "[email protected]", mais sachez que si l'autorité de certification en question est membre du forum CA / B, elle la verra également. Cependant, il en sera de même pour tous les autres membres de l'autorité de certification et du navigateur. Une autre option consiste à le signaler au CA Security Council, une organisation regroupant les 8 plus grands émetteurs de SSL publics au monde. Il s'agit d'un groupe industriel qui a intérêt à maintenir des normes élevées pour ses membres et à promouvoir les meilleures pratiques parmi tous les CA. Le formulaire est ici: https://casecurity.org/contact-us/

Les gens qui votent contre cela pourraient-ils expliquer le raisonnement derrière cela?
Cette page est fortement orientée vers la publicité. Le lien de contact va à «Contacts médias - Connect Marketing».
Cela semble maintenant correct.Peut-être ont-ils amélioré la page.Non supprimé.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...