Entreprises, comment éviter les remontées sauvages de failles de sécurité ?

Bon, vous le savez, depuis 2013 on organise des Bugs Bounties avec les copains de YesWeHack. Et en 2015, on a décidé de créer www.yeswehack.com, une plateforme qui permet facilement à chaque société qui le souhaite, de créer son programme de bug bounty. L’idée c’est de faire tester un site, une application, un projet open source, des webservices, des objets connectés et autres, à notre communauté de Hunters (experts en sécurité) pour voir si des bugs de sécurité s’y trouvent. C’est un bon moyen d’améliorer la sécurité informatique de sa boite, dans un cadre de développement agile, en ne payant qu’au bug effectif remonté.

Et aujourd’hui, j’aimerais vous parler du concept de bug bounty sauvage, ou plus généralement de remontées sauvages de failles, car plusieurs de nos clients, avant de faire appel à nous, y ont été confrontés.

Le bug bounty classique, c’est-à-dire légal, officiel, approuvé par la société qui l’initie, c’est la mise en place d’un périmètre de test, soumis à des experts en sécurité en mode privé ou public, avec à la clé, un versement d’une récompense aux experts ayant trouvé et remonté une vulnérabilité. Ça, c’est cool.

En opposition, la remontée sauvage de failles de sécurité n’est pas encadrée et se fait sans l’approbation initiale de l’entreprise concernée. Il n’y a pas de règles donc cela peut revêtir les habits d’une “Coordinated Disclosure” parfaitement propre comme on le fait avec Zerodisclo.com. C’est le cas de figure idéal quand aucun programme de bug bounty n’est en place.

Mais le plus souvent, ça se fait de manière un peu plus violente. Soit les informations concernant la faille sont publiquement affichées sur un site, un forum…etc. et donc peuvent être utilisées par d’autres. Soit la personne qui a trouvé la faille l’annonce (par mail ou publiquement sur un site dédié à ça) et réclame à l’entreprise une récompense (ou un job) en échange de ces infos. On rentre alors dans un cadre qui s’apparente plus à du chantage.

Et malheureusement, une entreprise qui est confrontée à cela est souvent démunie et son seul réflexe est de porter plainte. (ce qui est une mauvaise idée la plupart du temps)

Voici donc quelques clés pour garder au maximum la maitrise de ses vulnérabilités.

La première étape parait évidente, mais plutôt que d’attendre qu’un inconnu lance un bug bounty vous concernant sur une plateforme tierce dont vous ne savez rien, il faut prendre les devants et créer votre propre programme de Bug Bounty.

Cela va vous permettre plusieurs choses :

• Obtenir rapidement un niveau de sécurité supérieur à l’actuel et donc éviter la remontée de failles trop évidentes.
• Avoir une connaissance immédiate des failles trouvées, sans chantage et sans négociation.
• Être le seul à avoir connaissance du détail des failles remontées.
• Garder la maitrise totale du budget, du périmètre de test et du nombre de hunters qui vont se pencher sur ce périmètre.
• Pouvoir échanger sans risque avec le découvreur de la faille pour lui demander des informations complémentaires ou de l’aide pour la correction du problème.
• De plus, proposer une récompense évitera, la plupart du temps, qu’une faille se retrouve décrite publiquement dans la nature.

Ça, c’est donc le 1er truc à faire. Choisissez aussi la bonne plate-forme de bug bounty au regard du contexte éco/géo/politico/légal, car vous vous en doutez les lois US diffèrent des lois européennes en matière de divulgation des vulnérabilités. Notez quand même que l’Europe a pris au sérieux le dossier de la protection des données personnelles via la RGPD, mais revenons à nos bugs.

Ensuite, **quelque chose d'hyper important si vous fonctionnez avec un bug bounty privé, c'est de rester discret**. En effet, je vois trop souvent des entreprises expliquer partout qu'elles ont un bug bounty privé, voire d'autres plateformes de Bug Bounty se vanter dans les médias d'avoir tel ou tel client (en bug bounty privé évidemment).

La nature même de “privé” c’est que tout le monde n’est pas invité à la fête. Donc si vous criez sur tous les toits que vous avez un programme de bug bounty et que celui-ci n’est pas public, les gens vont faire n’importe quoi avec votre site.

D’abord, ils n’auront pas connaissance du périmètre, donc ils vont tester tout ce qui va leur passer sous la main, sans chercher à savoir si de vôtre côté vous approuvez ou non. Vous essuierez aussi peut-être quelques attaques DDoS, des tentatives des phishings… etc. Bref, pleins de trucs moches. Ensuite ceux qui vont trouver une faille, tenterons de vous contacter par tous les moyens. Et comme ils n’auront aucune connaissance du montant de vos récompenses, ils commenceront à négocier à l’aveuglette, voire à basculer en mode chantage. Et cela leur paraitra normal de défoncer votre site et de vous demander un gros chèque, puisqu’après tout, vous avez expliqué partout publiquement que vous proposiez de “l’argent contre des failles de sécurité”.

J’ai déjà vu ce genre de problèmes chez une société qui n’avait pas pris conscience de cela et qui a été un peu trop bavarde sur son bug bounty privé. Pensez donc bien à garder secrète l’existence de tous programmes de bug bounty privés que vous lanceriez. Et si veillez bien aussi à ce que vos partenaires techniques sur le bug bounty n’utilisent pas le nom de votre société pour faire du name dropping promotionnel.

Le but évidemment, c’est qu’ensuite vous puissiez sortir de cette phase “privée” pour passer en bug bounty public. À ce moment-là, tout le monde sera invité à la fête et pourra se référer au périmètre et aux montants des récompenses que vous proposerez. Ce sera enfin l’occasion de communiquer publiquement et sans risque de débordement sur votre programme de bug bounty pour mettre en avant l’importance que vous accordez aux données de vos clients et à la sécurité de votre site.

Maintenant que faire si malgré toutes ces précautions, quelqu’un décide de vous remonter une vulnérabilité de manière un peu plus sauvage ? Et bien il n’y a pas 36 000 solutions, il suffit de rediriger gentiment le hunter vers votre programme de bug bounty officiel, en lui expliquant qu’en passant par là, il pourra toucher une récompense si sa faille est valide. Vous pourrez ensuite patcher au plus vite la ou les failles concernées.

Pour compléter la lecture de cet article, je vous renvoie vers ce PDF qui revient sur la plupart des mythes liés aux bugs bounty ouverts qui pourraient freiner les sociétés les moins informées sur cette pratique de la crowdsecurity.

Bonne lecture.