La campagne qui a piraté Axios expose la fragilité des chaînes d'approvisionnement logicielles

Cette semaine la communauté de développement de Node.js a dû s'intégrer dans un rappel inconfortable: les chaînes d'approvisionnement du logiciel sont aussi fragiles que les gens qui les maintiennent. Les chefs de clients HTTP Axios populaires ont publié un rapport détaillé sur un incident dans lequel les attaquants ont réussi à compromettre un compte de maintenance et à publier deux versions malveillantes du paquet dans l'enregistrement npm. Ces versions, étiquetées comme 1.14.1 et 0.30.4, ils ont introduit une unité appeléecrypto-jsqui a déployé un Trojan d'accès distant capable de fonctionner sur macOS, Windows et Linux.

La fenêtre d'exposition était courte - les versions malveillantes étaient dans le registre environ trois heures avant qu'elles soient retirées - mais cette courte période était suffisante pour les projets et les environnements qui les ont téléchargés pour être en danger. Les responsables d'Axio ont averti que tout système qui a installé ces versions pendant cette période devrait être considéré comme compromis et ont recommandé des lettres d'identité tournantes et des clés d'authentification. De plus, l'équipe touchée a effacé les machines compromises et rétabli l'accès tout en mettant en œuvre des mesures visant à réduire la probabilité qu'une situation semblable se reproduise. Vous pouvez lire le post-mortem officiel dans le dépôt Axios dans GitHub: https: / / github.com / axios / axios / numéros / 10636.

Ce qui rend cet incident particulièrement inquiétant n'est pas seulement malware lui-même, mais la façon dont les agresseurs ont eu accès à: une campagne d'ingénierie sociale beaucoup travaillée visant les responsables. Selon la chronique des personnes touchées, l'attaque a commencé par l'implantation d'une entreprise légitime, en reproduisant son image d'entreprise et en créant de faux profils qui ont simulé les employés et les collaborateurs de l'écosystème open source. De là, ils ont invité les développeurs à un espace « fiable » Slack et organisé des appels vidéo qui semblaient authentiques.

Lors d'une de ces réunions simulées, les attaquants ont montré une erreur technique supposée qui a motivé l'installation d'une mise à jour de Microsoft Teams. Cette "mise à jour" n'était rien d'autre qu'un installateur qui a déployé un RAT sur l'équipe du mainteneur, permettant aux attaquants d'accéder à des sessions authentifiées et d'extraire des identifiants npm. En d'autres termes, la protection fondée sur le MFA a été compromise parce que l'accès s'est concrétisé par des séances déjà authentifiées. L'explication et l'analyse de Google Threat Intelligence Group, qui attribue l'opération à l'acteur identifié comme UNC1069, comprend plus de détails sur l'infrastructure utilisée et ses parallèles avec les campagnes précédentes: https: / / cloud / google.com / blog / sujets / amenat-intelligence / nord-korea-amenat-acteur-cibles -axios-npm-package.

Les groupes de sécurité qui ont suivi l'exemple de cette activité soulignent qu'il ne s'agit pas d'une attaque isolée, mais d'une campagne coordonnée et ciblée pour des projets qui dépendent beaucoup de l'écosystème Node.js. La société Socket, qui a publié une analyse du modèle d'attaque, a documenté comment les attaquants ont contacté plusieurs responsables via LinkedIn, Slack ou d'autres plateformes et reproduit le même mode d'opérandi : invitations à des espaces privés, rencontres avec des acteurs apparemment réels et pression pour installer des logiciels "natifs" ou exécuter des commandes console qui ont fini par télécharger des logiciels malveillants. Socket résume ses constatations et ses préoccupations concernant l'impact sur les emballages à forte utilisation dans cet article : https: / / socket.dev / blog / attaquants-chasse-haut impact-nodejess-maintainers.

