La menace Miasma expose la fragilité de npm et fait de GitHub un vecteur de vol d'identités

Une nouvelle vague de gestion de la chaîne d'approvisionnement des paquets JavaScript, détectée sous le nom de campagne « Miasma », a démontré à nouveau combien l'écosystème de npm est fragile quand un acteur malveillant est capable de contaminer les paquets populaires liés aux services cloud. Le vecteur initial semble avoir été la prise d'un compte GitHub par un employé de Red Hat., qui a permis l'introduction d'engagements orphelins et le chargement de code malveillant dans les paquets utilisés par les développeurs et les systèmes CI / CD.

Les analyses publiques de plusieurs sociétés de sécurité montrent que les logiciels malveillants sont activés dans le temps d'installation et est conçu pour voler les lettres de créances et les secrets locaux et CI: jetons npm, secrets GitHub Actions, clés SSH, identifiants cloud (GCP, Azure), matériel Kubernetes et Vault, ainsi que des fichiers de configuration d'outils de développement. La menace est complétée par un mécanisme d'exfiltration chiffré et un canal de sauvegarde par des dépôts publics de GitHub contrôlés par les attaquants, ce qui leur permet à la fois de voler des données et d'essayer de répandre l'engagement à d'autres unités et pipelines.

La chose la plus inquiétante est la sophistication opérationnelle : les logiciels malveillants utilisent l'échange OIDC pour les jetons, les repagettes et les dispositifs de signature avec Sigstore, utilisent l'API GitHub pour créer des engagements apparemment vérifiés et peuvent insérer des flux de travail ou des changements dans les pipelines pour persister ou activer de nouvelles étapes malveillantes. Certaines variantes génèrent une charge cryptée unique pour chaque infection, ce qui rend difficile la détection par signatures et le suivi des variantes.

En termes d'attribution et de motivation, la situation est ambiguë. Le fait que des outils associés à la famille Shaï-Hulud aient été publiés par un groupe criminel bien connu complique l'identification de l'auteur réel de l'attaque : la source ouverte d'une menace permet à plusieurs acteurs de reproduire des campagnes avec des changements minimes réduire la traçabilité et augmenter le risque des imitateurs.

Pour les équipements techniques et responsables de la sécurité, la liste des impacts possibles est longue : de l'engagement du compte cloud à la contamination des images de conteneurs, des paquets publiés ou des artefacts qui sont ensuite distribués aux utilisateurs finaux. Dans les environnements à intégration continue, un titre volé qui vous permet d'écrire dans des dépôts ou de lancer des flux de travail peut transformer un incident local en une échelle étendue. L'exfiltration cryptée et l'utilisation de forces comme canal de fuite font de GitHub un double vecteur : objectif et véhicule.

La réponse immédiate devrait combiner confinement et criminalistique : isoler les machines qui ont installé des versions compromises, suspendre les exécutions d'IC touchées et révoquer tout jeton ou titre de compétence qui aurait pu être présent dans ces environnements. Il est essentiel non seulement de désinstaller les paquets; la campagne comprend des mécanismes de persistance dans les outils de développement (p. ex., des crochets pour les éditeurs et les coureurs) qui nécessitent un audit complet de l'hôte et la restauration d'images propres, le cas échéant. Les clés rotatives, les jetons / jetons invalides et les engagements d'audit et les workflows dans GitHub sont des étapes incontournables.

Au niveau préventif, les organisations devraient renforcer les contrôles sur les comptes capables de publier des paquets ou de modifier les flux de travail : appliquer l'accès avec le moins de privilèges possible, forcer l'authentification multifactorielle, exiger des révisions de code et permettre des politiques de restriction des jetons chez les coureurs. De plus, l'utilisation d'outils pour vérifier l'origine des colis et des artefacts - comme les modèles d'avertissement de la chaîne d'approvisionnement ou les solutions de numérisation - réduit la probabilité qu'un colis contaminé arrive sans être détecté dans des environnements critiques.

Il est également approprié d'intégrer une détection basée sur le comportement qui cherche des signaux atypiques: appels vers des API tierces à partir de processus d'installation, création d'engagements automatiques qui incluent des changements dans les actions GitHub, ou la présence de fichiers et de crochets persistants dans les répertoires utilisateurs. Pour de bonnes pratiques et ressources en matière de sûreté dans les dépôts et la chaîne d'approvisionnement, consultez la documentation de sécurité des plateformes de pointe et le blog de sécurité GitHub, ainsi que les analyses techniques publiées par des fournisseurs de sécurité tels que Microsoft et JFrog. Blog de sécurité GitHub et Microsoft Security Blog offrir des guides et des avertissements pertinents.

Enfin, cet incident rappelle que l'hygiène de l'identité et la protection des comptes de développeurs font partie intégrante de la sécurité de l'entreprise. Minimiser les références persistantes dans les postes de travail et les coureurs, en utilisant des références éphémères et souvent des autorisations d'audition dans les dépôts et les projets de cloud sont des mesures qui réduisent la fenêtre d'exposition. Les organisations doivent supposer que la pollution de la chaîne d'approvisionnement peut se produire et concevoir des processus pour contenir, éradiquer et récupérer rapidement sans compter uniquement sur la désinstallation des paquets.