Divulgation complète ou responsable de la divulgation des vulnérabilités de sécurité

Il y a trois semaines, un grave problème de sécurité sous OS X 10.10.4 a été découvert. Cela, en soi, n'est pas particulièrement intéressant.

Des vulnérabilités de sécurité dans des progiciels populaires sont découvertes tout le temps, et OS X ne fait pas exception. La base de données de vulnérabilités Open Source (OSVDB) indique au moins 1100 vulnérabilités marquées comme “OS X”. Mais quoi est intéressant est la façon dont cette vulnérabilité particulière a été révélée.

Plutôt que de le dire à Apple et de lui laisser le temps de remédier au problème, le chercheur a décidé de publier son exploit sur Internet pour que tout le monde puisse le voir..

Le résultat final fut une course aux armements entre Apple et des hackers au chapeau noir. Apple devait publier un correctif avant que la vulnérabilité ne devienne une arme, et les pirates informatiques devaient créer un exploit avant que les systèmes à risque ne soient corrigés..

Vous pourriez penser que cette méthode de divulgation est irresponsable. Vous pouvez même appeler cela contraire à l'éthique ou imprudent. Mais c'est plus compliqué que ça. Bienvenue dans le monde étrange et déroutant de la divulgation des vulnérabilités.

Divulgation complète ou responsable

Il existe deux manières courantes de révéler les vulnérabilités aux éditeurs de logiciels..

Le premier s'appelle divulgation complète. Comme dans l'exemple précédent, les chercheurs publient immédiatement leur vulnérabilité dans la nature, ne donnant aux vendeurs aucune occasion de publier un correctif..

La seconde s'appelle divulgation responsable, ou une divulgation échelonnée. C’est là que le chercheur contacte le fournisseur avant la publication de la vulnérabilité..

Les deux parties conviennent alors d'un délai dans lequel le chercheur promet de ne pas publier la vulnérabilité, afin de donner au fournisseur l'occasion de créer et de publier un correctif. Cette période peut aller de 30 jours à un an, en fonction de la gravité et de la complexité de la vulnérabilité. Certaines failles de sécurité ne peuvent pas être corrigées facilement et nécessitent la reconstruction complète de systèmes logiciels..

Une fois que les deux parties sont satisfaites du correctif produit, la vulnérabilité est ensuite divulguée et un numéro CVE lui est attribué. Celles-ci identifient de manière unique chaque vulnérabilité et celle-ci est archivée en ligne sur la mémoire OSVDB..

Mais que se passe-t-il si le délai d'attente expire? Eh bien, une des deux choses. Le fournisseur négociera ensuite une extension avec le chercheur. Mais si le chercheur n’est pas satisfait de la réaction ou de l’agir du fournisseur, ou s’il estime que la demande de prolongation est déraisonnable, il peut simplement la publier en ligne, sans solution..

Dans le domaine de la sécurité, il y a de vives discussions sur la meilleure méthode de divulgation. Certains pensent que la seule méthode éthique et précise est la divulgation complète. Certains pensent qu'il est préférable de donner aux fournisseurs l'occasion de résoudre un problème avant de le relâcher dans la nature..

En fin de compte, il existe des arguments convaincants pour les deux parties.

Les arguments en faveur de la divulgation responsable

Regardons un exemple de la meilleure utilisation de la divulgation responsable.

Lorsque nous parlons d'infrastructures critiques dans le contexte d'Internet, il est difficile d'éviter de parler du protocole DNS. Comment changer vos serveurs DNS et améliorer la sécurité Internet Comment changer vos serveurs DNS et améliorer la sécurité Internet Imaginez ceci - vous vous réveillez Au matin, sers-toi une tasse de café, puis assieds-toi devant ton ordinateur pour commencer ton travail de la journée. Avant que vous obteniez réellement… Lire la suite. C’est ce qui nous permet de traduire des adresses Web lisibles par l’homme (comme makeuseof.com) en adresses IP..

Le système DNS est incroyablement compliqué, et pas seulement au niveau technique. Il y a beaucoup de confiance dans ce système. Nous sommes convaincus que lorsque nous tapons une adresse Web, nous sommes envoyés au bon endroit. L'intégrité de ce système dépend beaucoup de l'intégrité de ce système.

Si quelqu'un était capable d'interférer avec une requête DNS ou de compromettre une requête DNS, il y a beaucoup de risque de dommages. Par exemple, ils pourraient envoyer des personnes vers des pages de banque en ligne frauduleuses, leur permettant ainsi d’obtenir leurs coordonnées bancaires en ligne. Ils pourraient intercepter leurs e-mails et leur trafic en ligne via une attaque de type "man-in-the-middle" et en lire le contenu. Ils pourraient nuire fondamentalement à la sécurité d'Internet dans son ensemble. Trucs effrayants.

Dan Kaminsky est un chercheur en sécurité très respecté, avec une longue expérience de la recherche de vulnérabilités dans des logiciels bien connus. Mais il est surtout connu pour la découverte, en 2008, de la vulnérabilité probablement la plus grave du système DNS. Cela aurait permis à quelqu'un d'effectuer facilement une attaque par empoisonnement du cache (ou usurpation de DNS) sur un serveur de noms DNS. Les détails plus techniques de cette vulnérabilité ont été expliqués à la conférence Def Con 2008.

