Un moyen facile de gagner de l'argent sur Bug Bounty

Vous avez sûrement déjà entendu l'expression «chasse aux sacs» plus d'une fois, et je suis sûr que vous ne refuseriez pas de gagner quelques centaines (voire des milliers) de dollars si vous déceliez une vulnérabilité potentielle dans le programme de quelqu'un d'autre. Dans cet article, je vais parler d'une astuce qui aidera à rechercher des projets open source pour de telles vulnérabilités.

Bug Bounties sur les logiciels libres et open source - qu'est-ce que c'est?

Bug Bounty est un nom générique pour divers programmes dans lesquels les développeurs de sites Web et de logiciels offrent des récompenses en espèces pour trouver des bogues et des vulnérabilités. En plus des programmes bien connus de Bug Bounty de grandes sociétés comme Apple ou Microsoft, il existe également des programmes pour rechercher les vulnérabilités dans les projets open source.

Beaucoup d'entre eux peuvent être trouvés sur HackerOne, mais peut-être le plus important est FOSSA - Audit logiciel libre et open source. Il s'agit d'un programme de recherche sur la vulnérabilité parrainé par l'Union européenne pour divers projets open source. La cagnotte totale est un montant impressionnant - jusqu'à 850 000 euros!

Comment participer?

Vous devez d'abord vous inscrire sur HackerOne . Nous aurons besoin exactement de ces projets open source. HackerOne a toute une liste .

Si vous souhaitez participer au Bug Bounty de l'Union européenne - une liste des projets participant à ce programme peut être trouvée ici . Pour la plupart des projets, il suffira d'être enregistré sur HackerOne, mais la plupart des programmes répertoriés dans cette liste sont sur intigriti.com.

Pour participer, vous devez choisir un projet qui vous convient, puis lire attentivement les conditions de participation. S'ils vous satisfont, il est temps de pratiquer.

Pour trouver la vulnérabilité et obtenir votre argent, il vous suffit de télécharger le projet (ou de le cloner à partir de GitHub) et d'analyser soigneusement chaque ligne de code, en examinant chaque expression pour des erreurs potentielles. Si vous trouvez quelque chose qui pourrait affecter la sécurité du programme - écrivez-le dans un rapport et envoyez-le aux développeurs. S'ils évaluent votre trouvaille comme valant la promotion - votre argent est dans votre poche :).

Attendez, où est la légèreté?

Et la facilité est qu'il n'est pas nécessaire d'analyser le code exclusivement manuellement. Il existe des outils pour rechercher des erreurs dans le code en mode automatique. Par exemple, les analyseurs de code statique. Je préfère utiliser notre développement - PVS-Studio . L'analyseur PVS-Studio est capable de trouver des erreurs dans le code écrit en C ++, C # et Java, et dispose également d'une interface pratique. De plus, il existe plusieurs options pour son utilisation gratuite. Il existe également de nombreux autres analyseurs de code .

Bien entendu, les analyseurs statiques peuvent détecter loin de toutes les erreurs. Oui, et que Dieu les bénisse! Après tout, notre objectif est de trouver les erreurs rapidement et facilement, et non de les trouver toutes.

Une fois le projet téléchargé et assemblé, il suffira de ne faire que quelques clics pour démarrer l'analyse. Le résultat sera un rapport avec une quantité (généralement considérable) d'avertissements générés par l'analyseur. Dans PVS-Studio, ils sont classés en trois niveaux de confiance. Vous devez commencer par les avertissements de premier niveau, afin que les niveaux orange et jaune puissent être filtrés du résultat de l'analyse.

Un exemple de filtrage des résultats d'analyse.

Ainsi, il ne reste plus qu'à passer en revue les avertissements restants et à sélectionner parmi eux les endroits qui peuvent constituer le plus grand danger. Il est nécessaire de vérifier s'il est possible de reproduire l'un d'eux directement pendant le fonctionnement du programme. Si vous réussissez à le faire, cela augmentera non seulement les chances que les développeurs acceptent le rapport, mais cela augmentera également le montant du paiement. Dans ce domaine, la visibilité est votre meilleure amie.

Il convient également de déterminer si l'erreur trouvée affecte la sécurité du programme. En effet, dans ce cas, le montant qui vous sera versé sera plusieurs fois supérieur :)

La capture d'écran montre l'interface de Visual Studio. Cependant, ne vous y trompez pas. L'analyseur peut être utilisé non seulement comme plug-in pour Visual Studio, mais également indépendamment, y compris sous Linux et macOS .

Avantages de cette approche

Tout d'abord, l'utilisation d'un analyseur statique est l'un des moyens les plus simples de trouver des erreurs. Pour utiliser des analyseurs de code, il n'est pas du tout nécessaire d'avoir des connaissances particulières: il suffit de comprendre la langue dans laquelle le code testé est écrit.

