Sécurité : Netflix, Uber, Tesla, Apple, piratées et vulnérables ? Notre éclairage pour comprendre la situation

Le chercheur en sécurité Alex Birsan a pu « pirater » les chaînes d’approvisionnement de 35 grandes sociétés mondiales, soulevant de nombreuses questions sur les conséquences potentiellement ravageuses de cette action. En revenant sur l'affaire avec trois experts en cybersécurité, Jérôme Thémée, David Bizeul et Fred Raynal, nous allons voir que la situation, bien que problématique, ne doit pas être source de panique pour le grand public.

Dans un article publié sur Medium, le chercheur en sécurité Alex Birsan a dévoilé, il y a quelques jours, comment il est parvenu à pirater Apple, Microsoft, PayPal, Tesla, Uber, Shopify, Yelp, Netflix, et des dizaines d'autres grandes entreprises mondiales, 35 au total, le tout par le biais de la chaîne d'approvisionnement utilisée pour concevoir et mettre à jour leurs différentes applications.

Fort heureusement, il ne s’agit pas d’un piratage « malveillant », bien au contraire. Le spécialiste a agi avec l’assentiment des entreprises concernées, en sa qualité de hacker éthique, dans le cadre d'un bug bounty qui lui a tout de même rapporté la coquette somme de 130 000 dollars. En gros, il a été payé pour dénicher des vulnérabilités au sein de ces multiples applications. Et ses trouvailles sont plus qu’intéressantes…

Une succincte présentation de la faille dénichée

Techniquement, Alex Birsan a exploité une vulnérabilité décelée dans les gestionnaires de programmation que sont Python (PyPi), Node.js (mpm) et Ruby (RubyGems). Les grandes entreprises du numérique concernées construisent ou reconstruisent leurs applications (quotidiennement pour certaines) en utilisant du code, des composants qui peuvent être privés mais aussi publics, ce qui constitue une opportunité pour un hacker d’injecter du code malveillant, code qui pourra être récupéré par l’éditeur dès lors qu’il interroge l’une des sources qui l’héberge. C'est ce qui permettra ensuite de mettre à jour l'application en déposant une porte dérobée. Comme souvent, les entreprises partent du principe que l’outil de base est de confiance. Et lui accorde une confiance aveugle. « Aucun des services d'hébergement de packages ne peut garantir que tout le code téléchargé par ses utilisateurs est exempt de logiciels malveillants », explique aujourd’hui Alex Birsan.

La question se pose notamment lors de l'utilisation de certains packages publics (comme ce qu'a pu faire PayPal) que tout le monde peut utiliser et librement télécharger, mélangés à des packages privés. Ici, Birsan a pu en profiter pour mener sa compromission de dépendance, ou « attaque par substitution ».

Pour apporter une expertise et une franche touche de pédagogie à cette vulnérabilité et vous aider à comprendre le pourquoi du comment, nous avons recueilli les réactions de Fred Raynal, patron et fondateur de Quarkslab, une entreprise française spécialisée dans le développement de logiciels en sécurité de l’information. Nous sommes également allés à la rencontre de Jérôme Thémée, fondateur de l'organisme de formation ESD Cybersecurity Academy ; et de David Bizeul, spécialiste et CTO de Sekoia, qui œuvre dans l’anticipation des cyber-menaces.

Une vulnérabilité qui n'est pas nouvelle

La première chose à savoir, ou à déconstruire si vous pensiez que ce type d’attaque est nouveau, c’est que justement, il ne l’est absolument pas. « Les attaques par supply chain existent depuis 20 ans. Historiquement, nous appelons aussi cela les "attaques sur les dépendances" », nous dit Fred Raynal. « J'ai le souvenir d'un fait similaire mais de plus haut niveau en 2015, lorsque Kaspersky Lab avait révélé une grosse campagne APT menée par l'Equation Group, qui était parvenu, en sortie d'usine, à modifier des disques durs. Les niveaux d'attaques par supply chain sont de très haut niveau aujourd'hui, ça relèverait presque du film d'espionnage », se remémore Jérôme Thémée.

