Alain Tiemblo - Bug Bounty - Vulnerability Coordination

Depuis septembre 2017, BlaBlaCar propose à un nombre d’experts en sécurité triés sur le volet, un
programme de Bug Bounty privé afin de renforcer la sécurité opérationnelle de sa plateforme. Accessible
jusqu’alors uniquement sur invitation via BountyFactory.io, la plateforme de bug bounty de YesWeHack, ce programme a permis à BlaBlaCar de rester proactif sur la cybersécurité de ses services.

Entretien avec Alain Tiemblo Web Security Lead Engineer – @BlaBlaCar – manager du programme de Bug Bounty.

Jeudi 19 avril le programme de BlaBlaCar est public

Quel est votre rôle au sein de BlaBlaCar ?

Je suis un profil développeur backend, aujourd’hui chapeautant la sécurité applicative. Lorsque je suis arrivé à BlaBlaCar, je m’occupais de la performance et la sécurité de la plateforme. Mi 2015 début 2016, nos besoins en sécurité opérationnelle ont augmenté de manière significative notamment à la suite de nos grosses levées de fonds qui ont suscité quelques convoitises. J’ai alors pris le lead d’une petite équipe afin de mitiger ces attaques, et auditer / consolider la plateforme.

Quelle est votre démarche en termes de sécurité et notamment de divulgation coordonnée de vulnérabilités?

Nous avons pendant longtemps gardé la sécurité applicative en interne. Auparavant, nous faisions appel à des audits classiques menés par diverses entreprises, par plusieurs applications de pentest, en utilisant des outils d’analyses statiques, etc. Je pense que ça a permis de dégrossir beaucoup de petites choses qui auraient été détectées par des chasseurs de failles.

Par ailleurs, on a reçu quelques messages de trolls sur Twitter signalant des failles sans préavis et sans aucun détails… On a aussi quelques Emails via le support client concernant des potentielles failles de sécurité, mais rien n’était révélé par ces contacts, ils souhaitaient d’abord être payés et ce, sans preuve de l’existence d’une faille, donc il était impossible pour nous de les rémunérer.

Sur les derniers mois, ces mails étaient de plus en plus nombreux alors nous avons pris la décision de franchir le pas du Bug Bounty.

Par ailleurs, nous avons intégré également le fameux security.txt sur notre site pour orienter les chasseurs de bugs vers la plateforme BountyFactory car le Bug Bounty est une bonne façon d’inciter la coordination de vulnérabilités.

Quels critères vous ont guidé pour choisir BountyFactory.io ?

Nous avons fait un comparatif des différentes plateformes de Bug Bounty en Europe et nous avons préféré prendre une entreprise française principalement pour des raisons de régulations. Le second critère était le nombre de hunters actifs sur la plateforme, ça ne sert pas à grand-chose de mettre de l’argent et de l’énergie dans un programme s’il n’y a pas une masse critique de hunters pour chercher efficacement des failles.

Qu’avez-vous appris de la phase privée de votre programme ?

Dès le lancement d’un programme sur BountyFactory, cela génère un grand nombre de rapports dans les premiers jours, non pas parce que le site est troué de partout, mais parce qu’il nous a fallu du temps pour décrire au mieux notre programme.
Il y a certains standards de sécurité qui ne sont pas compatibles avec notre produit, ou il y en a d’autres qui sont techniquement trop coûteux à mettre en place par rapport à leur valeur ajoutée.
Bref, la première chose qu’on a apprise c’est l’importance de bien définir le scope c’est à dire le périmètre de jeu des chasseurs de failles.

Dans le lot, il y avait tout de même de vraies failles, vraiment critiques qui ont été rapportées, et elles nous ont convaincus de la pertinence et de l’efficience du service de YesWeHack.

Après la première semaine, le nombre de failles diminue grandement, mais celles qui sont remontées sont plus intéressantes, car les hunters rentrent dans notre produit et font des rapports vraiment spécifiques à notre métier.

