La trahison dans votre code : comment un seul paquet engagé expose la faiblesse de la chaîne d'approvisionnement du logiciel

Il y a quelques jours, il a été confirmé que la chaîne d'approvisionnement ouverte de npm a subi un incident grave: le paquet populaire Axios a été manipulé pour distribuer un logiciel multiplateforme malveillant, et Google a souligné que un groupe nord-coréen appelé UNC1069 serait derrière l'attaque. Bien que les nouvelles aient sauté dans plusieurs médias spécialisés, ce qui préoccupe la communauté n'est pas seulement qu'une librairie aussi répandue a été compromise, mais la sophistication de la procédure et la capacité de l'agresseur d'opérer de manière évolutive et furtive.

Le mécanisme utilisé par les attaquants n'était pas de modifier le code source d'Axios, mais de profiter de la confiance de la chaîne d'édition. Le paquet npm du responsable a été enlevé et deux versions manipulées (1.14.1 et 0.30.4) ont été publiées qui ont ajouté une dépendance malveillante appelée "chiffre simple". Cette unité a été utilisée par un crochet d'installation (un postinstall défini dans le fichier).de l'information) pour exécuter le code sur l'équipe de ceux qui ont installé Axios: npm, par conception, exécute ces scripts automatiquement après l'installation, ce qui a permis une exécution silencieuse du code malveillant sans toucher à l'API Axios.

L'unité a agi comme une sorte de véhicule pour déployer une dropper JavaScript opfuscado, surnommé SILKBELL (fichier appelé "setup.js"), qui contacte un serveur distant et télécharge la prochaine étape selon le système d'exploitation de la victime. Dans la branche Windows, une charge basée sur PowerShell est fournie, dans macOS un binaire Mach-O écrit en C + + est installé, et dans Linux un backdoor est fourni en Python. Après le téléchargement et l'exécution de la bonne charge, la goutteuse effectue un nettoyage : elle élimine les traces et remplace lade l'informationd'une dépendance malveillante à un "propre" sans crochet d'installation, ce qui rend difficile de détecter davantage de criminalistique.

La porte arrière identifiée dans les systèmes a été baptisée comme WAVESHAPER.V2, une évolution d'un outil précédent lié au même acteur. Cette variante élargit les fonctionnalités et exploite un canal de commande et de contrôle avec communication dans JSON; elle recueille plus d'informations du système et accepte des ordres pour arrêter son exécution, les répertoires de listes et les métadonnées de fichiers, exécute des scripts (AppleScript, PowerShell ou shell, selon la plate-forme) et même injecte et exécute des binaires décodés en mémoire. Le malware effectue des enquêtes sur le serveur de contrôle toutes les 60 secondes, et partage des fonctionnalités opérationnelles et des artefacts (tels que les itinéraires horaires et les chaînes d'agents utilisateurs) qui ont permis aux sociétés de sécurité et à Google de le corréler avec UNC1069.

L'attribution, bien que pas toujours finale, a eu des contributions importantes: Elastic Security Labs a été le premier à détecter des similitudes fonctionnelles et Mandiant avec Google Threat Intelligence Group a fourni des analyses techniques qui soutiennent la relation entre les nouveaux échantillons et les campagnes précédentes de l'acteur. L'historique complet est rapporté dans plusieurs analyses techniques et nouvelles spécialisées qui documentent à la fois la technique postinstallation et les charges spécifiques déployées: il est approprié d'examiner les sources de sécurité pour les indicateurs d'engagement et le contexte plus technique, par exemple dans l'inscription du paquet à npm et dans les rapports des spécialistes de la sécurité ( Page Axios dans npm, Sécurité élastique Analyse des laboratoires et couverture médiatique Les nouvelles Hacker).

Que pouvons-nous apprendre de cet incident? Premièrement, les attaques contre la chaîne d'approvisionnement évoluent : elles ne se limitent pas à un script opportuniste, mais à des opérations planifiées qui combinent l'engagement des comptes, les charges prépositionnées pour plusieurs systèmes et mécanismes d'effacement des impressions. Les experts ont averti que cette affaire devrait être considérée comme un modèle de fonctionnement qui peuvent être reproduits dans d'autres registres et écosystèmes (PyPI, NuGet, etc.), parce que l'objectif est de maximiser la portée des unités de construction et de développement automatisées.

Dans la pratique, les mesures que les organisations et les promoteurs devraient prendre ne sont pas banales et passent par l'hygiène de l'environnement et les pratiques de sécurité dans la publication et la consommation des paquets. Il est approprié de vérifier les chaînes de dépendance et de bloquer les versions compromises, définir (pin) les versions sécurisées dans les fichiers de verrouillage commepaquet-lock.jsonprévenir les mises à jour accidentelles et vérifier manuellement la suspicion de dépendancecrypto-jsdansmodules _ noeud. Si l'activité est détectée, il est essentiel d'achever les processus malveillants, d'isoler l'équipement affecté et de faire pivoter les lettres de créance et les clés qui peuvent avoir été exposées. En outre, bloquer les connexions au domaine de commande et de contrôle signalé et votre IP associé aide à couper le canal de contrôle et de contrôle; les outils d'analyse du trafic et les listes de verrouillage doivent être mis à jour en conséquence.

Au-delà de cette réponse réactive, l'écosystème a besoin de mesures préventives durables : appliquer l'authentification multifactorielle dans les comptes de maintenance, forcer des examens plus rigoureux des changements qui affectent les dépendances, générer et maintenir un SBOM (bill de matériaux logiciels) pour savoir exactement ce qui vient dans les bâtiments, et limiter l'utilisation de crochets qui utilisent le code dans les phases d'installation ou de construction. Il est également prudent de supposer que tout secret stocké dans l'environnement qui a publié ou construit des paquets commis peut avoir été compromis et devrait être tourné sans délai.

Cet incident est également un appel à l'attention sur l'économie derrière certains acteurs: des groupes ayant des motivations financières ont toujours préféré des campagnes contre les services et les plates-formes de cryptomoneda, et la sophistication observée (charges utiles pour trois systèmes, déploiement à court terme et mécanismes d'autodestruction) suggère une intention d'opérer à grande échelle. La réponse ne devrait donc pas se limiter à un patch spécifique, mais plutôt à repenser la façon dont les organisations gèrent les unités et les permis dans leur cycle de développement.

Si vous voulez approfondir, vérifiez les analyses publiées par les laboratoires de sécurité et les fournisseurs de renseignements qui ont documenté les échantillons, les domaines et les modèles de comportement. Consultez des sources fiables et à jour qui vous permettront d'appliquer les derniers indicateurs d'engagement et de coordonner une réponse appropriée : Laboratoires de sécurité élastiques, Mandiant, ReversingLabs et des articles de presse spécialisés tels que Les nouvelles Hacker sont de bons points de départ pour contraster l'information et accéder aux listes IoC.

En fin de compte, la leçon est claire : la confiance dans une dépendance n'est pas immuable. Adopter des contrôles plus stricts dans la chaîne d'approvisionnement des logiciels, accroître la surveillance dans les processus d'édition et traiter la gestion secrète comme essentielle sont des étapes essentielles pour réduire le risque qu'un incident semblable affecte vos projets ou votre organisation.