David Bizeul, qui soutient aussi le caractère pas vraiment inédit de la démarche, note que « la technique n'est pas nouvelle, n'est pas forcément facile à exploiter non plus, mais elle est intéressante car elle permet potentiellement de forcer la porte de multiples entreprises et d'avoir des accès à forts privilèges ».

Ce qui est assez rocambolesque, ici, c’est que le chercheur Alex Birsan a œuvré à grande échelle. « On connaît certaines personnes qui ont déjà fait cela en laboratoire. La pratique, pas nouvelle donc, s'est amplifiée avec le Cloud, les micro-services etc., car les applications sont reconstruites en permanence, en allant chercher un peu partout les fameuses dépendances (la supply chain), sans forcément vérifier que c'est la bonne dépendance qui est recherchée et qu'elle est bien légitime. Le moyen que Birsan a trouvé, c'est de fournir les packages plus à jour. Un système, qui est chargé d'une application, voit donc qu'il y a une mise à jour plus récente, il la récupère et reconstruit l'application avec la dernière version. Sauf que dans les faits, ici, ce n'était pas la version légitime. C'est l'une des erreurs rencontrées dans la manière dont les applications sont construites », explique Fred Raynal.

David Bizeul complète en décrivant une « technique qui met l'accent sur une tendance qui s'installe de plus en plus, et qui est relative aux compromissions indirectes. On peut parler de supply chain lorsque la vulnérabilité vient d'un partenaire, mais ici, la faille vient d'un composant tiers rapporté dans la chaîne de traitement. » Le terme « vulnérabilité » ne semble jamais avoir aussi bien porté son nom.

Les raisons et les sources de cette faille

Aujourd'hui, nous sommes plongés dans un environnement où de grandes entreprises du secteur numérique, comme Google, Netflix, Uber, Tesla ou PayPal ont besoin de développer des applications sans perte de temps, rapidement, et il en va de même pour les mises à jour. « Elles sont dans un monde moderne où, pour leurs applications, elles vont chercher du code un peu partout », analyse le fondateur de l'organisme de formation ESD Cybersecurity Academy.

Du code nécessaire à la mise à jour et à la création des applications

Pour trouver le code nécessaire à la mise à jour des applications, les entreprises se rendent sur des bibliothèques très connues, comme analytics.js, jQuery et bien d'autres. Il faut avoir à l'esprit que le recours à ces bibliothèques est primordial pour monter une application. Or, ici, elles peuvent être la solution… Et la source du problème ! Rappelez-vous : tout à l'heure, nous faisions la distinction entre le code privé et le code public.

« Ce modèle DevOps, qui va très vite, pousse à faire confiance à une base connue, publique, qui peut être analysée. Mais on en oublie que ce sont des parties prenantes qui pénètrent notre système d'information », alerte Jérôme Thémée, « et peu de personnes font de la revue de code des dépositaires publics ».

Répondre à la nécessité d'une (re)construction quotidienne des applications

Pour Fred Raynal, il existe trois facteurs au problème :

• un système de build (construction), qui est ce qui va fabriquer l'application,
• L'application, qui est ce qui est fabriqué par le système de build,
• Les dépendances, qui sont ces bibliothèques externes qui vont éviter, par exemple, de recoder un bouton « OK » dès qu'on en aura besoin, c'est-à-dire très souvent, en théorie. En d'autres termes, on se sert alors d'un bouton prêt à l'emploi.

« Le système de build reçoit des instructions qui lui indiquent que le code source de l'application est à tel endroit, qu'il faut l'utiliser et, pour construire l'application, qu'il faut chercher la bibliothèque "Toto" (c'est un exemple), en prenant toujours la dernière version de la bibliothèque Toto ».

« Dans le système de build, il y a une liste d'endroits où l'on peut chercher la bibliothèque mais aussi toutes les autres dépendances, y compris le code source. Le système de build va se mettre à faire le tour de tous les liens de stockage des dépendances, et ne va pas faire la distinction entre Toto sur Toto.fr ou, par exemple, Toto sur GitHub. Il ira au plus simple et prendra la version la plus récente ».

