Et si vous récompensiez les hackers qui trouvent vos failles de sécurité?

Ludwine : Bonjour à toutes et à tous ! Je suis Ludwine et vous écoutez le podcast Human Coders. C’est Julien Cretel qui se retrouve cette semaine à notre micro pour nous parler de sécurité. La sécurité est un sujet assez vaste et dans cet épisode, on a échangé sur un terme qui m'était jusque-là inconnu, mais que peut-être certains ou certaines connaissent : la divulgation responsable. Alors, à quoi ça sert de mettre en place une politique de divulgation responsable ? Pourquoi est-il important d'en avoir une en tant qu'entreprise ? Quel est le lien entre la divulgation responsable et les hackers ? Oui, parce qu'avec Julien, on a aussi parlé des hackers et des programmes de bug bounty. Ça fait beaucoup de mots-clés, mais en bref, si vous voulez en savoir plus sur les failles de sécurité, comment en trouver et comment s'en prémunir, restez avec nous. Très bonne écoute !

Ludwine : Bonjour Julien.

Julien : Salut Ludwine.

Ludwine : Est-ce que tu pourrais te présenter, s'il te plaît ?

Julien : Je suis Julien Cretel. Ça fait environ un an que je travaille en tant que développeur indépendant. J'ai plusieurs activités : je fais du développement en freelance, je donne des formations sur le langage Go et ma troisième activité, c'est la sécurité informatique. Je fais des audits de sécurité pour des entreprises.

Ludwine : On s'est contactés parce qu'on voulait parler de sécurité. Qu'est-ce que tu fais exactement dans ce domaine ? C’est assez large.

Julien : Oui, c'est large. Ça dépend. Des clients me contactent en me disant : "On a du code, on a eu des remontées et on sait qu'il y a des problèmes de sécurité. Est-ce que tu peux jeter un coup d'œil et nous dire ce qu'il en est ? Est-ce qu'il vaut mieux tout réécrire ? Est-ce que ça peut être corrigé ? En combien de temps ? Est-ce que tu veux le corriger toi-même ?". D'un autre côté, j'ai des entreprises qui me contactent car elles savent que je m'intéresse à la sécurité et que j'aime trouver des bugs. Elles me disent : "Est-ce que tu peux essayer de t'introduire dans notre système ? Si tu trouves des failles, remonte-les nous et on te paie selon un certain barème".

La chasse aux failles de sécurité et le bug bounty

Ludwine : Tu es en quelque sorte un chasseur de failles de sécurité ?

Julien : C'est ça. Pour s'assurer que leurs systèmes sont bien sécurisés, les entreprises ont différentes stratégies. Certaines font simplement confiance à leurs développeurs et ne se préoccupent pas de la sécurité au-delà de ça. D'autres contactent des sociétés spécialisées et demandent des tests d'intrusion tous les trimestres.

Au-delà de ça, les entreprises peuvent mettre en avant ce qu'on appelle une "politique de divulgation responsable". C'est un nom un peu compliqué, mais c'est simplement une procédure qui s'adresse à n'importe qui et qui détaille comment remonter une faille de sécurité. Par exemple, Twitter peut dire : "On sait qu'on n'est pas parfaits. Si vous tombez sur quelque chose d'intéressant, voici comment nous contacter, nous donner les détails sur la nature de la faille et vos suggestions pour y remédier". Ils s'engagent à revenir vers vous sous un certain délai et éventuellement à donner une récompense. Quand on commence à offrir des récompenses, on passe sur ce qu'on appelle le "bug bounty hunting".

Ludwine : Si je comprends bien, des entreprises peuvent avoir une page dédiée qui détaille le procédé à suivre si quelqu'un trouve une faille ?

Julien : Exactement. Jusqu'à maintenant, ce n'était pas une pratique très courante. Les entreprises avaient tendance à dire : "Non, on est invulnérables". Mais de plus en plus, elles se rendent compte qu'elles ont intérêt à mettre leur arrogance de côté et à demander au public de remonter les problèmes. Cette politique de divulgation responsable prend la forme d'une page sur leur site qui explique comment les contacter.

Ludwine : Est-ce que tu sais si c'est plus développé dans certains pays que d'autres ? Comment se situe la France ?

Julien : De mon point de vue, c'est aux États-Unis que c'est le plus développé. En France, ça commence, mais les entreprises restent un peu frileuses. Elles ont encore peur d'inviter les gens à les "attaquer". Il y a un conflit entre présenter une façade d'invulnérabilité et être réaliste en reconnaissant qu'on ne l'est pas. Ce qui est intéressant, c'est que même des boîtes de sécurité s'y mettent. Elles reconnaissent que malgré leur expertise, elles font aussi des erreurs.

La communauté des hackers éthiques

Ludwine : Existe-t-il des communautés derrière cette notion de divulgation responsable ? Des développeurs ou des hackers qui se réunissent pour partager des bonnes pratiques ?

