Quand la faille d’un fournisseur devient la vôtre : les enseignements de l’incident Klue

Il y a une vérité dérangeante à laquelle toute équipe de sécurité finit par être confrontée : la faille qui vous fait le plus de tort ne se produit peut-être pas chez vous. Vous pouvez corriger votre code, renouveler régulièrement vos secrets et protéger étroitement votre périmètre, et pourtant vous réveiller face à un incident causé par un système qui ne vous appartient pas.

C’est ce qui s’est passé lors de l’incident impliquant Klue, une plateforme de veille concurrentielle utilisée par de nombreuses entreprises. D’après les informations rendues publiques, un acteur malveillant a compromis le système backend de Klue, puis s’est servi de cet accès pour atteindre les systèmes connectés de ses clients, notamment leurs environnements Salesforce intégrés à la plateforme. D’autres fournisseurs de solutions de sécurité, comme Recorded Future, Tanium, Huntress et Jamf, ont également été touchés et ont publié des informations à ce sujet. Il vaut la peine de s’arrêter sur les faits, car le déroulement de l’incident illustre clairement comment les écosystèmes modernes de logiciels en tant que service (SaaS) peuvent être compromis.

Anatomie de l’incident

Selon les informations publiées à ce jour, l’enchaînement des faits est à peu près le suivant :

L’accès initial à Klue s’est fait au moyen d’un ancien identifiant, qui aurait été créé à un moment donné pour un prototype d’intégration ensuite abandonné, mais qui n’a jamais été désactivé. Cet accès a perduré bien après la fin du projet pour lequel il avait été créé. Un acteur malveillant l’a découvert, et il fonctionnait toujours.

À partir de là, l’attaquant a atteint la partie de l’infrastructure de Klue qui relie la plateforme aux outils de ses clients. Ces connexions reposent sur des jetons OAuth, qui permettent à Klue de lire et de modifier des données dans des systèmes comme Salesforce au nom de ses clients. L’attaquant a injecté du code conçu pour récupérer ces jetons. Une fois en leur possession, il n’avait plus besoin de s’introduire chez chaque client individuellement. Il pouvait s’authentifier en tant que compte de service découvert, à l’aide du secret intégré, interroger directement les données de gestion de la relation client (CRM) de chaque client, puis les exfiltrer. Des tentatives d’extorsion ont suivi.

En faisant abstraction des détails, on retrouve un schéma bien connu : un maillon faible, des clés empruntées et un périmètre d’impact qui s’étend à tous les acteurs connectés en aval. La compromission d’une seule organisation ne s’est pas limitée à celle-ci. Elle s’est propagée.

À propos de Snyk

Par souci de transparence, une exigence que nous avons envers tous les fournisseurs, nous tenons à le dire clairement : Snyk fait partie des organisations touchées par l’incident Klue. D’après notre enquête, et à notre connaissance à ce jour, l’impact s’est principalement limité aux champs de données métier des environnements Salesforce. Il s’agit notamment des coordonnées professionnelles des clients, ainsi que des titres et descriptions d’un sous-ensemble limité de demandes d’assistance client. Le corps ou le contenu de ces demandes n’a pas été concerné, et les produits Snyk n’ont pas été touchés. Notre capacité à servir nos clients n’a pas été affectée.

Dès que nous en avons été informés, nous avons désactivé l’intégration de Klue dans Salesforce, lancé notre propre enquête et contacté les interlocuteurs concernés. Pour consulter l’état actuel et les informations les plus récentes, rendez-vous sur status.snyk.io ou dans le Snyk Trust Center. Nous tiendrons ces deux pages à jour au fur et à mesure de notre enquête.

S’il y a une chose à retenir de cet incident, au-delà de notre propre situation, c’est qu’il faut vérifier les clés que vous avez confiées à d’autres — et celles dont vous avez oublié l’existence.