Fuite de données chez le Français Spliiit : la communication a limité les dégâts

Le 5 juillet, la startup française Spliiit a subi une cyberattaque. Derrière ce mot, l’imaginaire collectif projette une manœuvre sophistiquée, lancée par un cybercriminel motivé, peut-être basé à l’étranger. Mais sous le sweat à capuche imaginaire se trouvait « Slvsher », un hacker anonyme, étonnement bavard, dont nous avons recueilli le témoignage. Un francophone, qui discute sur le ton de la blague, et n’opère qu’en solo, pour « se faire un peu de sous ».

Il a profité d’une variante d’une faille de sécurité bien connue de Laravel, le logiciel que Spliiit a utilisé pour construire son application web. Il a réussi à en tirer une base de données avec l’email, le nom et parfois le numéro de téléphone de plus de 200 000 clients. Puis il s’est servi des accès de la startup pour envoyer un phishing à près d’un quart des clients.

Il est plus facile d’attaque un système que de le protéger. // Source : Louise Audry pour Numerama

Unique, l’incident de Spliiit ? Pas vraiment. On pourrait même le qualifier de « banal », si l’attaquant ne s’était pas fait connaître. Même les grands groupes subissent des incidents dus à des failles de sécurité très simples, et les startups y sont encore plus exposées, avec leurs effectifs techniques généralement plus modestes. « Techniquement nous n’avons pas été à la hauteur », concède tout de même Jonathan Lalinec, CEO de l’entreprise, à Cyberguerre.

Là où Spliiit s’est en revanche démarqué, c’est dans sa communication. À chaque nouvel élément concret sur l’incident, l’entreprise a communiqué de façon transparente.

• D’abord, elle a averti sur le phishing envoyé par l’intrus, à la fois par email, sur son site et sur ses réseaux sociaux, en exposant l’exemple précis.
• Puis elle a mis en garde individuellement chaque personne qui avait cliqué sur le lien du phishing — alors que techniquement, l’erreur des victimes n’était plus de sa responsabilité.
• Pour finir, dans un email détaillé sur les conclusions de l’enquête interne, Jonathan Lalinec annonçait à Cyberguerre le 8 juillet : « Nous allons désormais préparer un mail à toute notre base, cette fois afin d’expliquer en détail ce qu’il s’est passé. »

Cet exercice de transparence, loin d’être une pratique commune, a permis à ses clients de s’adapter à la situation.

Les entreprises à la fois victimes et responsables

Bien que chaque jour, des dizaines d’entreprises — à commencer par les plus grandes —  soient victimes d’incident de sécurité, l’annoncer à ses clients revient à admettre une faute. Bon nombre de dirigeants voient la situation comme un risque supplémentaire de perdre des clients, et préfèrent malheureusement communiquer le moins possible sur les événements. La position des sociétés dans ce type d’affaires n’est, il est vrai, pas des plus plaisantes.

D’un côté l’entreprise est la première victime de l’attaque : elle a subi l’intrusion d’un tiers sur son infrastructure, et celui-ci a pu lui voler des informations ou encore causer des dégâts. De l’autre, en tant que responsable du traitement de données, l’entreprise est responsable de la fuite à l’égard de la loi. Elle peut être sanctionnée par les autorités, si elle n’a pas déployé un minimum de mesures nécessaires pour protéger les données.

Pour les organisations concernées, ce double statut victime-responsable s’avère parfois difficile à gérer. C’est pourquoi beaucoup d’entreprises insistent sur leur statut de victime, n’hésitant pas à préciser que l’attaque était « sophistiquée » ou « de grande ampleur » sans que ces affirmations soient appuyées par la réalité technique. Plus elles insistent sur leur position de victime, plus elles espèrent cacher leur position de responsable, qui a pu faire une erreur grossière dans sa sécurité.

Des fuites à deux vitesses

Reste que la loi, notamment le fameux RGPD, contraint les entreprises à communiquer. D’abord, tout incident de sécurité qui affecte des données personnelles doit faire l’objet d’une déclaration à la Cnil, le gendarme français des données, dans les 72 heures qui suivent sa découverte. Cette déclaration peut être complétée par la suite avec des précisions tirées de l’éventuelle enquête.

Puis, dans les 72 heures suivantes, si le risque représenté par la fuite pour les personnes concernées peut être considéré comme « élevé », alors l’entreprise devra prévenir individuellement chaque victime de la fuite. Cette seconde étape est cependant rarement nécessaire. Dans le cas de Spliiit par exemple, la fuite ne contient « que » des adresses email, des noms et des numéros de téléphone, autant d’informations insuffisantes pour remplir le critère de dangerosité. Ces données sont déjà accessibles sur les Pages Jaunes ou sur des réseaux sociaux comme LinkedIn, qui les exposent aux yeux de tous.

