00:00:00C'est sérieux et ce n'est pas une blague, ces dernières heures ont été rudes, car il y a eu
00:00:06une énorme attaque de la chaîne d'approvisionnement sur Axios, oui, cet Axios qui compte plus de 80 millions de
00:00:14téléchargements hebdomadaires.
00:00:15Alors, commençons par le début.
00:00:18Pour que vous puissiez vérifier si vous êtes concerné, vous trouverez en pièce jointe un lien vers un article, et
00:00:23je partagerai plus de détails dans un instant, mais c'est important : pour vérifier si vous
00:00:27avez été touché, vous devez suivre ce lien ci-dessous et exécuter les commandes que vous y verrez
00:00:32pour votre système d'exploitation, macOS, Linux, Windows, ils sont tous concernés.
00:00:37Vous devez exécuter ces commandes si vous êtes concerné.
00:00:40Et surtout, si ces étapes montrent que vous avez été compromis, vous devrez
00:00:49renouveler vos secrets, changer vos mots de passe, considérez vos identifiants, les clés API sur
00:00:55votre système, tout ce qui se trouve sur votre système, comme volé.
00:01:00Considérez vos mots de passe comme volés, changez tout, désactivez les clés API, c'est vraiment important.
00:01:07Maintenant, que s'est-il passé exactement ?
00:01:09Axios, bibliothèque JavaScript très populaire évidemment, une bibliothèque qui peut être utilisée pour envoyer des requêtes HTTP
00:01:17depuis, par exemple, une application React vers une API backend.
00:01:22Elle est énormément utilisée, comme vous pouvez le voir, et du code malveillant a été injecté dans
00:01:28cette bibliothèque.
00:01:29Attention, cela ne signifie pas que les sites web qui utilisent cette bibliothèque ont été affectés.
00:01:36Cela signifie plutôt que les systèmes où vous avez installé cette bibliothèque, votre MacBook, votre
00:01:41PC, ou peut-être ce VPS où vous avez construit votre site, ceux-là ont été compromis.
00:01:50Si vous avez lancé npm install, bun install, npm update, bun update, ou autre durant les
00:01:57dernières heures, il y a un grand danger que vous soyez concerné.
00:02:00Encore une fois, j'ai partagé les tests à effectuer pour vérifier si vous avez été touché.
00:02:05Maintenant, comment cela est-il arrivé et qu'est-ce qu'une attaque de la chaîne d'approvisionnement exactement ?
00:02:10Je partagerai aussi, d'ailleurs, comment vous protéger contre de telles attaques à l'avenir.
00:02:15Mais d'abord, comprenons ce qui se passe exactement et ce qu'est une attaque de la chaîne d'approvisionnement.
00:02:20Une attaque de la chaîne d'approvisionnement est simplement une attaque qui ne cible pas le code de votre application.
00:02:24L'attaquant n'essaie pas d'infiltrer directement votre système ou votre base de code.
00:02:31Au lieu de cela, ils profitent du fait que votre code d'application a généralement des dépendances, qui elles-mêmes
00:02:37ont des dépendances.
00:02:38Vous avez donc cette chaîne de dépendances et l'attaque cible cette chaîne.
00:02:45Elle se produit donc en amont de votre code.
00:02:48L'une de ces dépendances contient du code malveillant suite à une attaque où ce code a été
00:02:54injecté, et non parce que le mainteneur essaie de vous attaquer.
00:02:58Mais plutôt, par exemple, comme dans ce cas, le compte d'un mainteneur est compromis
00:03:03et l'attaquant l'utilise pour injecter du code malveillant dans une bibliothèque, dans un paquet,
00:03:10qu'un autre paquet pourrait utiliser, et votre code pourrait alors utiliser ce paquet qui
00:03:16utilise le paquet malveillant, ou peut-être que votre application importe directement la dépendance malveillante.
00:03:23Quoi qu'il en soit, l'une de vos dépendances contient soudainement du code malveillant.
00:03:28Et au moment où vous lancez npm install ou une mise à jour, ce paquet est
00:03:36téléchargé sur votre système, celui qui est infecté, et il peut alors exécuter
00:03:41du code malveillant sur votre machine, généralement à l'aide de scripts post-installation.
00:03:47Au cas où vous ne le sauriez pas, npm possède ce mécanisme de scripts.
00:03:56Nous les utilisons tous dans nos projets, par exemple pour lancer un serveur de dev, compiler le projet,
00:04:01exécuter des tests, des choses comme ça.
00:04:04Et il existe spécifiquement des scripts post-installation, que vous n'utilisez peut-être pas
00:04:11lorsque vous créez une application React, par exemple, mais que les bibliothèques utilisent parfois
00:04:17pour exécuter du code sur votre système après l'installation, généralement pas
00:04:23pour faire quoi que ce soit de malveillant, mais par exemple pour compiler du code, créer un binaire qui
00:04:31pourrait être nécessaire à cette bibliothèque, ou préparer votre système d'une manière ou d'une autre
00:04:36pour qu'il puisse réellement utiliser la bibliothèque que vous venez de télécharger.
00:04:40C'est l'idée derrière un script post-installation.
00:04:42Il permet à un paquet de définir du code qui doit être exécuté après avoir été installé
00:04:49via npm install, par exemple, et c'est exactement ce qui est généralement exploité dans ces
00:04:55attaques de la chaîne d'approvisionnement.
00:04:57L'attaquant injecte du code malveillant dans un paquet sous la forme d'un script post-installation
00:05:04qui s'exécute automatiquement une fois que le paquet infecté a été installé.
00:05:10Généralement, ce code est obfusqué pour qu'il ne soit pas facile à lire.
00:05:14Il pourrait être encodé en base64 pour que les scanners de paquets malveillants
00:05:20ne le détectent pas, ou le code malveillant peut être téléchargé.
00:05:24Ainsi, le script post-installation, comme ici dans l'attaque Axios, ne contient pas
00:05:30directement le code malveillant.
00:05:32Au lieu de cela, il contacte un serveur et télécharge le code depuis celui-ci.
00:05:36C'est ce qui s'est passé ici.
00:05:37Et nous avons un rapport détaillé sur ce qui s'est passé exactement lors de cette attaque.
00:05:41Vous le trouverez en pièce jointe si vous voulez lire tous les détails, mais nous y
00:05:45apprenons essentiellement que deux versions du paquet Axios, 1.14.1 et 0.30.4, ont été compromises
00:05:57et que cela a été fait par l'attaquant en accédant au compte de l'un des
00:06:02mainteneurs du paquet Axios ; ils ont utilisé ce compte pour publier une nouvelle version d'Axios
00:06:08contenant une dépendance qui, à son tour, contenait ce script post-installation.
00:06:14Ce n'était donc même pas le paquet Axios lui-même qui contenait le script post-installation, mais
00:06:19un autre paquet, le paquet plaincryptojs, créé par l'attaquant,
00:06:25dont le seul but est d'avoir un script post-installation qui télécharge et exécute du code
00:06:31malveillant.
00:06:32Le paquet Axios a donc été compromis en ajoutant plaincryptojs comme dépendance.
00:06:39C'est un paquet malveillant.
00:06:40Il ne sert à rien d'autre qu'à télécharger ce code malveillant, et rien qu'en ajoutant cette
00:06:46dépendance à Axios, l'attaque était pratiquement terminée.
00:06:52Ce paquet n'est importé nulle part dans le code source d'Axios.
00:06:56Il possède juste ce script post-installation, et c'est tout.
00:06:59Comme mentionné, il peut ensuite télécharger et exécuter du code sur macOS, Windows et Linux pour
00:07:05faire quoi ?
00:07:06Eh bien, voler un tas de trucs.
00:07:08Si votre système est touché, comme je l'ai dit, les identifiants, clés API, jetons crypto,
00:07:14tout cela est collecté et exfiltré par un trojan téléchargé par ce script
00:07:21post-installation.
00:07:22C'est ainsi que l'attaque a fonctionné.
00:07:24C'est ainsi que des attaques similaires ont fonctionné par le passé.
00:07:29Maintenant, ce qui est intéressant, enfin, oh, au fait, cette attaque a commencé vers minuit,
00:07:36exactement après minuit UTC aujourd'hui, il y a quelques heures.
00:07:40Elle a duré quelques heures et les deux versions d'Axios 1.14.1 et 0.30.4 ont été touchées en
00:07:5040 minutes, 39 minutes pour être précis.
00:07:53C'était donc une attaque très orchestrée et planifiée.
00:07:56Évidemment, la création de ce paquet supplémentaire a eu lieu, je crois, 18 heures avant le début
00:08:03de l'attaque.
00:08:04C'était très orchestré et planifié.
00:08:06Ce qui est un peu bizarre ici, c'est que npm a ce mécanisme appelé "trusted publishing",
00:08:14qui peut être utilisé par les mainteneurs de paquets.
00:08:17L'idée est de limiter le processus de publication de nouvelles versions d'un paquet à un processus
00:08:26clairement défini où vous devez spécifiquement compiler et publier une nouvelle version via
00:08:32l'un des fournisseurs CI/CD supportés avec une configuration précise.
00:08:38L'idée est que même si vos identifiants de compte npm sont volés, en théorie,
00:08:46l'attaquant ne peut pas publier de nouvelle version depuis sa machine car il
00:08:51doit passer par ce processus.
00:08:52On pourrait argumenter que si le compte GitHub d'un mainteneur est compromis, alors peut-être
00:08:59qu'une version malveillante peut être poussée sur GitHub, déclenchant ce workflow de déploiement et
00:09:06donc le code malveillant est publié via ce processus de "trusted publishing".
00:09:11Mais d'après le rapport de sécurité, ce n'est pas ce qui s'est passé ici.
00:09:16Parce que l'équipe Axios utilise ce processus pour la branche 1.x, pas
00:09:21pour la branche 0.30, mais pour la branche 1.x.
00:09:26Pourtant, selon ce rapport, il n'y a aucun commit ou attaque dans le dépôt GitHub d'Axios.
00:09:33Il n'y a donc pas eu de push sur GitHub avec cette version compromise d'Axios.
00:09:40Le processus de "trusted publishing" n'aurait donc pas dû être déclenché.
00:09:44Au lieu de cela, ce rapport indique que l'attaquant a dû obtenir un jeton d'accès npm
00:09:50classique de longue durée pour publier cette version compromise d'Axios car
00:09:56la version n'existait que sur npm, pas sur GitHub.
00:10:01Peut-être est-ce faux.
00:10:02Peut-être que l'attaque est passée par GitHub.
00:10:05Si c'est exact, cependant, je ne vois pas bien comment cela a pu fonctionner car, en théorie,
00:10:11ce mode de publication ne devrait pas être possible quand le "trusted publishing" est activé.
00:10:15Je ne sais pas s'il s'agit d'une faille de sécurité ou d'un problème avec npm ici.
00:10:20Le fait que certains jetons existants de longue durée puissent encore être utilisés même avec le
00:10:26"trusted publishing" activé.
00:10:27C'est une chose que je n'ai pas pu tirer au clair.
00:10:32Et il y a un fil de discussion, un ticket GitHub sur la bibliothèque Axios où cette attaque a été
00:10:39signalée.
00:10:40D'ailleurs, petite parenthèse, d'autres tickets de ce genre ont été créés et supprimés par le mainteneur
00:10:45compromis, enfin par le compte du mainteneur compromis.
00:10:48Ce fil-ci a survécu et l'attaque a fini par être stoppée.
00:10:52Le mainteneur concerné a récupéré l'accès à son compte.
00:10:56Et dans ce fil, le mainteneur a posté qu'ils utilisent le
00:11:03"trusted publishing" et qu'on ne sait pas exactement comment cela a pu arriver.
00:11:07Voici une théorie qui a été partagée.
00:11:09Mais d'après ce que je comprends, cette théorie nécessiterait toujours qu'une version
00:11:16malveillante ou compromise soit poussée sur GitHub, mais encore une fois, ce n'est pas clair.
00:11:20Ce qui est clair, c'est que des versions compromises ont été publiées sur npm et
00:11:25ont donc pu être téléchargées sur des systèmes pour y voler des données.
00:11:29Et bien sûr, avec plus de 80 millions de téléchargements hebdomadaires, il y a beaucoup de dégâts possibles en
00:11:35quelques heures.
00:11:37Évidemment, les téléchargements ne sont pas répartis uniformément sur les 24 heures,
00:11:44mais c'est un chiffre énorme et on peut supposer que des milliers, voire des dizaines de milliers de systèmes
00:11:51ont été touchés en l'espace de ces quelques heures.
00:11:55Bien sûr, ce n'était pas la première attaque de la chaîne d'approvisionnement.
00:11:59Ces derniers mois, nous avons vu de multiples attaques.
00:12:01Une grosse attaque à la fin de l'année dernière, l'attaque Shy Hulu où plusieurs paquets ont été
00:12:08exécutés sur npm, suivant un schéma similaire : du code malveillant injecté et exécuté
00:12:16sur les systèmes téléchargeant ces paquets compromis, puis le vol d'identifiants
00:12:21et autres.
00:12:22C'était donc une attaque majeure.
00:12:25Et il y a seulement quelques jours, nous avons eu un incident similaire dans l'écosystème Python.
00:12:31Ce n'est donc pas limité à JavaScript ; le paquet lightllm a été touché.
00:12:37Un paquet très populaire qui facilite l'utilisation des fournisseurs d'IA via une
00:12:43interface pratique ; il a aussi subi une attaque similaire et a été affecté.
00:12:49Ce n'est donc pas que le JavaScript.
00:12:52Et je pense qu'il y a plusieurs raisons pour lesquelles nous voyons plus d'attaques de ce type.
00:12:57En théorie, ces attaques auraient pu se produire et se sont probablement produites dans le
00:13:03passé aussi, mais elles deviennent nettement plus fréquentes maintenant et je pense qu'il y a
00:13:08quelques raisons à cela.
00:13:11Une raison majeure est que nous sommes à une époque où plus de code que jamais
00:13:17est écrit ou généré.
00:13:19Vous pouvez regarder diverses mesures.
00:13:22Par exemple, j'ai vu ce graphique récemment montrant que le nombre de nouveaux dépôts GitHub
00:13:27créés atteint des records, et c'est bien sûr à cause de l'IA.
00:13:31Les gens travaillent sur des projets, génèrent du code.
00:13:35Nous avons plus de code produit que jamais auparavant et cela signifie qu'avec autant de
00:13:42programmes écrits et de code généré, la surface d'attaque est bien plus grande.
00:13:47Il y a plus de cibles.
00:13:48Il y a plus de gens qui construisent ou écrivent du code et installent des paquets.
00:13:52C'est donc plus attrayant que jamais.
00:13:54Ce n'était pas inintéressant par le passé, mais il y a maintenant plus de gens que jamais
00:13:59qui peuvent être attaqués.
00:14:00C'est donc une première raison importante.
00:14:03C'est simplement plus intéressant de lancer ces attaques, mais ce n'est pas la seule.
00:14:07Je pense qu'une autre raison est aussi liée à l'IA : d'une part, lancer de telles attaques
00:14:15est probablement devenu plus facile grâce à l'IA, car le code malveillant peut bien sûr
00:14:21aussi être généré et écrit par IA. Les compétences techniques requises pour de telles
00:14:28attaques sont plus accessibles que par le passé, je dirais, même si l'on pouvait déjà acheter
00:14:33des scripts ou des trojans sur le darknet ; cela reste plus accessible.
00:14:40Il n'y a pas que le bon côté de l'IA, à savoir que plus de gens peuvent créer des logiciels et transformer
00:14:46leurs idées en entreprises, il y a aussi le mauvais côté.
00:14:50Plus de gens peuvent faire des choses malveillantes liées au code grâce à l'IA, c'est une raison.
00:14:55On pourrait aussi dire que les mainteneurs de paquets et de bibliothèques sont submergés
00:15:01de pull requests.
00:15:02C'est un autre gros problème actuel : si vous êtes mainteneur open source, il y a
00:15:07plus de pull requests que jamais, donc vous pourriez être moins vigilant sur ce que
00:15:13vous fusionnez.
00:15:14Ce n'est pas le problème ici, pour être clair.
00:15:16Dans cette attaque Axios, c'était clairement un compte compromis, mais on pourrait en théorie
00:15:22soutenir qu'il serait possible que des mainteneurs fusionnent du code malveillant ou du code
00:15:29qui installe des dépendances malveillantes par simple inattention, ou peut-être
00:15:34parce qu'ils ont un processus de revue de code automatisé qui ne le détecte pas.
00:15:38Ils se fient juste à l'IA.
00:15:40Encore une fois, pas le cas ici, mais on peut imaginer que cela puisse être utilisé à l'avenir
00:15:45pour injecter du code malveillant parce que les gens ne vérifient plus.
00:15:51De plus, quand vous utilisez des outils comme Cursor, OpenCursor ou autre sur votre système pour
00:15:56toutes sortes de travaux, pas seulement pour vous aider à coder mais peut-être pour gérer votre système,
00:16:01pour certaines tâches, ces outils pourraient décider
00:16:09d'écrire un script et de lancer du code pour accomplir une tâche demandée, et ce
00:16:15code généré pourrait aussi s'appuyer sur des dépendances comme Axios.
00:16:20Donc la surface d'attaque s'agrandit encore, c'est mon premier argument, mais au-delà
00:16:24du simple développement logiciel classique. Pour toutes ces raisons, et probablement beaucoup d'autres
00:16:30auxquelles je n'ai pas pensé, ces attaques deviennent plus lucratives, plus faciles et plus
00:16:37intéressantes à mener, c'est pourquoi je suis certain qu'on en verra davantage à l'avenir.
00:16:43Maintenant, que pouvez-vous faire pour prévenir ces attaques et vous protéger ?
00:16:47Une étape de sécurité majeure, une chose que vous pouvez faire dans tous vos projets où vous
00:16:55travaillez sur des applications, c'est d'utiliser des outils comme pnpm au lieu de npm pour gérer
00:17:02vos dépendances. Vous pouvez ajouter un paramètre d'âge minimum de sortie dans votre fichier pnpm-workspace.yaml.
00:17:09Bun a une fonctionnalité similaire, vous pouvez ajouter un fichier bunfig.toml si vous l'utilisez,
00:17:15et ils ont aussi un paramètre d'âge minimum de sortie.
00:17:21Qu'est-ce que cela fait ? Ça garantit simplement que lors de l'installation d'un paquet,
00:17:27seules les versions qui ont au moins cet âge-là seront installées.
00:17:34Donc si un paquet a été compromis il y a cinq heures, mais que vous avez une règle n'installant que les
00:17:39versions vieilles d'au moins trois jours, vous devriez être en sécurité. C'est l'idée, et malheureusement npm
00:17:46ne propose pas cela nativement. Juste pour être clair,
00:17:51nous parlons toujours de paquets hébergés sur npm, le problème n'est pas l'hébergeur mais le gestionnaire de paquets.
00:17:56Vous pouvez bien sûr utiliser bun ou pnpm pour télécharger ces paquets depuis npm, et si vous les
00:18:03utilisez à la place de npm lui-même, vous pouvez profiter de réglages comme celui-ci
00:18:08qui vous offrent simplement une couche de sécurité supplémentaire. Généralement, par le passé, ces
00:18:14attaques ont été détectées en quelques heures ; donc si vous avez un seuil de trois jours,
00:18:20par exemple, la plupart de ces attaques auront été identifiées et terminées. Ce n'est pas
00:18:25sûr à 100% bien sûr, une attaque pourrait durer plus longtemps, mais cela donne un net avantage et c'est
00:18:32clairement une bonne pratique. Pour être encore plus serein, vous pouvez
00:18:39envisager d'utiliser des solutions comme Doppler (ce n'est pas sponsorisé, c'est juste un exemple, il y a des alternatives ;
00:18:44j'ai d'ailleurs créé ma propre alternative que j'utilise moi-même), qui sont des services ou outils pour
00:18:49gérer vos secrets. Quelque chose comme votre clé API OpenAI, vous pourriez la mettre dans un fichier
00:18:55.env, mais il vaut mieux la stocker de manière chiffrée avec un service comme Doppler sur
00:19:02leurs serveurs ou auto-hébergé sur votre propre VPS, puis l'injecter dans l'environnement
00:19:08pour que votre application puisse l'utiliser au besoin. Ainsi, si vous aviez un
00:19:13trojan sur votre système qui récupère tous vos fichiers .env pour en extraire les informations,
00:19:20il n'y trouverait aucun secret. C'est l'idée : ne pas stocker ces secrets
00:19:25dans des fichiers texte sur votre système (un fichier .env n'étant qu'un fichier texte après tout) mais
00:19:32plutôt chiffrés ailleurs est une chose à envisager sérieusement.
00:19:36Encore une fois, il existe différentes solutions, mais c'est une piste de réflexion.
00:19:40Et pour une sécurité maximale, vous pourriez externaliser votre environnement de développement
00:19:45pour ne pas l'avoir sur votre MacBook ou votre PC, mais plutôt sur un VPS ou un Mac mini
00:19:50auquel vous vous connectez via SSH ou autre, ou peut-être dans un conteneur Docker, pour que
00:19:56si du code malveillant y était exécuté, il n'affecte que ce conteneur Docker ou ce
00:20:02VPS, et non votre système entier. Il ne pourrait pas récupérer tous vos mots de passe système
00:20:07et autres ; il resterait isolé, réduisant ainsi le rayon d'action.
00:20:13Car ces attaques continueront de se produire. Je suis certain que nous aurons des mécanismes
00:20:21de plus en plus performants pour sécuriser la publication des paquets, mais il n'y aura jamais de garantie
00:20:27à 100% que ces attaques sont impossibles. Par conséquent, en tant qu'utilisateur de ces paquets,
00:20:33vous devez sécuriser votre système et multiplier les couches de défense pour réduire les risques
00:20:39de télécharger une version compromise et, si cela arrive, limiter les dégâts.
00:20:45C'est ce que vous pouvez faire ; j'en dirai plus dans de prochaines vidéos, également sur mon autre chaîne,
00:20:50la chaîne Academy. Mais voilà, restez prudents, vérifiez si vous avez été touché par cette
00:20:55attaque et, comme je l'ai dit, ces dernières heures ont été mouvementées.