Vous l'aurez aussi compris, certaines des applications visées par la faille sont reconstruites et/ou mises à jour quasi-quotidiennement (ou des centaines, voire des milliers de fois par jour pour un service comme Amazon). « Ce qui pousse à prendre certains raccourcis qui ne sont pas toujours optimaux ».

Quelles conséquences pour les utilisateurs de ces outils et applications ?

C'est sur cette partie-là que nous pourrions vous alarmer et céder à la panique. Mais nous avons souhaité faire preuve de raison et ne pas nous arrêter à la simple évocation de la vulnérabilité, ni aux noms ronflants évoqués (Uber, Tesla, Netflix, Apple, tout ça tout ça…). La sagesse avant tout !

Oui, la faille permet à un attaquant d'injecter une backdoor dans les systèmes utilisés.

Oui, cette backdoor peut permettre de créer une dépendance avec, par exemple, le numéro de carte bancaire d'une personne, et faire croire à une enseigne que le paiement a fonctionné alors qu'il n'a pas réellement été effectué. Mais ce n'est pas aussi simple !

« Cet exemple est erroné, car il y a d'autres mécanismes de protection s'agissant de l'achat par carte bancaire », rappelle Fred Raynal. « Il illustre le potentiel de la vulnérabilité. Mais un pirate aura cependant plus d'intérêt à récupérer toutes les transactions et numéros de carte bleu qu'à faire cela ».

« L'attaque, si elle est bien menée, permet d'imaginer, séquentiellement, la récupération des permissions de l'application compromise, l'accès à la machine ayant installé le programme et enfin la compromission du système d'information », analyse de son côté David Bizeul. Mais le directeur technique de Sekoia tempère, lui aussi et à sa façon, la vulnérabilité : « Les impacts peuvent être importants, pour autant faut-il céder à la panique ? Non bien sûr. Il convient de suivre les bonnes pratiques de sécurité en termes de développement pour faire appel, d'une part, aux bibliothèques strictement nécessaires et connues, et d'autre part pour limiter les privilèges des applications ».

Essayer de relativiser

On peut très bien imaginer un pirate réussir à avoir accès à l'outil qui gère l'ouverture des portes des véhicules Tesla, « mais pour moi, c'est s'amuser à se faire peur », juge Fred Raynal. « À partir du moment où nous avons un tel accès, on peut imaginer un peu tout et n'importe quel débouché. Il faut aussi relativiser par rapport aux cibles et à la volonté d'un attaquant ».

Et le fondateur de Quarkslab de revenir sur l'exemple, forcément parlant, de la carte bancaire : « Ce n'est pas parce que vous aurez réussi à insérer votre numéro de carte bleue que vous réussirez à maquiller des paiements, car derrière, il y a tout un tas d'autres acteurs qui interviennent pour valider ou non un paiement (comme le fameux code de confirmation émis par votre banque sur votre mobile, ndlr.). Il faut réussir à dédramatiser ».

Une faille possiblement déjà exploitée par des individus malveillants

Cette vulnérabilité, vous l'aurez compris, ne date pas d'hier. Mais a-t-elle déjà été exploitée par des pirates informatiques pour autant ? Pas sûr. Pour Fred Raynal, « avant la révélation, peut-être que des gens avaient connaissance de ces vulnérabilités et les ont exploitées ».

La brèche n'est en tout cas pas vraiment comparable à celle exploitée par SolarWinds, liée à de l'injection en mémoire, « ce qui permettait d'entrer directement dans les systèmes d'exploitation », rappelle Jérôme Thémée. « Ici, si c'est dans l'application Web, on va pouvoir faire de l'exfiltration de données, ou peut-être injecter un JavaScript malveillant. On peut dire que ce sera une couche un peu plus haute ».

Une vulnérabilité (plus ou moins facile) à colmater

