Quand on opère un site tel que le nôtre, une des tâches quotidienne est de relever la boîte mail de l’association et d’y faire un peu le tri dans l’optique de supprimer les éventuels spams reçus. Cette semaine, j’ai hésité longuement avant d’effacer un email nous étant destiné provenant de la plateforme Open Bug Bounty, dont je n’avais jamais entendu parler. Je ne l’ai heureusement pas fait et je vous explique pourquoi dans cet article « retour d’expérience ».
Votre site est vulnérable – what ?
L’email reçu commençait par cette magnifique phrase en majuscules ponctuée d’un point d’exclamation : « UNE FAILLE A ETE TROUVEE SUR VOTRE SITE WEB ! ». Quelques paragraphes et liens nous expliquant comment obtenir les détails de cette faille suivaient cette annonce. Plutôt douteux comme approche.
Avant d’effacer cet email et de cliquer sur ses liens, j’ai pris le temps de faire un peu de recherche sur internet à propos d’Open Bug Bounty. La page wikipedia Open Bug Bounty nous apprend que ce site, comme son nom l’indique, est une plateforme libre de Bug Bounty.
On peut voir ce concept un peu comme celui des chasseurs de primes dans les jeux vidéo : vous arrêtez un vilain, et vous récupérez la récompense. Ici, c’est un peu pareil, vous trouvez des failles de sécurité sur un site et vous demandez une récompense au propriétaire. Cependant, les propriétaires de sites souhaitant que des chercheurs les testent vont au préalable publier leur « bounty program » (leur avis de recherche) sur des plateformes officielles telles que HackerOne ou BugCrowd afin d’énoncer leurs conditions : récompenses, qu’est ce qui est autorisé, qu’est ce qui ne l’est pas, etc. Il n’est en effet pas autorisé et même punissable de s’amuser à chercher des failles sur un site sans l’accord de son propriétaire.
Open Bug Bounty change un peu la donne par rapport à ce concept traditionnel que je viens de présenter. Ici, la plateforme autorise des chercheurs à partir en chasse de failles non-intrusives sur l’internet entier et de les y publier sous le principe de Responsible Disclosure et surtout sans exigence de récompenses, sous peine d’être banni de la plateforme.
Il y a pas mal à digérer ici. En effet, rien n’autorise légalement la recherche active de failles (même non-intrusives) sur un site et rien ne garantit que le chercheur agira éthiquement. Il pourrait très bien exiger une rançon et menacer de divulguer la faille à défaut de paiement.
Les seuls garde-fous sont :
- La clause disant qu’un chercheur ne peut exiger de récompenses ou agir de façon non-éthique, sous peine d’être banni.
- Le principe de Responsible Disclosure interdisant au testeur de publier les détails de la faille avant 90 jours sans réponse du propriétaire du site.
Le fil rouge sur le fil bleu
Sachant tout ça, je me suis dit que j’allais quand même tenter ma chance, répondre et voir jusqu’où ça nous mènerait. Le processus pour obtenir les détails d’une faille est de cliquer sur un lien menant au rapport (dans un état « on hold » avant la barre des 90 jours) indiquant le type de faille (ici, une faille de type XSS) , le nom du testeur (ici, login_denied) et la façon de le contacter.
Je lui ai donc envoyé un email demandant les détails de la faille, le remerciant pour son approche et lui expliquant nos termes de récompenses. Alea Jacta Est.
En parallèle, j’ai cherché de mon côté où pouvait se trouver cette faille et ai pour ce faire utilisé moi-aussi Open Bug Bounty. La plateforme est extrêmement puissante car elle permet de lister tous les rapports d’un chercheur en particulier et tous les rapports de sites spécifiques. J’ai donc listé tous les rapports de notre chercheur et suis remonté dans le temps jusqu’à la barre fatidique des 90 jours. Tous les rapports plus anciens passent en mode full disclosure (tous les détails de la faille trouvée sont publiés, y compris comment la reproduire). J’ai pu ainsi lister les payloads utilisés habituellement par le chercheur et ai pu détecter un certain pattern. Même sans devoir aller voir dans nos logs, j’ai pu assez rapidement trouver où se trouvait la faille sur notre site, la reproduire et la résoudre en moins de 24 heures.
Tout est bien qui finit bien
Le lendemain, je recevais un email du chercheur m’expliquant les détails de la faille et qu’il ne pouvait plus la reproduire. Nous avons ensuite eu un échange dans lequel j’expliquais mes actions. Tout est bien qui finit bien au final.
Mon avis sur Open Bug Bounty est donc plutôt positif pour de nombreuses raisons
- La plateforme utilise le principe de Responsible Disclosure : il préserve les sites pendant 90 jours de la publication des détails de la faille en les encourageant à améliorer leur sécurité.
- Le testeur a agi de façon tout à fait éthique, a répondu rapidement et n’a exigé aucune récompense
- Ce processus est bénéfique aux « petits » sites ne disposant pas d’équipe sécurité dédiée ou de gros budget en permettant de stimuler une approche où une équipe offensive (le chercheur) travaille de pair avec une équipe défensive (les opérateurs du site) dans l’optique d’améliorer la sécurité.
- Si la faille est corrigée avant les 90 jours, l’opérateur du site peut demander à ce que le rapport soit retiré de la plateforme.
- Le principe de full disclosure permettant aux chercheurs et aux opérateurs de site d’apprendre des expériences publiées.
- Il faut aussi prendre en compte que les opérateurs de site sont tenus de protéger leurs utilisateurs ainsi que les données à caractère personnel. De ce fait, se tester devrait faire partie des tâches d’un site. Ici, le test et le rapport sont fournis. Corriger les failles trouvées peut donc aussi être vu comme une forme de « due dilligence« .
- La plateforme sert de canal de communication pour les sites ne documentant pas comment rapporter une vulnérabilité les impactant.
Toutefois, il est aussi possible que cette plateforme soit utilisée à des fins déviantes : un testeur agissant de façon non-éthique ou des hackers listant toutes les anciennes failles publiées non résolues dans le but de les exploiter. Mon conseil aux sites recevant des emails d’Open Bug Bounty sera donc de les traiter sérieusement car dans le cas contraire vous risqueriez de vous retrouver avec une faille exploitable vous affectant publiée sur internet.
Je conclurai en remerciant encore une fois login_denied pour son travail et son attitude professionnelle et éthique.
[Update] Un nouveau cas
Cet article aura été bénéfique car nous avons été à nouveau contacté dans un contexte OpenBugBounty par l’utilisateur <ZerMal.kzb /> après qu’il ait pu le lire.
Il nous a contacté directement via notre Discord PxlBBQ pour nous faire part de vulnérabilités détectées.
Nous avons pu travailler ensemble sur Discord pour améliorer la situation et corriger ces failles. J’ai à nouveau trouvé cette approche éthique et professionnelle et le remercie pour sa démarche.
Nous ne rentrerons pas dans les détails ici mais ce cas aura permis certaines améliorations intéressantes. En effet, la plupart des CMS ne permettent pas de spécifier des HTTP Headers de sécurité « out of the box ».
Nous avons ici pu grâce à un plugin configurer de nombreux headers dont l’intéressant Content Security Policy (CSP). Celui-ci permet de contrôler des éléments tels que l’origine d’exécution des scripts, le contenu qui peut être mis dans des frames, etc. Un point très intéressant dans le contexte OpenBugBounty est qu’activer une CSP restrictive va interdire l’exécution de la fonction JavaScript eval qui est souvent la cause d’une catégorie de XSS particulière: les DOM-Based XSS.