On ne peut pourtant pas les qualifier d’inutiles ou inoffensives : elles peuvent alimenter un phishing ou des campagnes de spam, a fortiori lorsqu’elles sont amassées en grand nombre. En revanche, elles ne peuvent pas causer un dommage immédiat à elles seules, au contraire des données bancaires ou des mots de passe. Dans l’affaire Spliiit, le hacker n’a pas eu accès au « coffre-fort », le serveur séparé qui contient les données bancaires des clients, et il n’a pas non plus obtenu les mots de passe des clients. Au final, la startup a réussi à protéger l’essentiel.

Plus les entreprises seront transparentes, moins les clients seront à risque

La communication de Spliiit pourrait avoir permis à certaines personnes qui ont donné leurs informations bancaires dans le phishing de ne pas perdre d’argent. Pour cause : une fois l’erreur commise, un contre-la-montre s’engage. Slvsher comptait vendre les données des CB récoltées sur un petit magasin en ligne. Si les victimes ne se rendent pas compte qu’elles ont donné leurs informations bancaires, au lieu de les entrer sur le site officiel, les acheteurs ont la possibilité de les exploiter pour effectuer des achats de plusieurs dizaines, voire centaines d’euros.

Spliiit a très vite écrit un article pour décortiquer ce phishing. // Source : Capture d’écran Numerama

Mais grâce à la communication de Spliiit, il est probable qu’une partie des victimes aient eu le temps de faire opposition sur leur carte bancaire, avant de subir un préjudice. « Nous avons également pris contact avec notre assureur responsabilité civile professionnelle, qui est capable de couvrir les clients ayant eu des utilisations abusives de leurs cartes bancaires », ajoute Jonatahn Lalinec.

De même, si les clients savent que leurs email et téléphone ont fuité, ils seront plus méfiants face aux éventuels phishings qu’ils recevront. Bref : plus les entreprises seront sincères et rapides à communiquer, plus les individus pourront se protéger par leurs propres moyens.

Plus les entreprises communiqueront, moins les autres entreprises seront à risque

Spliiit ne se contente pas de communiquer sur les conséquences de l’attaque, elle nous a également expliqué son déroulé. L’incident vient d’une mauvaise configuration de Laravel, comme nous le suggérions dans notre article initial sur l’incident : les équipes de Spliiit ont laissé l’outil de débug ouvert, et le hacker a pu s’en servir. Mais l’attaque s’avère être une variante plus complexe, d’après le CEO de la startup : « en cherchant, il s’avère que la barre de debug était présente sur staging [l’environnement de travail des développeurs, à différencier de l’environnement de production, celui observé par les clients, ndlr], qui est sur une adresse sécurisée. Nous avons donc totalement désactivé staging afin de le sécuriser. » Autrement dit, l’attaquant ne se serait pas contenté de scanner le site en production pour découvrir la faille, comme on pouvait le penser initialement.

Une méthode étrange

De son côté, le hacker Slvsher s’emporte sur Twitter, dans une discussion avec un autre utilisateur : « C’est ma propre vulnérabilité, j’ai totalement ciblé le site de Spliiit et je n’ai utilisé aucun outil fait par d’autres personnes (…) j’ai développé mes propres scripts. » Dans le jargon, le hacker prétend avoir une faille « 0-day » sur Laravel, c’est-à-dire une faille qui n’a pas encore de correctif, et donc qui rend tout système Laravel vulnérable. « Ces déclarations ne sont pas convaincantes. Si un hacker découvre une 0day Laravel, il l’utilisera pour viser bien plus gros que Spliiit », estime l’expert Adrien Jeanneau, que Cyberguerre a consulté. Reste que la méthode employée par Slvsher n’est pas aussi évidente qu’elle le paraissait. Quelle que soit la faille utilisée par le hacker, les informations communiquées par Spliiit pourraient permettre à d’autres entreprises de s’en prémunir.

De son côté, Jonathan Lalinec affirme prendre des mesures pour qu’un incident ne se reproduise plus : « Nous allons faire appel à Yes We Hack afin de tester de nouveau nos services. » Ce service français de bug bounty permet de faire tester la sécurité de son site par des chercheurs indépendants, et les récompense d’une prime selon le type de faille trouvée.

Quel est le meilleur Gestionnaire de mots de passe ? Quel est le meilleur gestionnaire de mots de passe en 2024 ? Retrouvez nos tests complets