Une telle faille interroge forcément sur les moyens mis en œuvre par les différents acteurs potentiellement ciblés, pour faire en sorte de se mettre à l'abri. « A posteriori, ce qui va se passer, et ce n'est pas spécifique à cette vulnérabilité, c'est qu'il va y avoir un temps, plus ou moins long, pendant lequel il va falloir corriger la vulnérabilité. Ce qui n'est pas clair pour moi, ici, c'est que je pense que le correctif est propre à chacun et à la manière dont chacun a géré son système de build. Quand Microsoft ou Apple sortent un correctif, les systèmes sont mis à jour. Là, je crains qu'une partie du correctif dépende aussi fortement de la manière dont les ingénieurs des différentes boites ont configuré leur système de build », soulève Fred Raynal.

« Le fait de se livrer à du patch management, à la base, c'est une mesure de sécurité. La mise à jour équivaut à un gain de confiance. Mais en fait, la question à se poser : c'est "est-ce que je peux faire confiance à mon prestataire ?" Toutes les grosses entreprises se posent déjà la question », nous indique Jérôme Thémée, pour qui, aujourd'hui, tout peut aller très vite.

Quel avenir pour la construction des applications de demain ?

Doit-on s'attendre à des changements dans la méthode de construction et reconstruction des applications, qui se passeraient des lignes de code publiques ? Sans doute pas tout de suite !

« Tout peut aller très vite », assure le passionné de hacking. « Les grosses sociétés vont mettre en place des logiciels capables d'analyser du code. Il y a, aux USA, des modèles de framework, comme le BSIMM (Building Security In Maturity Mode), qui regroupe plusieurs dizaines de grandes entreprises, et travaille à la sécurisation des applications. Sur les entrées de code à travers les dépôts, on se rend compte que les grandes sociétés matures en cybersécurité font quand même de l'analyse, mais pas toutes. Il y a une vraie marge de progression là-dessus. Pour moi, il faut mettre en place un modèle pour ce genre d'attaque. Alors oui, ça peut coûter cher, mais on va mettre en place un processus pour sécuriser les cycles de développement. La dernière société française qui faisait ça s'appelait Sqreen, une start-up qui vient d'être rachetée par Datadog, une puissante entreprise US spécialisée dans la surveillance des infrastructures Cloud ».

Quant à savoir s'il faut que les grandes entreprises numériques revoient leur méthode de construction et reconstruction d'applications, en ne privilégiant plus que du code privé au travers duquel un individu malveillant ne peut plus interférer, David Bizeul ne prône pas un bouleversement majeur. « Non, bien sûr, ces systèmes de gestionnaires de paquets sont très pratiques et ils continueront d'être utilisés. Ils assurent une vraie souplesse pour les besoins de développement. Le problème, c'est qu'ils sont tellement pratiques qu'ils automatisent beaucoup d'actions  ».

C'est l'exemple du petit bouton « OK » dont nous parlions précédemment. « En rendant cela transparent, l'utilisateur gagne du temps mais perd le contrôle. À l'échelle de l'entreprise, des stratégies de généralisation de namespace (usage d'un module dans une librairie choisie) devraient être suffisantes pour éviter les effets des attaques de compromission de dépendances ».

Pour Jérôme Thémée, il est plutôt nécessaire de procéder à de la pédagogie au sein des entreprises, mais aussi de les inciter à se donner les moyens de leurs ambitions sécuritaires. « Il est bon de sensibiliser sur ce qu'il convient de faire dans le cas d'une attaque sur supply chain, et d'analyser les parties prenantes. Une entreprise va par exemple se protéger des attaques extérieures, mais ne va pas analyser du code public qui, pour elle, est du code légitime. Et ça, c'est encore du budget et des charges. Même l'ANSSI propose de n'oublier aucune partie prenante : il faut aussi analyser les petites portes », préconise le spécialiste.

La sécurité de la gestion des dépendances est donc une question complexe (que nous avons tenté de vulgariser un maximum), mais l'heure est sans doute davantage à l'optimisation des langages de programmation existants, qu'à celle d'en inventer de nouveaux, qui ne seront que d'inédites opportunités pour des hackers à l'affût de la moindre nouveauté…