Julien : Oui, il y a une communauté très forte, notamment sur Twitter ou IRC. Les gens écrivent des blogs pour expliquer comment ils ont trouvé telle faille, comment ils ont débloqué une situation... Ils partagent leurs astuces et leurs outils. Il y a aussi des événements physiques partout dans le monde, des conférences axées sur la sécurité ou le hacking, comme Hack in Paris.

Ludwine : Comment appelle-t-on ces personnes ? Les "gentils hackers" ?

Julien : On parle de "White Hats" (chapeaux blancs), des gens qui veulent faire le bien. On utilise aussi le terme de "hacker éthique". Ce sont des gens qui vous attaquent, mais en gardant un sens éthique : ils font des remontées au lieu d'exploiter les failles. Le but est de remonter l'information à l'entreprise pour que les utilisateurs du système soient mieux sécurisés.

Ludwine : Tu as mentionné le mot "bounty".

Julien : Oui, le "bug bounty". C'est la prime au bug de sécurité. C'est la récompense qu'un chercheur en sécurité va toucher lorsqu'il trouve une faille et la remonte à l'entreprise, selon un barème établi à l'avance. Certaines boîtes mettent en place ce système de récompense, mais ce n'est pas systématique. Une entreprise peut avoir une politique de divulgation responsable sans pour autant s'engager à verser une prime. Le système de prime, c'est l'étape d'après.

Exemples de failles de sécurité

Ludwine : Est-ce que tu as des exemples récents de failles que tu as trouvées ?

Julien : Je m'y suis mis relativement récemment, donc je suis encore un "petit joueur" par rapport à certains, mais on apprend tous les jours. Je participe notamment à des programmes privés où l'on est invité sur une liste restreinte pour hacker un système. Récemment, j'ai trouvé quelque chose d'intéressant qu'on appelle un SSRF (Server Side Request Forgery). En gros, on force un serveur à lancer une requête vers un autre serveur.

Dans ce cas précis, le serveur que j'attaquais devait envoyer une requête à un serveur bien précis. J'ai réussi à détourner le truc pour qu'il envoie une requête vers un serveur que je contrôlais. En inspectant les en-têtes de la requête, j'ai vu des données sensibles : une clé API qui était censée appeler un service tiers. Je pouvais donc utiliser leur clé API pour mes propres fins.

Ludwine : Quand tu contactes les entreprises, sont-elles toujours contentes ? Quelle est leur réaction ?

Julien : La réaction la plus courante, c'est l'absence de réponse. Et a priori, d'après mes tests ultérieurs, la faille n'est souvent même pas corrigée. C'est surtout vrai pour les boîtes qui n'ont aucune politique de divulgation responsable.

Ludwine : C’est peut-être parce que tu ne contactes pas le bon service ?

Julien : Exactement. On tombe sur une adresse email générique du genre "[email protected]" et on sait que c'est un trou noir. Une autre tactique est de contacter le support technique, mais ils ont un script et ça ne rentre pas dans leurs cases. D'où l'intérêt pour une entreprise d'avoir une politique claire pour guider les gens qui ont une bonne intention.

Le standard Security.txt

Ludwine : Il existe donc des standards pour ça ?

Julien : Oui, il existe une proposition de standard pour trouver ces politiques plus facilement : le fichier security.txt. L'idée est de placer la politique de divulgation responsable sous un chemin précis à la racine du domaine. Comme ça, les hackers savent exactement où chercher. Si tu vas sur facebook.com/.well-known/security.txt, tu trouveras les instructions. Google le fait aussi. On y voit par exemple des liens vers leurs programmes de récompenses. Avoir une standardisation facilite énormément le travail des hackers éthiques.

Ludwine : Tu disais que tu participais à des programmes privés. Comment ça se passe ?

Julien : Soit l'entreprise gère ça toute seule, soit elle fait appel à une plateforme spécialisée dans le bug bounty. Les deux plus connues à l'international sont Bugcrowd et HackerOne. Il y en a une aussi qui se spécialise dans les bug bounties privés, c'est Yogosha, qui est française. Ces plateformes invitent des chercheurs à trouver des failles, s'occupent de trier les rapports et de filtrer ce qui n'est pas de bonne qualité. Ça décharge l'entreprise de tout ce fardeau administratif.

Ludwine : C’est limité dans le temps ?

Julien : Ça peut l'être (par exemple une opération de deux semaines), mais ça peut aussi être en continu. C'est ça qui est intéressant. Traditionnellement, les tests d'intrusion se faisaient de manière ponctuelle tous les trimestres. Là, on se pose la question de la sécurité de manière continue. Le périmètre peut aussi varier : au début, on autorise l'attaque sur un seul domaine, puis on l'étend au fur et à mesure.

Comment se lancer dans la sécurité informatique ?

Ludwine : Quels conseils donnerais-tu à quelqu'un qui veut se lancer ?

Julien : La première chose, c'est qu'il n'y a pas besoin d'être déjà un expert en développement. Du moment qu'on est curieux et qu'on aime chercher, on peut réussir. Il y a énormément de ressources sur Internet ou dans des livres pour apprendre à chercher et exploiter des failles. On peut commencer petit, sur des failles qui n'ont pas forcément un gros impact, pour comprendre le fonctionnement.

