36 Packages npm Malveillants : Exploitation de Redis & PostgreSQL
Les faits
Récemment des analystes ont identifié 36 packages malveillants publiés sur npm qui se faisaient passer pour des plugins Strapi. Ces paquets, nommés à la ressemblance d'extensions populaires, contenaient une logique activée au moment de l'installation permettant d'extraire des identifiants, d'exploiter Redis et PostgreSQL, d'installer des shells inverses et de déployer des implants persistants. La découverte a été rapportée en avril 2026 après l'alerte d'un utilisateur vigilant et des scans automatisés qui ont confirmé la dangerosité des packages¹.
Sur le plan technique, l'architecture était répétitive et conçue pour agir au plus tôt du cycle de déploiement. Chaque package comportait un package.json minimal, un index.js apparemment inoffensif et surtout un script postinstall.js exécuté par npm ou yarn lors de l'installation. Ce postinstall scanne les variables d'environnement (DATABASE_URL, REDIS_URL, PGHOST, PGUSER, PGPASSWORD) et les fichiers de configuration (.env, config/*.js) à la recherche d'identifiants utilisables. Lorsqu'il trouve des informations valides, il tente des connexions et exploite des configurations laxistes pour obtenir un accès et déposer une porte dérobée¹.
Concrètement, les actions observées comprenaient l'abus d'API Redis permissives (par exemple CONFIG SET pour écrire des fichiers et SAVE pour les matérialiser), des requêtes PostgreSQL visant à activer des extensions comme plpythonu pour exécuter des commandes système, l'ajout de clés SSH à ~/.ssh/authorized_keys, l'écriture de scripts cron, et le déploiement de payloads via curl vers un hôte de commande et contrôle. Ces techniques exploitent des comptes et des configurations trop permissifs plutôt qu'une vulnérabilité zero-day dans npm lui-même¹.
Un pseudocode synthétique des étapes du postinstall retrouvé dans plusieurs packages illustre le schéma général:
- lire variables d'environnement et fichiers de configuration
- si REDIS_URL présent: tenter la connexion; exécuter CONFIG SET dir "/tmp"; CONFIG SET dbfilename "x.so"; SAVE
- si PostgreSQL accessible: exécuter CREATE EXTENSION plpythonu; appeler une fonction PL/Python qui lance un subprocess pour récupérer un payload
- déployer un script persistant dans /etc/cron.daily ou ajouter une clé SSH à authorized_keys
- ouvrir un shell inverse vers l'adresse de l'attaquant
Ce mode opératoire fonctionne dès lors que l'environnement d'exécution a des droits suffisants et que les bases de données sont exposées ou configurées sans le principe du moindre privilège¹.
Contexte
L'écosystème JavaScript et son registre centralisé ont déjà été la cible régulière de campagnes de typosquatting et d'abus de scripts lifecycle. Les scripts d'installation automatiques comme postinstall offrent une surface d'attaque simple et efficace pour introduire du code malveillant pendant le déploiement. Des analyses précédentes ont documenté ces tactiques et leurs variantes, et montrent que les chaînes d'approvisionnement JavaScript exigent une vigilance continue²³.
Trois vecteurs historiques expliquent pourquoi cette campagne a pu prospérer:
- typosquatting et usurpation de noms pour provoquer des installations accidentelles
- abus des scripts lifecycle de npm, qui sont exécutés automatiquement sans contrôle manuel dans de nombreux pipelines de build²
- configurations de bases de données permissives: Redis sans authentification ou PostgreSQL avec comptes trop privilégiés, permettant l'exécution de commandes système via des extensions³
La détection initiale de ces 36 paquets a reposé sur la combinaison de scans automatisés et d'une analyse humaine capable de repérer des métadonnées manquantes (pas de repository, description vide) et la présence systématique d'un postinstall.js suspect¹². Plus largement, les organisations qui automatisent la vérification des métadonnées de packages dans leurs pipelines réduisent le risque d'installation accidentelle.
Réactions et conséquences
Registries et opérateurs ont répondu en supprimant les packages signalés afin d'arrêter de nouvelles installations¹. Ce retrait est une mesure nécessaire, mais il ne protège pas les systèmes déjà compromis.
Pour les entreprises concernées, l'impact peut être large: fuite d'identifiants, portes dérobées installées, mouvement latéral vers d'autres services et nécessité de restaurations à grande échelle.
Sur le plan opérationnel, une compromission détectée exige souvent la mise hors-service d'instances, l'audit complet des images et des systèmes de fichiers, et la reconstruction d'environnements depuis des sources sûres. Les coûts directs et indirects incluent le temps d'intervention, la perte de disponibilité et l'atteinte à la confiance des clients. D'un point de vue tactique, les attaquants ont misé sur des mécanismes simples mais efficaces pour maximiser leur persistance et leur capacité de commandement et contrôle¹.
Mesures immédiates et recommandations opérationnelles
Voici des actions concrètes à exécuter dès la découverte ou la suspicion d'une compromission liée à ces paquets:
- Auditer les dépendances: rechercher les noms signalés dans package-lock.json et yarn.lock; scanner node_modules pour la présence systématique d'un postinstall.js; vérifier package.json pour l'absence de repository ou de description. L'usage d'un outil SCA permet d'automatiser une grande partie de cette recherche¹².
- Bloquer temporairement l'exécution des scripts d'installation dans vos pipelines: exécuter npm install --ignore-scripts ou configurer le CI pour interdire les scripts lifecycle, en évaluant l'impact sur les builds.
- Isoler et traiter les bases de données compromises: couper l'accès réseau public, révoquer et régénérer les identifiants suspects, restaurer depuis des sauvegardes intègres et auditer les logs pour gestes post-compromission.
- Appliquer le principe du moindre privilège: créer des comptes applicatifs avec droits strictement limités; désactiver les extensions PostgreSQL inutiles; interdire les commandes système via des extensions non nécessaires³.
- Durcir Redis: activer l'authentification, limiter les commandes sensibles via ACL si disponible, et restreindre l'accès réseau aux seuls hôtes applicatifs autorisés.
- Surveiller les indicateurs de compromission: connexions sortantes inhabituelles, ajouts à ~/.ssh/authorized_keys, tâches cron créées, fichiers .so ou binaires écrits dans /tmp ou /var.
- Rebuild et nettoyage: supprimer artefacts suspects et reconstruire conteneurs et images VM à partir du code source vérifié; réinstaller dépendances depuis un miroir privé ou via listes blanches.
- Mettre en place des scans SCA et des contrôles de métadonnées: Snyk, Dependabot, et solutions équivalentes aident à détecter les packages sans dépôt, avec scripts lifecycle suspects, ou présentant d'autres signaux de danger²³.
Checklist rapide pour les équipes DevOps/Sec:
- isoler les services exposés
- exécuter npm install --ignore-scripts dans un environnement de test
- extraire et analyser les packages installés
- révoquer les secrets potentiellement exposés
- reconstruire images et redéployer depuis code contrôlé
Observations finales
Cette campagne rappelle que la sécurité des chaînes d'approvisionnement s'appuie sur deux axes: la discipline dans la gestion des dépendances et le renforcement des configurations d'infrastructure. Traiter vos dépendances comme des composants non fiables jusqu'à preuve du contraire réduit considérablement la surface d'attaque. Les registres font leur part en retirant les packages malveillants, mais la responsabilité opérationnelle de protection incombe aux équipes de développement et d'exploitation sur le terrain¹²³.
Ressources et documentation complémentaires pour approfondir: analyses publiques du cas et analyses générales sur les attaques de la chaîne d'approvisionnement JavaScript ¹²³.
