36 packages npm malveillants déguisés en plugins Strapi ciblent l'écosystème Guardarian

36 faux plugins Strapi : une attaque supply chain à évolution rapide contre la fintech

La sophistication des attaques supply chain sur npm ne cesse de progresser. Après la compromission d’Axios et les campagnes ciblant les développeurs Python et Ruby, une nouvelle opération vient d’être documentée par SecurityWeek et CybersecurityNews : 36 packages malveillants se faisant passer pour des plugins officiels ou populaires de Strapi CMS, ciblant spécifiquement l’écosystème Guardarian, une plateforme fintech et crypto.

Ce qui distingue cette campagne des attaques supply chain habituelles, c’est la vitesse d’évolution des payloads : 8 variantes distinctes déployées en seulement 13 heures, témoignant d’une opération active et adaptative pilotée en temps réel par ses opérateurs.

Strapi CMS : une cible stratégique

Strapi est un headless CMS open source parmi les plus populaires de l’écosystème Node.js. Il est largement utilisé dans les projets fintech, e-commerce et SaaS pour gérer le contenu backend via une API REST ou GraphQL. Son architecture extensible repose sur un système de plugins, ce qui en fait un vecteur d’attaque particulièrement intéressant : les développeurs sont habitués à installer des plugins tiers via npm, réduisant leur vigilance face à des packages au nom similaire à des plugins officiels.

Les 36 packages identifiés utilisaient des noms imitant des plugins Strapi connus, avec des variations subtiles (typosquatting, ajout de préfixes ou suffixes, utilisation du scope @strapi-community non officiel). Plusieurs packages avaient atteint des centaines d’installations avant leur détection.

L’écosystème Guardarian dans le viseur

Guardarian est une plateforme fintech permettant l’achat et la vente de cryptomonnaies. Son infrastructure technique repose partiellement sur Strapi pour la gestion de contenu et d’API internes. En ciblant des packages mimant l’écosystème Strapi, les attaquants espéraient atteindre des développeurs travaillant sur ou avec Guardarian.

Cette ciblage sectoriel n’est pas anodin : les plateformes crypto et fintech manipulent des clés privées, des credentials d’API d’exchange, des secrets de portefeuilles numériques et des données KYC sensibles. Un accès à l’environnement de développement d’une telle plateforme représente un gain potentiel considérable.

Anatomie des 8 variantes de payloads

L’aspect le plus frappant de cette campagne est l’évolution rapide des charges utiles. En 13 heures, les attaquants ont déployé 8 variantes distinctes, chacune ajoutant ou modifiant des capacités :

Variante 1-2 : Reconnaissance et exfiltration initiale

Les premières versions se contentaient de collecter des informations sur l’environnement cible : variables d’environnement, chemins de fichiers de configuration, présence de fichiers .env, et envoi vers un serveur distant via requête HTTP. Simple mais efficace pour cartographier la cible.

Variante 3 : RCE via Redis

La troisième variante introduit une technique plus avancée : exploitation de Redis non protégé (souvent présent dans les environnements Strapi pour le caching) pour obtenir une exécution de code à distance. Redis mal configuré sans authentification peut être instrumentalisé pour écrire des fichiers sur le système hôte, permettant l’exécution de commandes arbitraires.

Variante 4 : Exploitation PostgreSQL

Une variante similaire ciblant PostgreSQL, base de données par défaut de Strapi. Les credentials de connexion, souvent stockés en clair dans les fichiers de configuration Strapi ou les variables d’environnement, permettent l’accès direct à la base de données et l’exécution de commandes via les fonctions d’administration de PostgreSQL.

Variante 5 : Évasion de conteneur Docker

Cette variante tente de détecter si l’environnement s’exécute dans un conteneur Docker et, si c’est le cas, d’exploiter des configurations Docker incorrectes (volumes montés depuis l’hôte, socket Docker exposé, capabilities élevées) pour s’échapper du conteneur et atteindre le système hôte.

Variante 6 : Reverse shell persistant

Une charge utile établissant un reverse shell vers l’infrastructure des attaquants, avec mécanisme de persistance via cron job ou service systemd selon l’environnement détecté.

Variante 7 : Vol de credentials ciblé

Recherche et exfiltration de fichiers spécifiques : clés SSH, fichiers de configuration AWS (~/.aws/credentials), tokens GitHub (~/.gitconfig), secrets de portefeuilles crypto, et tout fichier contenant des patterns correspondant à des secrets (tokens Bearer, clés API au format JWT ou Base64).

Variante 8 : Implant persistant multi-stage

La variante finale et la plus sophistiquée : un implant léger s’installant comme dépendance système, capable de recevoir des mises à jour de payload depuis l’infrastructure C2, et se dissimulant dans les processus Node.js légitimes pour éviter la détection.

Évolution en temps réel : une opération pilotée activement

Le fait que 8 variantes aient été déployées en 13 heures indique une opération pilotée en temps réel par ses opérateurs. Chaque nouvelle variante répondait probablement à des feedbacks de l’infrastructure C2 : tel payload n’a pas fonctionné sur les environnements cibles (PostgreSQL absent, Docker non utilisé), donc une nouvelle variante est déployée en tentant une approche différente.

Cette adaptabilité rapide est caractéristique d’une équipe organisée et expérimentée, pas d’un individu isolé.

Mesures de protection

Pour les développeurs utilisant Strapi :

• Vérifiez l’ensemble de vos dépendances npm liées à Strapi. Comparez les noms de packages installés avec la liste officielle des plugins Strapi.
• Auditez votre package-lock.json pour identifier tout package au nom inhabituel ou au scope non officiel.
• Analysez vos variables d’environnement et fichiers de configuration pour identifier les secrets potentiellement exposés.

Pour les équipes de sécurité :

• Intégrez des outils d’analyse comportementale des packages (Socket.dev, Snyk Open Source) dans vos pipelines CI/CD.
• Configurez des alertes sur les nouvelles installations de packages dans les environnements de développement sensibles.
• Assurez-vous que Redis, PostgreSQL et le socket Docker ne sont jamais exposés sans authentification dans les environnements de développement.

Pour les plateformes fintech et crypto :

• Effectuez un audit de la chaîne d’approvisionnement logicielle complet, en particulier sur les composants Node.js.
• Mettez en place une politique de revue obligatoire pour tout nouveau package npm ajouté aux projets critiques.
• Utilisez un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager) plutôt que des variables d’environnement en clair pour les credentials sensibles.

Lectures recommandées

Ces liens sont des liens affiliés. Si vous effectuez un achat via ces liens, nous pouvons recevoir une commission, sans coût supplémentaire pour vous.

• Pro Cybersécurité : couverture des attaques supply chain dans les écosystèmes open source et méthodes de sécurisation des pipelines de développement.
• Fondamentaux de la cybersécurité : concepts fondamentaux pour comprendre les vecteurs d’attaque ciblant les environnements de développement et les dépendances tierces.
• NordPass : protégez vos credentials de développement (tokens npm, clés API, secrets d’environnement) avec un gestionnaire de mots de passe sécurisé.

Sources

• Guardarian Users Targeted with Malicious Strapi npm Packages - SecurityWeek
• 36 Malicious npm Strapi Packages - Cybersecurity News