L'avant caché des attaques de npm avec rootkits threaded eBPF et backdoors qui menacent CI CD IDE et identificateurs

Ces derniers jours, l'écosystème npm a souffert d'une vague d'attaques de chaîne d'approvisionnement qui combinent des techniques anciennes et très nouvelles: paquets groupés légitimes, crochets d'installation et binaires natifs utilisant un chargeur Rust avec un routkit basé sur le noyau basé sur eBPF, ainsi que des variantes de vers autoréplicateurs qui utilisent des identifiants volés pour se propager entre les dépôts et les enregistrements. La combinaison d'un braqueur d'information capable de se cacher dans le noyau et d'une famille de vers réutilisant des références rend ces incidents non seulement des infections locales, mais des armes de propagation durable qui peut compromettre un ordinateur portable développeur vers des pipelines CI / CD et des environnements de production en nuage.

Les deux campagnes rapportées utilisent des vecteurs différents mais complémentaires: un (publicment identifié comme "IronWorm") publie des paquets échoués qui exécutent un ELF dans Rust par des crochets de pré-installation; un autre profite d'un mécanisme moins surveillé - une minuscule liaison.gyp, nommé par les chercheurs comme "Phantom Gyp" - pour exécuter le code pendant l'installation npm et ainsi échapper à de nombreuses vérifications. Les deux télécharger des runtimes alternatifs (comme Bun) et chercher agressivement des identifiants liés aux fournisseurs de cloud, portefeuilles cryptomoneda, GitHub Actions et les paramètres d'assistant de code basés sur l'IA. Le but est double: exfilter des secrets et laisser des portes arrière persistantes qui sont activés chaque fois qu'un développeur ouvre un projet dans un IDE avec l'aide de l'IA un vecteur particulièrement inquiétant pour la sécurité du développement moderne.

Au-delà des dommages techniques, les implications pour la confiance dans la chaîne d'approvisionnement sont profondes. Ces campagnes montrent que les acteurs malveillants peuvent utiliser GitHub non seulement pour stocker l'exfiltration, mais comme un canal de commande et de contrôle adaptatif - modifiant les engagements qui contiennent des indicateurs tels que "firedalazer" pour changer la charge utile - et qui peut forger des métadonnées de publication (SLSA) pour faire des versions dans les enregistrements semblent légitimes. Lorsque la plate-forme que nous utilisons pour collaborer devient un canal pour mettre à jour votre propre malware, les contrôles traditionnels sur le réseau et les scanners de malware cessent d'être assez.

Pour les développeurs et les équipements qui dépendent de npm et de GitHub, les mesures réactives immédiates sont claires : faire pivoter et révoquer les identifiants exposés, invalider les jetons courts et les clés SSH, et supprimer tout jeton npm qui pourrait avoir été émis par les coureurs engagés. À moyen terme, une politique de construction plus stricte doit être imposée: définir des versions avec intégrité du fichier de verrouillage, désactiver l'exécution automatique des scripts d'installation dans les environnements de développement ( npm config set ignore-scripts true ou son équivalent dans d'autres gestionnaires), et préfèrent construire reproductible dans les coureurs éphémères avec des privilèges minimum. Il est également essentiel de permettre et d'examiner les mécanismes de détection dans le dépôt, tels que la numérisation des secrets et la demande d'épreuve de l'offre (SLSA); le site Web du projet SLSA fournit des conseils pratiques sur la façon d'améliorer la chaîne de confiance: https: / / slsa.dev /.

Dans la couche du système d'exploitation, ces campagnes montrent l'efficacité des charges utiles qui utilisent eBPF pour se cacher ; si votre organisation le permet, envisagez de limiter l'utilisation de eBPF pour les processus non privilégiés et évaluez l'adoption de mécanismes du noyau qui réduisent la surface, par exemple l'option de blocage du noyau (verrouillage du noyau) dans les systèmes Linux, qui empêche certains types de crochets et peut frustrer les techniques de dissimulation du processus : https: / / www.kernel / doc / html / latest / secure _ boot / lockdown.html. Du côté de la télémétrie, prioriser l'instrumentation des coureurs CI pour capturer les processus et les sockets, et configurer la rotation automatique des jetons émis par les flux de publication de confiance.

Les organisations doivent également resserrer leurs flux de contribution : appliquer la protection des directions générales qui font l'objet d'examens obligatoires, exiger des signatures vérifiées pour les engagements critiques, vérifier les comptes avec permis de publication et limiter la capacité des coureurs à délivrer des titres de compétence à long terme. Dans GitHub, il convient d'activer la numérisation des secrets et des politiques qui bloquent les erreurs d'appariement qui entrent dans des fichiers exécutables suspects; la documentation officielle sur la numérisation secrète explique la couverture et les options qui devraient être examinées: https: / / docs.github.com / en / code-security / scanning secret / about-secret-scanning.

Enfin, la réponse efficace exige une coordination : informer les détenteurs de paquets concernés, publier des instructions claires pour les utilisateurs (les versions à révoquer ou à bloquer) et partager des IoC avec la communauté afin que les outils de sécurité intègrent la détection de modèles tels que des engagements signés par des comptes suspects ou des dispositifs provenant de coureurs inhabituels. La leçon clé est que la sécurité des logiciels modernes n'est plus seulement la protection des binaires : elle protège les flux humains et automatiques qui publient, compilent et distribuent du code. La résilience de la chaîne d'approvisionnement sera à la fois technique et procédurale.