Table of Contents
vraj est chercheur en sécurité. On a parlé de ce qui fait un bon hacker, du rôle de la psychologie dans le bug bounty et de comment il a perdu un wallet crypto.
Il y a des centaines de hunters dans la Yogosha Strike Force. Il y a des centaines de hunters dans la Yogosha Strike Force. Il y a ceux qui excellent techniquement, et ceux qui se distinguent par une psyché qui en fait de redoutables attaquants. Et puis il y a vraj – Vishwaraj Bhattrai – qui brille dans tous les domaines. Il occupe actuellement la 4e place au classement Yogosha All-time, et la 5e place au leaderboard 2022.
Chez Yogosha, tous ceux qui ont eu la chance de travailler avec lui l’adorent. Il est brillant, mais aussi sympa. Alors quand nous nous sommes demandé quel serait le prochain hacker interviewé, la réponse était évidente.
Depuis combien de temps es-tu dans le domaine du hacking éthique ?
Professionnellement, je dirais environ 6 ans. Mais je me suis lancé dans le hacking éthique avant ça, j’ai surtout appris tout seul en lisant des livres et en allant dans des cybercafés pendant mes études. Je crois que j’avais environ 19 ans quand j’ai commencé à me renseigner sur le phishing. J’ai commencé à explorer le sujet pour le plaisir, et plus tard, je m’y suis mis pour de bon. Après cela, j’ai fait ma licence en sciences informatiques. Parallèlement, j’ai continué à m’exercer et à améliorer mes compétences dans divers domaines. J’ai ensuite choisi d’en faire mon métier, parce que c’était un challenge et que j’aimais le processus créatif de casser des choses – même si, techniquement, on ne les casse pas, on montre juste comment elles étaient déjà cassées. C’était comme un puzzle pour moi.
Tu es bug hunter et ingénieur en sécurité de métier. Qu’est-ce qui te plaît le plus en travaillant dans la cybersécurité ?
Ce que j’apprécie le plus, c’est de pouvoir satisfaire ma curiosité et d’avoir une liberté de création. Il peut s’agir chaque jour d’un système ou d’un environnement différent, où l’on peut expérimenter ses idées et apprendre.
En tant que hunter, c’est vraiment plaisant. Je me lance et j’essaie tout ce qui me passe par la tête. Il n’y a aucune limitation, aucune restriction. Il faut tout de même respecter les règles de “safe harbor”, s’assurer que l’on ne viole aucune des conditions. Mais c’est justement ce qui est positif, d’être invité légalement et éthiquement à éprouver des produits.
En tant qu’ingénieur en sécurité, il faut sécuriser les éléments qui sont construits tout autour. On doit bien modéliser les menaces et comprendre la surface d’attaque pour les fonctionnalités et les services, avant même qu’ils ne soient construits. Ça change votre perspective, vous devez voir davantage d’un angle défensif. Et en testant le système, il faut penser comme un attaquant. Mais plus encore, on doit prendre des mesures au plus tôt pour rendre le système plus sûr et résilient, afin que des problèmes similaires ne se reproduisent pas la prochaine fois. J’ai également l’occasion d’écrire des défenses pour mes propres attaques, et de guider les développeurs pour qu’ils ne cafouillent pas, ce qui ajoute à mon apprentissage.
En tant qu’ingénieur en sécurité on doit être des deux côtés de la barrière, là où c’est à sens unique en tant que hunter – mais on a plus d’options et de liberté pour explorer en dehors des clous.
Et quel est le mauvais côté de la chasse aux bugs ?
Je dirais les burnouts. Si vous avez trop d’attentes, ou si vous faites du bug bounty à plein temps. Mais je ne dirais pas que c’est si terrible, ça fait partie du jeu. C’est dans sa nature.
L’incertitude existe, mais elle peut être éliminée au fil du temps, en développant ses propres méthodologies. On passe en quelque sorte un accord avec soi-même sur le fait que ça fait partie du jeu. Ensuite tout va bien. En fin de compte, ça se joue vraiment dans la tête de chacun.
Il y a des jours où l’on ne chasse pas, et on ne sait même pas pourquoi on ne chasse pas. Il faut faire une pause, puis revenir. Il est également important d’avoir différents systèmes à tester pour éviter l’ennui.
En ce qui concerne les programmes de bug bounty eux-mêmes, je dirais le temps de réponse et la communication générale. Les responsables se font du tort en prenant trop de temps pour répondre, et en ne publiant pas de mises à jour régulières. Ce sont ce genre d’expériences qui démotivent les gens à soumettre des rapports.
Quelle est ta méthodologie pour appréhender le bug bounty ?
Je ne suis pas un gros adepte des outils, je fais un travail basique de reconnaissance des applications. Si on me donne une application à tester, je vais simplement l’analyser. Comprendre comment elle fonctionne, comment elle authentifie les utilisateurs. J’ai une approche old-school, j’analyse fonctionnalité par fonctionnalité. Peut-être que je trouverai une douzaine de cas où il est possible de détourner cette fonctionnalité. Et j’en tirerai du plaisir, car c’est là que ma créativité entre en jeu.
Récemment, je me suis consacré aux optimisations. Il y a trop de gens qui chassent dans les mêmes espaces. Il faut être rapide. Admettons que quelqu’un puisse rédiger un rapport en 10 minutes. Est-il possible de le faire en moins de temps ? Pour ce faire, j’ai créé des templates standardisés, portant sur les mêmes failles que celles que je recherche. J’ai aussi écrit des plugins et des règles personnalisées, qui suggèrent des exploits ou des pistes pour tester certains scénarios. Je pense que de telles méthodes font gagner du temps et aident à valider les soumissions.
Pour un scope plus important, l’automatisation et un bon travail de reconnaissance amélioreront vos performances. Il faut aussi expérimenter, et ajouter régulièrement de nouvelles logiques de détection dans son setup.
Y a-t-il un type de vulnérabilité que tu aimes particulièrement chasser ?
Principalement les failles de business logic. Celles qui auront le plus d’impact sur l’entreprise, comme les prises de contrôle de comptes, les défaillances de paiement, les race-conditions. Ensuite, je teste les attaques de type IDOR et les problèmes de contrôle d’accès. Enfin, je teste les problèmes techniques comme les injections, XSS, CSRF, SSRF, en fonction des fonctionnalités disponibles. Ce sont les trois premières catégories que je recherche toujours, car c’est là qu’on obtient un premier résultat. Une fois que je suis en confiance, je cherche des variantes de vulnérabilités similaires.
Je chasse les variantes. Si je trouve un type de bug, j’essaie de trouver où, dans toute l’application, il aurait pu être reproduit, mais d’une manière différente.
Prenons l’exemple d’une application bancaire. Disons que la personne A veut payer la personne B. Si je veux payer la personne B, je devrais pouvoir sélectionner mon compte et le compte de l’autre personne, puis envoyer l’argent.
Mais qu’advient-il si, en tant qu’attaquant, je peux renverser la loi de la transaction ? Puis-je obtenir l’argent du compte de l’utilisateur B en modifiant les paramètres “from” et “to” ? Et si c’est le cas, à quel autre endroit cela peut-il se produire ? Ce pourrait être dans le système de remboursement, où le paramètre ?from= pourrait être celui du compte interne de la banque. De la même manière, vous pouvez tester les fonctionnalités de versement, de contestation de transaction.
La chasse aux variantes vous donnera plus de bugs. Même les grandes entreprises, comme Google ou Facebook, ont adopté cette pratique très tôt. Il est difficile de corriger les occurrences individuelles de vulnérabilités en raison de l’ampleur de leur codebase. On écrit donc une règle de détection pour un cas spécifique, puis on l’exécute dans l’ensemble de la base de code pour trouver le même bug à plusieurs endroits, et les mitiger immédiatement.
Encore une fois, ma première priorité serait les erreurs de business logic, car la recherche ne peut pas être automatisée avec un logiciel. C’est de la pure logique humaine. Vous pouvez utiliser Burp Suite et des outils techniques, et ils trouveront des failles techniques de manière automatique. Mais les bugs logiques ne peuvent être trouvés à l’aide d’aucun outil, il faut avant tout utiliser son cerveau.
En dehors de ça, je cherche à enchaîner les bugs. J’aime enchaîner les petites failles et construire des scénarios plus critiques. Par exemple :
Quel est le bug que tu es le plus fier d’avoir découvert ?
L’une d’entre elles se trouvait dans une plateforme d’échange de crypto-monnaies, où j’ai été en mesure de modifier l’adresse du portefeuille de n’importe quel utilisateur via une attaque IDOR. J’ai ensuite pu l’enchaîner avec CSRF (Cross-Site Request Forgery) de manière à pouvoir initier des paiements, amener quelqu’un à transférer de l’argent. Je dirais que c’était un bug très facile, mais qui a eu un impact énorme. Habituellement, les problèmes de contrôle d’accès et IDOR sont simples, mais quand ils fonctionnent… leur impact est considérable. Finalement, cette plateforme de crypto m’a payé une prime avec des coins à eux, mais je ne sais plus où est le wallet. Je l’ai en quelque sorte perdu… c’était il y a 3 ans.
J’ai également trouvé quelques IDORs dans le Google Play Store, et un autre où j’ai pu télécharger gratuitement un APK payant. Pour ces problèmes, Google m’a accordé une subvention de recherche de vulnérabilité (Vulnerability Research Grant). C’était motivant. Une autre fois, j’ai soumis un rapport de vulnérabilité à une célèbre compagnie aérienne, qui m’a récompensé en me donnant beaucoup de Miles. Maintenant, je peux voyager gratuitement pendant un certain temps, c’est cool !
Tu es originaire d’Inde et tu as soumis des vulnérabilités à des entreprises du monde entier. Constates-tu une différence dans la façon d’aborder le bug bounty, en fonction du pays d’origine des organisations ?
Oui. Cela diffère surtout dans les pays où les économies sont différentes. J’ai constaté que la sécurité est prise au sérieux, quel que soit le niveau des problèmes, dans les pays où la conformité est plus élevée. Disons l’Union européenne, les États-Unis, principalement en Occident, où des lois strictes sur la sécurité des données sont en place.
En Inde, les lois sont plutôt souples par rapport aux pays européens. Nous devons améliorer nos lois en ce qui concerne la posture globale de cybersécurité, mais les choses évoluent. Il y a des discussions en cours sur le projet de loi 2022 sur la protection des données personnelles numériques, ce qui constitue une avancée par rapport aux années précédentes.
Bangalore est considérée comme la Silicon Valley de l’Inde. La majorité des start-ups sont ici, et beaucoup d’entre elles prennent la sécurité au sérieux. Elles lancent leurs bug bounty, et elles font au moins preuve d’une prudence générale en matière de sécurité. Mais nous devons encore parcourir un long chemin. Il faut espérer que les choses s’amélioreront avec les nouvelles lois sur la protection de la vie privée.
Nous avons également beaucoup d’adolescents et de diplômés qui sont maintenant intéressés par la cybersécurité. Ils participent à des CTF ainsi qu’à des bug bounty et des programmes d’apprentissage. On observe également une croissance significative des communautés locales de sécurité, qui aident et guident les nouvelles générations dans ce domaine. Il y a eu une véritable frénésie ici au cours des trois ou quatre dernières années, et je suis convaincu que la tendance va s’accentuer.
Un conseil que tu aimerais donner aux hunters débutants ?
Comprenez les technologies du web. Je pense que le fait d’en savoir plus sur le fonctionnement du web fera de vous un meilleur hacker que quiconque. Comprenez les DNS, les protocoles, les règles des navigateurs Web et, si possible, lisez les RFC pour trouver des surfaces d’attaque cachées.
Apprenez également un langage – PHP, Python, Java. Essayez de développer des applications et des fonctions comme le login et le signup, en partant de zéro. Apprenez comment les données sont stockées dans la base de données, et où elles sont présentées à l’utilisateur. Cela vous donnera une idée de la façon dont les données se propagent concrètement.
Une fois que vous avez développé une application, essayez de la casser. C’est ainsi que je me suis formé avant de me lancer dans le bug bounty. J’ai passé 7 ou 8 mois à me familiariser avec ces choses, et je continue à le faire.
Ensuite, je pense que la pratique de différentes classes de vulnérabilités est importante. Asseyez-vous, expérimentez, combinez deux classes de vulnérabilités et voyez quel avantage vous pouvez en tirer. Prendre des notes est important. Aujourd’hui, je pourrais chasser sur une plateforme et apprendre quelque chose à son sujet. Mais demain, si je me retrouve dans une situation similaire, je ne serai pas capable de m’en souvenir. Mais je pourrai toujours me référer à mes notes.
Alors maintenant, je fais des notes graphiques et des cartes mentales.
- Commencez à prendre des notes, couchez-y les enseignements uniques que vous tirez de chaque chasse ;
- Ne négligez pas les notions de base et revenez souvent sur les concepts lorsque vous en avez besoin ;
- Essayez de penser du point de vue du développeur. Où pourrait-il/elle avoir commis des erreurs ?
- Expérimentez de nouveaux outils et techniques, améliorez votre travail de reconnaissance ;
- Soyez constant, améliorez-vous chaque jour en lisant des blogs, Twitter ou en profitant de la sagesse de vos collègues chercheurs ;
- Faites des pauses, revenez sur le même endpoint avec un esprit neuf si vous ne vous sentez pas productif. Ne forcez pas les choses ;
- Réfléchissez à ce que vous pouvez améliorer. Quel est votre avantage sur les autres ?
- Ne testez pas les systèmes que vous n’êtes pas autorisé ou invité à tester ;
- Et enfin, ne perdez pas espoir. Mes 20 premiers bugs n’ont pas été acceptés avant ma première contribution valide. Il m’a fallu 2-3 mois pour mon premier rapport valide.
Donc c’est important de savoir changer de perspective sur les choses ?
Oui, d’une certaine manière. Lorsque je révise du code, je tiens également compte des différences de comportement, et des connaissances du développeur. C’est une théorie qui n’a rien d’exceptionnel, mais elle fonctionne. Je l’appelle “behavior hunting”, la chasse par le comportement.
Prenons un exemple. Pour un programme antérieur, j’ai regardé sur Github ce que les gens ont fait. Vous voyez vite comment ils écrivent le code. Et avec un peu d’expérience, vous pouvez savoir si une personne est nouvelle dans l’équipe ou non. Ensuite, vous ciblez la personne qui n’écrit pas un code soucieux de la sécurité, la personne qui peut se planter. Il y a 99% de chance qu’elle revienne.
Du coup, j’ai écrit une automatisation autour de ça – “Alerte moi à chaque fois que cette personne participe.” Et j’ai eu une alerte à chaque fois, et mon système a simplement cherché les règles que j’avais écrites auparavant. S’il y avait une erreur, c’est qu’il y avait un bug. C’est là que se trouve votre avantage, là où vous pouvez prendre le dessus. Et puis même les seniors font des erreurs !
En gros, il faut utiliser leur psychologie. Leurs connaissances. Ils peuvent ne pas avoir d’expérience dans l’écriture de code sécurisé, ou de requêtes sécurisées pour éviter les injections SQL. Il s’agit vraiment de renverser leur psychologie. Parfois, vous trouverez aussi des commentaires conflictuels dans le code, comme “veuillez ne pas y toucher” ou “ceci est un code pour exécuter des commandes en toute sécurité” – c’est suffisant pour attirer votre attention.
Comment penses-tu que les équipes internes d’une organisation devraient aborder le bug bounty ?
Les équipes internes testent régulièrement leurs produits et services, mais le bug bounty permet de couvrir les zones d’ombre qu’elles auraient pu manquer. Il est donc tout aussi important pour elles d’allouer des ressources et d’inviter les chercheurs en sécurité à tester leurs systèmes sous différents angles, afin de découvrir les mauvaises surprises plus tôt.
Le camp de l’attaquant est plus détendu. Mais lorsque vous êtes dans l’organisation, comme ingénieur ou consultant par exemple, vous devez penser à la fois de manière offensive et défensive. Je pense qu’il faut se montrer paranoïaque.
L’équipe de sécurité devrait surveiller ses actifs, améliorer constamment ses détections, ses compétences, et tirer des enseignements des intrusions afin d’être mieux préparée la prochaine fois. Elle doit également être au courant des dernières tendances en matière de CVE, et appliquer des correctifs en conséquence pour les bibliothèques obsolètes. La sécurité n’est pas un travail facile, surtout si vous avez une petite équipe.
Ça dépend aussi des priorités et de la culture de l’entreprise.
- Ils doivent avoir les accès, l’équipe et le budget nécessaires pour gérer le bug bounty ;
- Ils devraient consacrer une bonne partie de leur temps à tester le système en question avant de le mettre en production. Il ne faut pas se précipiter. La plupart du temps, les équipes de développement contactent l’équipe de sécurité au dernier moment, ce qui n’est pas une pratique saine ;
- L’équipe de sécurité doit avoir son mot à dire, une sorte de veto pour prendre la meilleure décision possible dans l’intérêt de l’entreprise ;
- Ils doivent être entendus et ne doivent pas être réprimés, car ils sont là pour prévenir avant que les choses ne dégénèrent.
À ton avis, qu’est-ce qui fait la qualité d’un programme de bug bounty ?
En tant qu’ancien responsable de programme moi-même, je pense que les points ci-dessous peuvent être utiles à d’autres :
- La confirmation : Vous devez accuser réception rapidement aux chercheurs après avoir reçu le bug ;
- Communication claire : Que le rapport soit valide ou non, il faut en donner la raison afin que la personne puisse s’améliorer la prochaine fois avant de soumettre le rapport. J’apprécie lorsque la personne en face pose des questions et cherche à obtenir des éclaircissements plutôt que de fermer brusquement un rapport, ou de ne pas laisser de place au dialogue ;
- Montant de la prime : Si le paiement est élevé, cela attirera naturellement plus de personnes vers le programme ;
- Représentation correcte du scope : Ce qui est accepté et ce qui ne l’est pas. Il doit être affiché afin que les chercheurs et les équipes ne perdent pas leur temps ;
- Paiement au triage : Ne les faites pas attendre, si le bug est valide, payez-les au triage ;
- Scope important : Un scope d’actifs plus large à tester sera attractif, comme les domaines wildcard, les applications de bureau, les applications mobiles…
Quelle est la chose que tu aimes le plus chez Yogosha ?
Je dirais qu’il y a de bons programmes, ils répondent et paient à temps. Ce que j’aime le plus, ce sont les invitations régulières, les paiements au triage, les Hunter Survival Games et la facilité à joindre l’équipe. Il n’est pas nécessaire de se battre sur les réseaux sociaux. Vous pouvez simplement vous adresser à l’équipe et ils sont toujours prêts à aider. Ils veulent que vous travailliez. Si quelque chose ne fonctionne pas, ils seront en mesure de vous aider. Dans l’ensemble, mon expérience s’est bien déroulée jusqu’à présent et j’ai hâte de continuer.
Où vois-tu le bug bounty dans le futur, dans 5 ou 10 ans ?
La sécurité sera toujours une nécessité avec la croissance de la technologie, tout comme le bug bounty. J’ai le sentiment qu’il y aura plus de diversité à l’avenir, les gens ne seront pas limités aux API et à la sécurité native, mobile, web, et IOT. Par exemple, le Web3 est arrivé. Qui aurait cru que les gens créeraient leurs propres crypto-monnaies, en faisant des audits Solidity ? De même, la sécurité spatiale semble intéressante avec les récents développements dans le domaine, comme Starlink. Petit à petit, les gens pourraient aussi s’orienter vers la sécurité spatiale. Il existe déjà un programme appelé Hack-A-Sat pour la sécurité des satellites.
La dynamique des tests de sécurité traditionnels a cependant changé. Elle devient plus centrée sur les outils, en raison de la concurrence ou peut-être de la complexité croissante des systèmes. Les hunters doivent construire leurs propres outils et automatismes pour être compétitifs. À l’avenir, nous devons faire des recherches et nous concentrer davantage sur les nouvelles classes de vulnérabilités qui sont encore cachées sous la surface, et que les autres ne connaissent pas encore. Cela nous permettra d’avoir un avantage sur les autres, sinon il sera difficile de survivre dans ce domaine.
De plus, nous verrons davantage de travailleurs indépendants sur cette scène. Des gens qui ne veulent pas être dans une configuration professionnelle traditionnelle, et qui veulent juste hacker sans obligation. À l’avenir, je pense que l’IA jouera un rôle majeur pour nous aider ou nous remplacer dans la sécurité. Reste à voir comment les gens vont progressivement évoluer pour surmonter la chose…
Quels sont tes loisirs ?
Quand je ne travaille pas, j’aime écouter et suivre des artistes musicaux émergents, surtout dans le style hip-hop indien et Coke Studio. Je vais parfois au ciné, et j’essaie de produire des beats de temps à autre.
Vishwaraj est sur Twitter et Linkedin. Il écrit aussi ses réflexions et ses découvertes sur son blog, et partage parfois ses enseignements sur sa chaîne Youtube.
