36 Malicious npm Packages Exploited Redis and PostgreSQL Security
Les faits
Des chercheurs ont récemment identifié 36 packages malveillants publiés sur le registre npm, présentés comme des plugins pour Strapi, un CMS populaire. Ces packages n'avaient ni description utile, ni dépôt associé et pas de mots-clés pertinents, ce qui doit attirer la méfiance lors d'un examen manuel. Chaque package comprenait uniquement trois fichiers : package.json, index.js et postinstall.js. Le vecteur d'infection commun est le script postinstall, exécuté automatiquement lors de l'installation d'une dépendance et capable de lancer des commandes système sur la machine qui réalise l'installation¹.
Concrètement, le script postinstall a été utilisé pour plusieurs objectifs malveillants. Certains packages tentaient d'exploiter des bases de données mal configurées, en particulier Redis et PostgreSQL, en se connectant à des instances exposées et en testant des identifiants par défaut pour obtenir un accès. D'autres installaient des shells inverses ou exécutaient des commandes à distance vers des serveurs contrôlés par les attaquants. Des routines de collecte cherchaient des fichiers de configuration et des secrets (par exemple des .env) pour voler des identifiants et des clés API. Enfin, des mécanismes de persistance permettaient de relancer le code malveillant après un redémarrage, par exemple par la création de tâches planifiées ou l'implantation de services locaux¹.
Les indicateurs techniques à relever incluent l'absence de dépôt public lié au package, la présence d'un script postinstall qui lance des appels réseau, des connexions sortantes vers des ports inhabituels, et la création d'unités systemd ou de cron jobs après une installation. Ces signes doivent déclencher une enquête immédiate.
Contexte
Ce cas n'est pas isolé. L'abus des scripts lifecycle npm, et du script postinstall en particulier, est un vecteur connu depuis plusieurs années. Les scripts postinstall s'exécutent dans de nombreux environnements de développement et dans les runners CI/CD, souvent sans contrôle strict, ce qui crée une surface d'attaque importante. Des publications techniques et des analyses de sécurité ont documenté des campagnes similaires où de faux packages injectent du code pour exfiltrer des secrets ou miner des cryptomonnaies².
Parallèlement, les attaques ciblant des bases de données exposées ont augmenté avec la prolifération d'infrastructures cloud mal configurées. Redis est fréquemment cité comme une cible privilégiée car il est parfois déployé sans mot de passe et accessible depuis Internet, facilitant des compromissions rapides. L'exploitation de bases de données mal protégées est une tactique répandue pour établir un point d'ancrage et obtenir des informations sensibles³.
Ces comportements s'inscrivent dans un problème plus large, la sécurité de la chaîne logistique logicielle. Les dépendances open source deviennent une entrée possible pour des logiciels malveillants si les acteurs qui publient ou maintiennent ces composants ne sont pas scrutés. Protéger les pipelines de livraison et limiter l'exécution de code non approuvé sont des éléments clés pour réduire ces risques³.
Risque opérationnel
Pour une entreprise, l'impact peut être immédiat. Un runner CI/CD qui installe des dépendances lors d'un build sans restriction peut exécuter un postinstall malveillant et livrer au pirate des secrets et des accès réseau. Une fois en possession de ces éléments, l'attaquant peut effectuer de la reconnaissance, se déplacer latéralement et exfiltrer des données. La compromission d'environnements de développement ou d'intégration peut provoquer la fuite de credentials, d'API keys et de données personnelles, avec des conséquences réglementaires et financières importantes.
Les exemples concrets incluent la perte de secrets utilisés pour déployer en production, la compromission d'artefacts signés et la mise en place d'implantations persistantes sur des systèmes de build. La remédiation peut exiger la rotation massive de secrets, des audits forensiques et des périodes d'indisponibilité pour nettoyer les environnements affectés. Ces opérations ont un coût direct et un coût réputationnel pour les organisations concernées.
Réactions et mesures
Les registres de packages et des équipes de sécurité ont déjà agi pour supprimer les packages signalés et partager des recommandations. Des bonnes pratiques à mettre en place immédiatement :
- Désactiver l'exécution automatique des scripts npm sur les runners CI/CD (npm config set ignore-scripts true) et privilégier des builds reproductibles qui n'exécutent pas de code tiers durant l'installation.
- Scanner systématiquement les fichiers de lock (package-lock.json, yarn.lock) pour repérer des ajouts suspects et intégrer des politiques de blocage des packages non approuvés.
- Isoler les runners CI/CD du réseau de production et restreindre le trafic sortant pour empêcher des connexions directes vers des serveurs malveillants.
- N'utiliser que des artefacts de dépendances validés et mis en cache dans un registre interne approuvé plutôt que d'installer directement depuis le registre public.
- Surveiller les machines de build et les postes développeurs pour des signes de compromission : processus inconnus, créations d'unités systemd ou de cron jobs, connexions sortantes vers des IP ou des ports inhabituels.
- Procéder à la rotation immédiate des secrets identifiés comme compromis et révoquer les accès si une exfiltration est suspectée.
Ces mesures s'alignent sur les recommandations de recherche sur la sécurisation des chaînes logicielles et des pipelines CI/CD³. Elles réduisent la probabilité qu'un postinstall malveillant puisse atteindre des ressources sensibles.
Mise en pratique pour les équipes
Pour une mise en oeuvre pragmatique, voici un plan en plusieurs étapes :
- Audit initial : inventorier où les installations npm sont réalisées, quels runners CI existent et quelles permissions réseau ils possèdent.
- Durcissement des runners : appliquer ignore-scripts, exécuter les builds dans des conteneurs sandboxés, limiter les privilèges et restreindre l'egress.
- Gouvernance des dépendances : créer un registre miroir interne, exiger une revue des changements de lockfile, automatiser des scans SCA (software composition analysis).
- Surveillance et réponse : définir règles de détection pour les modifications système post-install, centraliser les logs réseau et prévoir un playbook d'urgence pour isoler et analyser un runner compromis.
- Formation : sensibiliser les développeurs et les équipes DevOps aux signaux d'alerte et aux procédures à suivre lors de la découverte d'un package suspect.
Appliquer ces pratiques permet de transformer la sécurité de la chaîne d'approvisionnement logicielle en un processus maîtrisé plutôt qu'en une source d'incertitudes.
À retenir
La découverte de 36 packages npm malveillants ciblant Redis et PostgreSQL rappelle que la sécurité des dépendances et des pipelines ne peut pas être traitée comme un simple réflexe. Il faut combiner contrôles techniques, gouvernance des dépendances et vigilance opérationnelle pour limiter la surface d'attaque. Les organisations disposant de runners CI/CD exposés, de bases de données accessibles ou de politiques permissives sur l'exécution de scripts doivent prioriser les mesures listées ci-dessus pour réduire le risque de compromission¹²³.
