Alerte de sécurité: compromis @ asyncapi npm paquets d'incendie le cadre malveillant Miasma pendant le bâtiment et les flux CI

Les enquêteurs de la sécurité ont identifié une campagne d'engagement de la chaîne d'approvisionnement qui a affecté plusieurs paquets de npm d'espace de noms @ asyncapi, et qu'ils ont distribué un chargeur en plusieurs étapes qui conduit à un cadre malveillant avancé appelé "Miasma." Les paquets concernés comprenaient des versions spécifiques de @ asyncapi / générateur-aide, @ asyncapi / générateur-composants, @ asyncapi / générateur et @ asyncapi / spécifications; ces paquets contenaient un fichier injecté qui, une fois chargé par Node.js avec requis (), a exécuté une première charge utile obfusquée qui a téléchargé d'IPFS une deuxième étape cryptée appelée "sync.js". La ressource de téléchargement observée a été publiée sur la passerelle publique : ipfs.io ipfs / QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9.

La chaîne d'infection décrite ci-dessus ne dépend pas des crochets d'installation (pré-installation / post-installation) mais de la charge en temps de fonctionnement: le code malveillant est activé lorsque la librairie infectée est requise () d pendant une construction ou dans un flux de travail CI. Cette différence est cruciale pour la détection et la réponse, car une installation npm simple qui ne charge pas la bibliothèque peut ne pas activer l'exécution, alors qu'une compilation ou une tâche CI qui importe le module.

Le chargeur "sync.js" contient deux composants : l'un est la charge utile finale cryptée JavaScript contenant le framework Miasma et l'autre est une grande structure cryptée utilisée par l'exécution des chaînes de processus. Le framework rapporté regroupe des centaines de modules et prend en charge plusieurs canaux de contrôle et de contrôle, y compris HTTP REST, relais Nost, IPFS, BitTorrent DHT, libp2p GossipSub et même un contrat intelligent dans Etheum. Ses capacités incluent le vol de lettres de créances, l'empoisonnement des outils IA, le mouvement latéral du LAN et la propagation du ver aux enregistrements tels que npm, PyPI et Cargo, ainsi que les mécanismes de persistance dans les clés de registre systemd, crontab, lancé et Windows.

L'analyse montre également des fonctions opérationnelles matures : chiffrement des communications et des tâches, téléchargement de fichiers, signature des nœuds et mise à jour à distance des charges utiles. Le malware inclut un mécanisme de "switch de l'homme mort" qui surveille un jeton volé et peut activer un répertoire supprimé si le jeton est révoqué, et évite les systèmes qui ressemblent à des bacs à sable, des machines virtuelles, des équipements configurés en russe ou ceux avec un logiciel de sécurité spécifique installé (par exemple CrowdStrike, SentinelOne, Microsoft Defender et autres), ce qui indique l'intention de rester opérationnel dans des environnements réels et éviter l'analyse.

Un point opérationnel important qui distingue cette intrusion est le vecteur de publication: selon les équipes impliquées dans l'enquête, l'attaquant a obtenu accès à pousser les dépôts et utilisé les flux légitimes GitHub Actions du projet, publiant des paquets par l'intégration de l'OIDC de GitHub pour npm. Ce qui a produit des paquets avec des attestations SLSA et OIDC valides, ce qui montre que les bâtiments ont été réalisés par un workflow autorisé, mais ne garantit pas que les membres qui l'ont activé étaient légitimes. En d'autres termes, la présence de preuves d'origine SLSA ne remplace pas un contrôle strict sur qui peut pousser et sur quels engagements sont acceptés.

Les versions malveillantes ont déjà été retirées de l'enregistrement npm, mais les dommages peuvent s'être matérialisés dans tout paramètre qui a importé et exécuté ces modules dans des bâtiments, des environnements de développement ou des emplois CI. Tout système qui charge les versions concernées doit être traité comme potentiellement compromis et de ne pas assumer la sécurité en raison de l'absence de scripts d'installation dans le paquet. Json.

Pour les équipes et les gestionnaires, les actions immédiates recommandées sont d'isoler et de préserver les artefacts s'ils soupçonnent l'exécution, de vérifier les dépendances et de construire, et de rechercher des indicateurs concrets: suivre dans les fichiers de verrouillage et dans l'arbre des dépendances les versions affectées de @ asyncapi; rechercher dans les dépôts et dans la base de codes appelés à exiger () sur ces paquets; détecter les processus Child Node.js qui sont exécutés dans l'arrière-plan et les fichiers appelés "sync.js" écrits sur des itinéraires spécifiques du système; vérifier la présence d'unités système, d'entrées crontab, lancé et Rkeys récemment créés dans le registre Windows. Il convient également de bloquer au niveau du réseau le CID / IPFS connu et la passerelle concernée pour empêcher les téléchargements futurs: en plus du lien IPFS précédent, les organisations peuvent appliquer des contrôles d'évacuation pour les passerelles publiques.

Au niveau de la prévention de la chaîne d'approvisionnement, il est essentiel de limiter qui peut modifier les dépôts et quels flux de travail peuvent publier des artefacts. Examiner les protections de la branche, forcer les examens humains avant qu'ils ne tirent sur les versions, vérifier les secrets et les références de pousser au dépôt, et limiter l'identité des actions GitHub avec des autorisations minimales. Notez que les tests OIDC / SLSA confirment que la construction a été produite par le workflow de confiance, mais ne remplace pas le contrôle de l'intégrité du dépôt ou la protection des pouvoirs push. La documentation utile sur le modèle de l'OIDC à GitHub et sur l'initiative SLSA est disponible auprès des ressources officielles: GitHub - OIDC pour les actions GitHub et SLSA (niveaux de la chaîne d'approvisionnement pour les artistes logiciels).

Au cours de la phase de réponse et de médiation, il convient de combiner des mesures techniques et de processus : révoquer et faire pivoter les justificatifs d'identité exposés, examiner et remplacer les paquets engagés par des versions propres ou reconstruites à partir de sources vérifiées, reconstruire les dispositifs de libération dans des environnements contrôlés et vérifier les hachages, et effectuer des analyses médico-légales sur les paramètres suspects avec EDR / antimalware pour détecter les infiltrations, les persistances et les modules chargés par Node.js. Pour réduire les risques futurs, mettre en œuvre un balayage continu de l'unité, publier la signature et les politiques qui limitent la publication automatique sans révision du code qui déclenche le flux de travail.

Cet incident souligne que la confiance dans la chaîne d'approvisionnement est conditionnée : les garanties du workflow et de la signature facilitent la traçabilité, mais ne remplacent pas le besoin de contrôles d'accès, d'examens humains et de surveillance du rendement. Si votre organisation a utilisé l'une des versions compromises, il agit comme s'il y avait eu un compromis : il vole, enquête et récupère à partir de sources propres, et profite de la leçon pour resserrer les contrôles sur les dépôts et CI / CD.