Parfois, en voulant bien faire les choses on peut générer plus de problèmes. J’ai récemment été contacté par Oliver, un développeur de logiciels qui travaille dans l’équipe de sécurité de TYPO3, un système de gestion de contenu Web open source populaire en Europe.
Oliver, comme la plupart des développeurs open source, travaille à temps partiel sur le projet. Avec cinq autres, il forme l’équipe de sécurité de TYPO3. Ils reçoivent généralement environ cinq rapports de sécurité par semaine. Étant donné que TYPO3 est une application PHP plutôt complexe, ce chiffre n’est pas surprenant.
En juillet 2020, ils avaient remarqué qu’ils recevaient un volume plus élevé de soumissions de rapport de bug similaires à celles sur lesquelles j’ai récemment écrit. À ce stade, le nombre de tickets hebdomadaires est passé entre 10 et 15. En février 2021, une augmentation exponentielle de ces dernières a été observée, mais nous y reviendrons dans un instant.
Avant la montée en puissance du mois de février, un collègue d’Oliver avait envoyé un rapport de bug indiquant que l’on pouvait extraire une séquence de version d’un serveur Apache Tomcat hébergeant leur instance Jira. Il ne s’agit en aucun cas d’une vulnérabilité, mais d’une pratique assez fréquente étant donné qu’il est recommandé de ne pas divulguer les versions exactes, lesquelles pourraient alors aider un attaquant à savoir que votre système est obsolète et vulnérable à un exploit connu.
Ainsi, TYPO3 a décidé d’offrir à la personne ayant soumis ce rapport de bug un sac estampillé TYPO3 en guise de remerciement pour avoir signalé cette vulnérabilité. L’équipe n’avait pas remarqué que cette personne avait plus de 13 000 abonnés sur Twitter qui le suivaient pour être coaché sur la façon de gagner de l’argent grâce à la chasse aux bugs.
À la réception des cadeaux, il a immédiatement tweeté à ses abonnés: “Reçu un beau sac de @typo3 Réponse instantanée“. Plus tard le même jour, il a également tweeté : “Comment je me suis développé dans la chasse bug bounty ? Un défi sur 2 mois seulement. 1er mois : rapport quotidien de 20 bugs, quelle que soit leur gravité. Tout ce que je trouverais était une opportunité. Je rapportais. 2ème mois : signalement de 5 bugs par jour avec un rapport de qualité“.
Immédiatement, quelques-unes des personnes qui avaient “liké” le tweet ont soumis des rapports de bug affirmant avoir trouvé davantage de séquences de version du serveur sur divers serveurs Web et ressources Internet. Curieusement, certaines personnes ont même soumis des rapports de vulnérabilité indiquant que le code source de TYPO3 était téléchargeable à partir de leur site Web. Bien évidemment que le code source est téléchargeable, il s’agit d’un projet open-source !
Après le tweet les remerciant, le nombre de soumissions de rapport de bug envoyées à l’équipe de sécurité de TYPO3 est passé de 5 par semaine à plus de 10 à 15 par jour.
Une autre tactique qui, selon nous, a été utilisée par cette vague de rapporteurs de bug, mais que nous ne pouvons pas prouver, consiste à signaler le même problème plusieurs fois, mais en utilisant différentes fausses identités pour tenter d’obtenir plusieurs récompenses.
Le premier exemple semble être une personne qui a lancé des scripts pentest agressifs contre une ancienne infrastructure non maintenue, provoquant ainsi une attaque par déni de service. En conséquence, le serveur Web Nginx sur cet hôte a signalé un message d’erreur contenant la séquence de version. Cette personne a soumis un rapport de bug contenant une capture d’écran d’un téléphone Android, et non d’un ordinateur de bureau, une pratique plutôt inhabituelle pour des chasseurs de bugs.
L’adresse email de ce chasseur beg bounty semble porter le nom d’un film bangladais populaire («দেয়র কথা»). Le fuseau horaire et l’adresse IP ont confirmé qu’elle semblait provenir du Bangladesh.
Environ 60 minutes plus tard, un autre rapport de bug presque identique a été envoyé, contenant également une capture d’écran de la même version d’Android. Cette personne prétendait s’appelée Royel, le message affichait le fuseau horaire BDT et contenait une phrase étrange identique à la première, “La version est en train d’être divulguée, :-)“.
L’équipe TYPO3 a répondu en résolvant certains des problèmes provoquant l’affichage des informations de version et a demandé plus de détails au rapporteur de bug pour comprendre comment il avait planté l’application générant ainsi des erreurs. Ils étaient intrigués par les “problèmes critiques” mentionnés et voulaient en savoir plus. La réponse du chasseur beg bounty ? “Donnez-moi une récompense pour mon bug“.
Oliver a répondu en expliquant comment l’équipe évalue la gravité des menaces, principalement sur les faits présentés et le risque associé au niveau de la plateforme et a donc de nouveau demandé plus de détails. Cette insistance a semblé mettre en colère le “chasseur beg bounty” qui s’est ensuite mis à les menacer.
“Cher Monsieur, si vous ne me récompensez pas pour le bug que je vous ai indiqué, je divulguerais les informations de votre entreprise sur Facebook, Instagram, Telegram LinkedIn, Twitter et YouTube.
Je publierais des informations pour que personne d’autre ne vous rapporte des bugs concernant ce programme. Vous avez compris ?
Je serai très heureux si vous me récompensez pour ce bug, mais sans récompense, je divulguerais vos informations”.
Il s’agit en réalité d’une tentative d’extorsion, ni plus, ni moins. Ainsi, après avoir compris qu’ils n’obtiendraient rien, ils ont tout de même continuer à “mendier” pour obtenir leur récompense.
Malheureusement, la seule conclusion que je puisse tirer de l’expérience d’Oliver est qu’une bonne action a quasiment toujours des conséquences. Cette histoire qui a commencé avec un ‘geste commercial’ envers le chasseur de bug qui n’avait vraiment suivi aucune directive et qui avait signalé un problème mineur, s’est transformée pour déboucher au final sur une multiplication x5 à x10 des rapports de bug représentant peu ou pas de valeur du tout.
Il existe des groupes de personnes qui encouragent activement ce genre de comportement (à savoir la chasse beg bounty) et il semble que cela soit devenu incontrôlable. Je recommande donc de ne payer ou de récompenser uniquement les rapports de sécurité soumis via des programmes officiellement approuvés.
Des services comme Bugcrowd et HackerOne peuvent également vous aider à définir des politiques et vous proposer des services que vous pouvez payer pour vous assister dans le tri de vos rapports afin d’augmenter votre ratio signal/bruit. Cette solution peut être un excellent choix si vous souhaitez obtenir de l’aide via un programme bug bounty et récompenser ceux qui sont vraiment motivés par l’amélioration de la sécurité de votre produit ou service.
Billet inspiré de The unintended consequences of rewarding beg bounty hunters, sur le Blog Sophos.
Qu’en pensez-vous ? Laissez un commentaire.