Kaminsky, parfaitement conscient des conséquences de la publication d'une telle faille grave, a décidé de la divulguer aux fournisseurs du logiciel DNS concernés par ce bogue..

Un certain nombre de produits DNS importants ont été concernés, notamment ceux développés par Alcatel-Lucent, BlueCoat Technologies, Apple et Cisco. Le problème concernait également un certain nombre d'implémentations DNS fournies avec certaines distributions Linux / BSD populaires, y compris celles pour Debian, Arch, Gentoo et FreeBSD..

Kaminsky leur a donné 150 jours pour produire un correctif et a travaillé avec eux en secret pour les aider à comprendre la vulnérabilité. Il savait que le problème était si grave et les dommages potentiels si importants qu'il aurait été incroyablement imprudent de le publier publiquement sans donner aux vendeurs l'occasion de publier un correctif..

Incidemment, la vulnérabilité a été révélée accidentellement par la société de sécurité Matsano dans un article de blog. Cet article a été supprimé, mais il a été mis en miroir et, un jour après la publication, un exploit intitulé Voici comment ils vous piratent: le monde obscur des kits d’exploitation Voici comment ils vous piratent: le monde obscur des kits d’exploitation Les fraudeurs peuvent utiliser exploiter les vulnérabilités et créer des logiciels malveillants. Mais quels sont ces kits d'exploits? D'où viennent-ils? Et comment peuvent-ils être arrêtés? Lire la suite a été créé.

La vulnérabilité DNS de Kaminsky résume en définitive le noeud de l'argument en faveur d'une divulgation responsable et échelonnée. Certaines vulnérabilités - comme les vulnérabilités zéro jour Qu'est-ce qu'une vulnérabilité zéro jour? [MakeUseOf explique] Qu'est-ce qu'une vulnérabilité de jour zéro? [MakeUseOf Explains] Read More - sont si importants que leur publication causerait des dommages importants.

Mais il y a aussi un argument convaincant en faveur de ne pas donner d'avertissement.

L'argument en faveur d'une divulgation complète

En libérant une vulnérabilité à découvert, vous déverrouillez une boîte de pandore où des individus peu recommandables sont capables de produire rapidement et facilement des exploits et de compromettre des systèmes vulnérables. Alors, pourquoi quelqu'un choisirait-il de le faire??

Il y a plusieurs raisons. Premièrement, les fournisseurs tardent souvent beaucoup à répondre aux notifications de sécurité. En forçant efficacement leur main en libérant une vulnérabilité dans la nature, ils sont plus motivés pour réagir rapidement. Pire encore, certains sont enclins à ne pas publier pourquoi les entreprises qui gardent un secret sont des bonnes choses sont une bonne chose. Pourquoi des entreprises qui gardent un secret des secrets peut être une bonne chose Avec autant d’informations en ligne, nous nous inquiétons tous des fuites potentielles de sécurité. Mais ces violations pourraient être tenues secrètes aux États-Unis afin de vous protéger. Cela semble fou, alors qu'est-ce qui se passe? En savoir plus sur le fait qu'ils livraient des logiciels vulnérables. Une divulgation complète les oblige à être honnêtes avec leurs clients.

Apparemment, @PepsiCo ne se soucie pas de la vuln de leur site, n'acceptant pas l'aide non sollicitée. A déjà une équipe de seconde. Je ferai une divulgation complète

- Paquet blanc (@WhitePacket) 4 septembre 2015

Mais cela permet également aux consommateurs de choisir en connaissance de cause s'ils souhaitent continuer à utiliser un logiciel en particulier et vulnérable. J'imagine que la majorité ne serait pas.

Que veulent les vendeurs?

Les vendeurs n'aiment pas la divulgation complète.

Après tout, c’est incroyablement mauvais pour les relations publiques et cela met leurs clients en danger. Ils ont essayé d'inciter les gens à divulguer les vulnérabilités de manière responsable par le biais de programmes de prime aux bogues. Celles-ci ont connu un succès remarquable, Google payant 1,3 million de dollars rien qu'en 2014..

Même si cela vaut la peine de souligner que certaines entreprises - comme Oracle Oracle veut que vous arrêtiez de leur envoyer des bogues - voici pourquoi c'est fou Oracle, veut que vous cessiez de leur envoyer des bogues - voici pourquoi c'est fou Oracle est en colère contre un blog erroné rédigé par le chef de la sécurité Mary Davidson. Cette démonstration de la différence de la philosophie de sécurité d'Oracle par rapport à la norme n'a pas été bien accueillie par la communauté de la sécurité… En savoir plus - dissuadez les personnes d'effectuer des recherches sur la sécurité de leurs logiciels.

Mais il y aura toujours des gens qui insistent pour utiliser la divulgation complète, soit pour des raisons philosophiques, soit pour leur propre divertissement. Aucun programme de prime aux bogues, aussi généreux soit-il, ne peut contrer cela.

En savoir plus sur: Sécurité informatique, Piratage.