Deuxièmement, les analyseurs sont prudents. Ils ne se fatiguent pas et ne perdent pas de vigilance, contrairement à une personne. Par conséquent, en les utilisant, vous pouvez analyser des bases de code arbitrairement grandes avec un coût presque minimal.

Troisièmement, les analyseurs ont souvent plus de connaissances qu'une personne. Qu'est-ce que cela signifie? Permettez-moi d'expliquer mon idée sur l'exemple de code du noyau Android:

static void FwdLockGlue_InitializeRoundKeys() { unsigned char keyEncryptionKey[KEY_SIZE]; .... memset(keyEncryptionKey, 0, KEY_SIZE); // Zero out key data. } 

Il semblerait où il pourrait y avoir une erreur?

Il s'avère que le compilateur, voyant que le tableau keyEncryptionKey n'est utilisé nulle part ailleurs, peut optimiser le code et en supprimer l'appel de fonction memset . Et il le fera uniquement lors de l'assemblage dans la configuration de version. Tout irait bien, mais seule la clé de cryptage restera déverrouillée dans la RAM pendant un certain temps, elle peut donc être obtenue par un attaquant. Un vrai trou de sécurité!

Et après tout, trouver cette erreur vous-même est presque impossible: en mode débogage, appeler memset fonctionne très bien. Et vous n'écrirez aucun test pour cela ... Il ne reste plus qu'à connaître cette fonctionnalité et à vous en souvenir vous-même.

Mais que faire si les développeurs du projet ne connaissent pas cette fonctionnalité? Et si vous ne connaissez pas cette fonctionnalité lorsque vous recherchez des bogues? Ce n'est pas important pour l'analyseur, car il dispose des diagnostics V597 , par conséquent, lorsque vous consultez un rapport, vous en serez certainement informé.

Enfin, quatrièmement. L'un des avantages les plus utiles de l'utilisation de l'analyse statique lors de la poursuite d'un Bug Bounty est la vitesse. Oui, avec lui, vous pouvez vérifier deux, trois, quatre projets dans la soirée - mais ce n’est pas tout.

Plus important encore, vous pouvez être le premier. Bien qu'une récompense soit offerte pour la recherche de bogues dans n'importe quel projet, le projet continue d'être finalisé et développé. Les développeurs déploient de nouvelles versions et de nouvelles fonctionnalités, et avec eux, de nouveaux codes et de nouveaux espaces ouverts pour les erreurs. En utilisant l'approche décrite par moi, il sera possible d'examiner avec précision les nouvelles erreurs et vulnérabilités potentielles dès le premier jour de leur publication.

Vulnérabilités potentielles

Le lecteur attentif peut être perplexe:

Arrête, arrête! D'une part, il fait référence à une recherche d'erreurs dans les programmes dans le code, d'autre part, des vulnérabilités potentielles sont mentionnées. De plus, les vulnérabilités sont plus intéressantes du point de vue de Bug Bounty. Veuillez clarifier!

Le fait est que les erreurs et les vulnérabilités potentielles sont essentiellement la même chose. Bien sûr, seules quelques erreurs / vulnérabilités potentielles dans les recherches futures peuvent se révéler être de vraies vulnérabilités. Cependant, une erreur inoffensive et une vulnérabilité grave peuvent avoir exactement la même apparence dans le code. L'article « Comment PVS-Studio peut-il aider à trouver des vulnérabilités? » Présente plusieurs de ces erreurs (à première vue ordinaires), qui sont maintenant connues pour être des vulnérabilités.

Soit dit en passant, selon le rapport de l'Institut national des normes et de la technologie (NIST), environ 64% des vulnérabilités des applications sont associées à des erreurs logicielles, et non à des failles de sécurité (pas un manque de fonctionnalités de sécurité).

Alors, prenez PVS-Studio en toute confiance et commencez à rechercher des erreurs et des défauts de sécurité! Soit dit en passant, la classification des avertissements selon CWE vous y aidera.

Conclusion

J'espère avoir aidé le lecteur à trouver le bug qui lui apporterait une petite reconnaissance et une récompense monétaire. Je suis sûr que l'analyse statique les y aidera! N'oubliez pas que les développeurs, en règle générale, n'ont pas le temps d'analyser en détail les erreurs trouvées, vous devez donc prouver que votre recherche peut réellement affecter le programme. La meilleure façon serait de le visualiser. Et rappelez-vous: plus le bogue du code peut violer la sécurité, plus ils le paieront.

C’est probablement tout. Bonne chance pour trouver votre récompense!

Si vous souhaitez partager cet article avec un public anglophone, veuillez utiliser le lien vers la traduction: George Gribkov. Un moyen facile de gagner de l'argent sur Bug Bounty .