Tous les objectifs n'ont pas cédé. Plusieurs responsables ont partagé comment ils ont rejeté les demandes d'installation de binaires ou de commandes d'exécution, et l'un d'eux, Pelle Wessman, a montré une capture du message frauduleux qu'ils leur ont présenté - une erreur présumée de connexion RTC - et a expliqué que lorsqu'il a refusé de lancer l'installateur, les attaquants ont même essayé de le convaincre de lancer une commande de boucle pour télécharger le code. Votre témoignage est disponible dans LinkedIn et les fils post mortem: publié par Pelle Wessman.

Une dimension technique pertinente ici est que les attaquants n'ont pas directement modifié le code source du projet Axios. Au lieu de cela, ils ont injecté une dépendance malveillante dans des paquets légitimes, une tactique qui permet aux acteurs malveillants d'emballer le code nuisible dans une mise à jour apparemment fiable. Cette stratégie souligne pourquoi les chaînes d'approvisionnement en logiciels, et en particulier les dépôts de paquets, sont si attrayants : compromettre une librairie populaire peut amplifier une attaque contre des milliers ou des millions d'utilisateurs.

Que peut faire un développeur ou une équipe si vous pensez avoir installé une des versions touchées? La chose la plus immédiate et la plus prudente est d'agir comme si le système était engagé : de supposer que les jetons, les lettres de créances et les sessions npm étaient exposés, et de les faire tourner et les révoquer. Il est également approprié de vérifier les fichiers de verrouillage (package-lock.json, fil.lock) pour détecter les dépendances inattendues, examiner l'historique de l'installation et examiner les journaux CI / CD pour une activité inhabituelle. Pour la gestion de compte npm spécifique, activer ou renforcer l'authentification de deux facteurs et revoir les jetons d'automatisation est recommandé; npm documente les bonnes pratiques et la configuration 2FA sur son site: https: / / docs.npmjs.com / configuration-deux facteurs-authentification.

Au-delà des opérations d'urgence, cet épisode soulève des questions plus larges sur la façon de protéger l'écosystème à source ouverte. Les gardiens travaillent souvent avec des ressources limitées et reçoivent des demandes légitimes de collaboration avec l'assiduité; toutefois, la sophistication de ces campagnes exige des protocoles plus stricts : vérification de l'identité des nouveaux collaborateurs, canaux de communication clairement définis, pratiques de durcissement des machines de maintenance (machines dédiées et séparées) et processus d'édition qui réduisent au minimum l'utilisation de jetons personnels en faveur des titres de compétence de courte durée ou des flux d'IC avec un minimum de permis.

Enfin, il faut se rappeler que les acteurs ayant des motivations financières ou d'État ont utilisé des tactiques similaires avant, en déployant une variété d'outils tels que backdoors, le téléchargement et les infostealers pour collecter des identifiants, des cookies et d'autres secrets. L'attribution de Google à UNC1069 mentionne l'utilisation d'une variante nommée WAVESHAPER. V2, qui relie cet incident aux schémas observés lors des campagnes précédentes contre les victimes du secteur critique et d'autres infrastructures: Analyse GTIG.

La leçon est claire et dure : la sécurité des logiciels n'est pas seulement un problème technique, c'est aussi un problème humain. La protection des projets à impact élevé nécessite non seulement des contrôles automatiques, mais aussi une formation, des protocoles et des ressources afin que ceux qui maintiennent des éléments critiques ne soient pas les maillons les plus faibles. Pendant ce temps, si vous gérez des projets qui dépendent d'Axios ou travaillez avec des paquets npm, vérifiez vos installations, prenez soin si les versions de clé et de jetons mentionnées et cassées ont été téléchargées.

Pour élargir la lecture de l'incident et de son enquête, en plus du post-mortem d'Axios et du rapport de Google, vous pouvez consulter la couverture technique dans les médias spécialisés, par exemple dans BleepingComputer, qui résume l'attaque et sa portée: https: / / www.bleepingcomputer.com / news / sécurité / hackers-compromise-axios-npm-package-to-drop-cross-platform-malware /.