Après le premier mois, c’était plus calme. Ça nous a laissé le temps de gérer le flow. Et dès que tout a été corrigé, on a rajouté des hunters.

Ajouter des hunters c’est à peu près pareil que lorsqu’on arrive sur la plateforme, il y a un sursaut de rapports liés a des standards, de bonnes pratiques, de scans automatiques, etc. ; puis on s’aperçoit que les rapports sont plus spécifiques au produit, plus pertinents et c’est de nouveau l’accalmie.

Vous allez bientôt passer en public, avez-vous préparé cette phase et quelles sont vos attentes ?

Nous n’avons rien préparé spécifiquement et la phase privée nous a bien rodés. On s’attend à avoir beaucoup plus de rapports et on espère avoir un faible ratio de positifs sur les premières semaines.

En terme de communication, nous avons été vraiment satisfaits de la qualité des échanges avec les chasseurs de failles pendant la phase privée et tout logiquement on s’attend à cette même qualité de service en passant en public.

Et bien entendu, nous comptons sur l’expertise et la réactivité de l’équipe YesWeHack pour aborder le plus sereinement cette étape.

À l’instar d’OVH, votre programme est-il voué à rester public de manière à répondre de manière opérationnelle et en continu aux évolutions de vos outils ?

Oui, nous souhaitons ouvrir notre programme au public de manière continue, dans la mesure du possible. Si par exemple nous avons trop de rapports à traiter, nous le mettrons peut-être à nouveau en privé afin de gérer le flow et éviter les rapports en double. Les hunters travaillent très dur pour trouver des failles, il est donc impératif d’éviter de se faire déborder.

Du côté de votre team , Devs, Devsecops, avez-vous noté une stimulation saine dans le cadre de ce programme ?

Nous sommes une petite équipe technique dans une entreprise avec de grandes ambitions. Il y a donc beaucoup de travail. Nos journées ne comportant que 24 heures, il a été parfois compliqué de faire comprendre à nos manager la nécessité d’intégrer des corrections de bugs qui apparaissent sans grande gravité, certains peuvent considérer cela comme une corvée. En revanche du point de vue de l’attaquant qui utilise un chaînage habile, voire malin, une vulnérabilité semblant bénigne peut s’avérer critique et c’est là que certains Devs comme chercheurs y trouvent un intérêt et peuvent alors monter en compétences !

La stimulation est saine dès lors où les Devs s’aperçoivent clairement d’un potentiel préjudice. Mon travail est de leur faire prendre conscience que le diable est dans le détail : tout le monde doit être conscient de l’enjeu et doit jouer le jeu. Nous attendons avec intérêt les prochaines failles critiques, car ce sont elles qui nous stimulent le plus.

En termes de communication externe, allez-vous communiquer sur votre programme ?

Non, même si en interne nous avons largement communiqué au sujet du bug bounty pour répondre aux questions du support qui recevait pas mal de tickets contenant “bug bounty” ou “hunter”, le marketing et la communication n’envisagent pas pour l’instant de l’utiliser comme argument de vente.

Notre communauté nous fait déjà confiance, et nous devons préserver leur confiance en leur livrant une plateforme sûre. Toute notre communication se concentre sur le partage et le mieux vivre ensemble.


Rendez-Vous à la Devoxx France

Jeudi 19 avril de 11:15 à 12:00 dans le cadre du salon Devoxx France : assistez à l’annonce de l’ouverture au public du programme de Bug Bounty de Blablacar avec Guillaume Vassault-Houlière (CEO – YesWehack ) et Alain Tiemblo ( Web Security Lead Engineer – BlaBlaCar ) pour un talk de 45 minutes sur la Divulgation coordonnée de vulnérabilités & le bug bounty.

In Bug Bounty, Disclosure, Privacy by Design, Security by design, Vulnerability Coordination