Shai-Hulud expose la faiblesse de la chaîne d'approvisionnement npm et PyPI en volant des lettres de créances avec des signatures apparentes

La campagne Shaï-Hulud a frappé à nouveau l'écosystème du paquet : des centaines d'artefacts npm et PyPI ont été publiés avec un code malveillant conçu pour voler des identifiants et se propager parmi les projets de développement. La chose la plus troublante n'est pas seulement le volume, mais la technique : les attaquants ont profité des jetons OpenID Connect (OIDC) légitimes pour signer et publier des versions malveillantes avec des attaques sources valides (SLSA Build Level 3), ce qui rend les parties compromises "cryptographiquement authentiques". Pour comprendre l'ampleur, il suffit d'examiner la recherche, par exemple Endor Labs et l ' analyse Snyk, qui documentent des centaines de versions compromises et d'artefacts et expliquent comment les attaquants enchaînés s'écrasent dans les flux CI / CD pour télécharger des paquets malveillants.

L'attaque, attribuée au groupe TeamPCP, a commencé à toucher des écosystèmes tels que TanStack et Mistral AI et s'est rapidement étendue à des projets populaires tels que Guarrails AI, UiPath et OpenSearch, y compris pour atteindre des paquets officiels tels que certains SAP et le Bitwarden CLI. Selon le post-mortem TanStack, les opérateurs enchaîné trois vecteurs: un flux dangereux de traction _ request-target, GitHub Actions cache empoisonnement et le vol de jetons OIDC à partir de la mémoire des coureurs. En outre, ils ont abusé d'un truc avec des fourchettes orphelines pour forcer npm à télécharger et exécuter le code contrôlé par l'attaquant par une unité optionnelle.

Ces techniques ont des conséquences très claires : lorsque le pipeline CI publie des paquets malveillants avec des signatures et des attaques légitimes, la confiance automatique dans la provenance n'est plus suffisante. Les développeurs qui ont installé les versions touchées doivent supposer que leurs secrets ont pu être exfiltrés. L'échantillon de malware détecté extrait des jetons et des identifiants (GitHub OIDC et PAT, jetons npm, identifiants AWS, secrets Vault, jetons de compte Kubernetes, clés SSH, fichiers .env et paramètres IDE) en lisant la mémoire des processus et fichiers connus, et utilise le réseau P2P Session pour camoufler le trafic d'exfiltration, ce qui complique les blocs et les débubs.

En plus de voler des secrets, les logiciels malveillants persistent dans l'environnement de développement : il écrit des crochets dans des outils comme Claude Code et des tâches auto-exécutables dans VS Code, de sorte que désinstaller le paquet malveillant n'efface pas l'infection. L'opération est également autopropagée : avec des identifiants volés, ils modifient les tarbales, injectent des charges utiles et republisent des versions infectées dans les paquets que l'utilisateur maintient engagés.

Dans la pratique, pour les responsables du matériel et de la sécurité, la recommandation initiale est claire : Si vous avez téléchargé une version affectée, traitez-la comme une fuite d'identité.. Vous devez immédiatement faire pivoter tous les jetons et secrets pertinents - y compris les jetons CI / CD, jetons npm, clés cloud, jetons Vault et comptes de service Kubernetes - et examiner les journaux et les configurations de CI pour détecter les publications non autorisées. Il est essentiel de vérifier le développement et les machines CI à la recherche de fichiers persistants ou de crochets malveillants (par exemple des fichiers tels que routeur _ runtime.js ou setup.mjs qui ont survécu aux installations), et de supprimer toute tâche ou configuration d'IDE que vous ne reconnaissez pas.

Au niveau de l'organisation, il convient d'examiner et de resserrer les flux d'IC/CD : éviter les flux de travail qui permettent à une demande peu fiable d'exécuter des processus avec des permis de publication, réduire la portée et la durée des jetons OIDC et utiliser des références éphémères et avec le privilège minimum. Il est également recommandé de forcer les installations de Lockfile uniquement pour empêcher les mises à jour automatiques silencieuses, et de compléter la vérification de la provenance (SLSA) par une analyse du comportement du temps d'installation et des signatures supplémentaires qui vérifient l'identité du bâtiment et l'itinéraire du workflow, et pas seulement la signature de l'artefact.

Pour atténuer des campagnes similaires à l'avenir, il est nécessaire de mettre en place des contrôles techniques et opérationnels : restreindre l'accès des coureurs, vider ou garantir la mémoire critique après des exécutions sensibles, désactiver les caches qui peuvent être empoisonnés pour des actions de publication, utiliser des coureurs éphémères et automatiser la rotation des références après des signes d'exposition. Au niveau du réseau, le blocage au niveau DNS / proxy de l'infrastructure de commande et de contrôle connue associée à cette campagne (par exemple les domaines documentés par les analyses) peut contenir l'exfiltration et les communications des attaquants.

La communauté de la sécurité a publié des listes et des guides pour identifier les versions touchées et les environnements de nettoyage : en plus des notes de recherche susmentionnées, elle examine les propres avertissements et fournisseurs de sécurité du TanStack qui ont suivi les artefacts commis. Voir le rapport de TanStack pour plus de détails sur le flux exploité et les versions publiées, et suivre les recommandations opérationnelles pour la réponse et la rotation des pouvoirs. Éviter la complaisance à l'égard des attaques valides et combiner les contrôles d'identité, l'analyse dynamique et les bonnes pratiques en IC seront essentielles pour réduire la fenêtre d'exposition à ce type de campagnes de la chaîne d'approvisionnement.