Pour moi, m'intéresser à la sécurité a fait de moi un meilleur développeur. J'ai moins tendance à introduire des failles moi-même. Quand j'écris du code, je me mets dans la peau d'un adversaire. Si je récupère une donnée utilisateur, est-ce que je lui fais vraiment confiance ? Est-ce que je ne devrais pas l'assainir avant de l'afficher ? Avoir une conscience "sécurité" permet d'écrire du code plus robuste dès le départ.

Ludwine : Et concernant les récompenses ? C'est de quel ordre ?

Julien : Ça varie énormément. Un grand groupe télécom français m'avait récompensé avec un smartphone dernier cri. Quand c'est de l'argent, ça peut être en euros, en dollars ou en cryptomonnaies. Le montant dépend de l'impact de la faille. Chez Starbucks, par exemple, si tu trouves une faille de type "subdomain takeover" (prise de contrôle d'un sous-domaine), ils paient 2 000 dollars. Ça peut monter à plusieurs dizaines de milliers de dollars pour des failles critiques. Certains en font même leur métier à plein temps.

Ludwine : Peux-tu nous citer d'autres types de failles classiques ?

Julien : On voit de moins en moins d'injections SQL, mais ça arrive encore. C'est quand un utilisateur arrive à modifier la structure d'une requête SQL effectuée par le serveur pour extraire des données sensibles. Il y a aussi le XSS (Cross-Site Scripting) où l'on arrive à injecter son propre code (HTML ou JavaScript) qui s'exécutera dans le navigateur des autres utilisateurs. Ça permet par exemple de récupérer des cookies de session. L'organisation OWASP est très connue pour son "Top 10" des vulnérabilités web les plus critiques. C'est une excellente base pour commencer.

Les risques légaux et les "Gray Hats"

Ludwine : Tu parlais des "White Hats", mais j'imagine qu'il y a aussi des communautés moins éthiques qui sont ravies de trouver ces failles ?

Julien : Bien sûr. Il y a aussi les "Gray Hats" (chapeaux gris). Ils sont entre les deux. Ça dépend de la période, de leur humeur... Si un hacker trouve une faille sur un système qui ne propose pas de récompense, il peut être tenté de revendre cette faille au plus offrant ou à une boîte privée qui l'exploitera. Il existe tout un écosystème autour du rachat de vulnérabilités.

Ludwine : Est-ce qu'il y a une réglementation ? Quelqu'un qui trouve une faille peut-il être inquiété par la justice ?

Julien : Tu as tout à fait raison. Des personnes avec de bonnes intentions ont déjà eu des problèmes après avoir remonté des failles. Il y a l'exemple d'un hacker français, Bluhtot, qui avait trouvé des documents sensibles indexés sur Google. Pour prouver le problème, il les avait téléchargés. L'entreprise l'a attaqué en justice pour ça. Un autre cas, Alberto Hill en Uruguay, a fini en prison après avoir signalé une faille parce qu'entre-temps quelqu'un d'autre s'était introduit dans le système et la police a cru que c'était lui. C'est pour ça qu'avoir une politique de divulgation responsable est crucial : l'entreprise s'engage à ne pas poursuivre le chercheur s'il respecte les règles du jeu et le périmètre défini.

Ludwine : En France, c'est un peu un vide juridique ?

Julien : Ce n'est pas vraiment encadré. D'où l'intérêt de rejoindre des plateformes qui fixent un cadre légal. En général, la règle est de ne pas partager les détails de la faille avant qu'elle soit corrigée. Après, certaines entreprises autorisent la publication d'un article de blog, d'autres non. C'est du cas par cas.

Ludwine : Est-ce qu'il y a des collectifs en France qui essaient de faire bouger les choses ?

Julien : À mon avis, une association comme La Quadrature du Net doit être active sur ce genre de sujets, mais c'est à vérifier.

Ludwine : Merci Julien d'avoir partagé tout ça avec nous. Pour finir, as-tu un dernier message ?

Julien : Pour ceux qui veulent se lancer : si vous comprenez l'anglais, lisez les ressources de l'OWASP. Commencez par des choses simples. On est toujours au pied de la montagne en termes de sécurité, on apprend tous les jours. Pour les boîtes : ça ne coûte pas grand-chose de mettre une page sur votre site pour dire que vous n'êtes pas infaillibles et expliquer comment vous contacter. Peu importe la taille de votre structure, dès que vous avez une présence en ligne, vous avez intérêt à avoir au moins une politique de divulgation responsable.

Ludwine : Merci encore Julien pour cet échange très riche. J'espère que cet épisode vous a plu et qu'il vous donnera envie de creuser le sujet. Si vous voulez retrouver tous les liens cités, rendez-vous sur notre blog : blog.humancoders.com. Pour écouter les autres épisodes, c'est sur SoundCloud ou sur notre page Podcast. N'hésitez pas à nous envoyer vos commentaires et suggestions. Nous sommes aussi à la recherche de nouveaux invités, alors pourquoi pas vous ? Si vous avez un sujet à partager, n'hésitez pas à me contacter. À bientôt !