Les attaques par rançongiciel visant MongoDB sont souvent considérées comme un problème résolu, mais de nouvelles recherches de Flare montrent que la menace n'a jamais disparu.
Au lieu d'évoluer, les attaquants ont continué à appliquer la même méthode peu coûteuse et très rentable : analyser Internet à la recherche de bases de données MongoDB exposées, les effacer et exiger de modestes rançons en bitcoins d'organisations mal préparées.
« L'étude de cas sur le rançongiciel MongoDB nous enseigne plusieurs choses importantes et illustre parfaitement comment les erreurs de sécurité d'hier deviennent les modèles économiques criminels d'aujourd'hui », a déclaré Assaf Morag, chercheur en cybersécurité chez Flare, dans un e-mail adressé à eSecurityPlanet.
Il a expliqué : « Le risque n'était pas nouveau. Ce qui a changé, c'est l'efficacité avec laquelle les attaquants ont appris à l'industrialiser et à le monétiser. »
Assaf a ajouté : « En outre, il n'existe pas de vulnérabilités ou de mauvaises configurations “anciennes”. Les attaquants recherchent constamment la moindre erreur que vous commettez pour la monétiser. »
- Les attaques par rançongiciel visant MongoDB à grande échelle
- Comment fonctionnent les attaques par rançongiciel visant MongoDB
- La mauvaise configuration, et non les exploits sophistiqués, est à l'origine du risque
- Comment les images et les identifiants non sécurisés amplifient l'exposition
- Pourquoi l'exposition est plus importante que les CVE
- Comment réduire le risque de rançongiciel visant MongoDB
- Les erreurs élémentaires alimentent les rançongiciels MongoDB
Les attaques par rançongiciel visant MongoDB à grande échelle
Les chercheurs de Flare ont identifié plus de 3 100 instances MongoDB entièrement exposées à Internet, sans aucune forme d'authentification.
Parmi ces bases de données exposées, 1 416 — soit près de 46 % — avaient déjà été effacées et remplacées par des notes de rançon exigeant environ 500 $ en bitcoins.
Presque toutes ces demandes de rançon renvoyaient à seulement cinq adresses de portefeuille, un même portefeuille apparaissant dans plus de 98 % des cas, ce qui indique fortement une campagne soutenue menée par un acteur dominant plutôt qu'un ensemble de suiveurs opportunistes.
Comment fonctionnent les attaques par rançongiciel visant MongoDB
Le fonctionnement de l'attaque est simple et n'a guère changé depuis les campagnes de rançongiciel visant MongoDB documentées pour la première fois entre 2017 et 2021.
Les attaquants analysent Internet à la recherche de services MongoDB ouverts, généralement sur le port 27017, et s'y connectent directement lorsqu'aucun identifiant n'est requis.
Une fois à l'intérieur, ils recensent les bases de données, suppriment les collections et insèrent une note de rançon menaçant d'une perte définitive des données.
L'ensemble de l'opération ne nécessite ni logiciel malveillant, ni élévation de privilèges, ni déplacement latéral, et les victimes qui choisissent de payer déclarent souvent ne rien recevoir en retour — ce qui entraîne une perte irréversible des données.
La mauvaise configuration, et non les exploits sophistiqués, est à l'origine du risque
À la base, les rançongiciels MongoDB exploitent les mauvaises configurations plutôt que les vulnérabilités logicielles.
De nombreuses instances exposées résultent de configurations par défaut ou copiées qui lient MongoDB à toutes les interfaces réseau sans imposer d'authentification.
Ces pratiques non sécurisées sont généralement propagées par des images Docker, des tutoriels en ligne et des configurations d'exemple conçues pour faciliter l'utilisation ou les tests, mais ensuite réutilisées dans des environnements de production.
Comment les images et les identifiants non sécurisés amplifient l'exposition
Flare a identifié 763 images de conteneurs sur Docker Hub contenant cette configuration de liaison non sécurisée, réparties dans 30 espaces de noms.
Si nombre de ces images étaient peu utilisées, les chercheurs ont également découvert des projets largement adoptés totalisant plus de 15 000 téléchargements et utilisant la même configuration.
Lorsqu'elles sont déployées avec des mappages de ports publics ou un réseau hôte, ces images peuvent instantanément transformer une base de données en cible accessible depuis Internet.
L'exposition des identifiants amplifie encore le risque.
Les chercheurs ont découvert des milliers d'identifiants MongoDB divulgués dans des dépôts GitHub, des registres de conteneurs, des sites de partage de textes et des forums du dark web, dont beaucoup étaient encore valides.
Associés à des services exposés, ces identifiants divulgués créent un écosystème facile à exploiter qui permet aux attaquants d'étendre leur extorsion sans exploiter la moindre CVE.
Pourquoi l'exposition est plus importante que les CVE
Bien que Shodan ait identifié plus de 200 000 serveurs MongoDB détectables sur Internet, seul un petit sous-ensemble — environ 3 100 — était entièrement exposé sans contrôles d'accès.
Si de nombreux serveurs révélaient des vulnérabilités connues, la plupart correspondaient à des problèmes à faible impact, comme des situations de déni de service.
Le principal risque observé ne venait pas de logiciels non corrigés, mais de l'accès sans authentification permis par une mauvaise configuration persistante.
Comment réduire le risque de rançongiciel visant MongoDB
Les attaques par rançongiciel visant MongoDB persistent parce qu'elles tirent parti de lacunes fondamentales dans le déploiement et les contrôles d'accès, et non de vulnérabilités sophistiquées.
Réduire le risque ne nécessite pas d'outils complexes, mais exige une configuration rigoureuse, une visibilité continue et une solide préparation opérationnelle.
- Évitez d'exposer MongoDB à l'Internet public en limitant l'accès aux réseaux privés, VPN ou aux hôtes bastions.
- Imposez une authentification forte, le RBAC et le principe du moindre privilège pour tous les utilisateurs et services de la base de données.
- Renforcez les contrôles réseau en bloquant le port 27017 depuis les accès entrants publics et en appliquant des règles strictes de pare-feu ou des politiques réseau Kubernetes.
- Sécurisez les déploiements de conteneurs et de CI/CD en éliminant les paramètres par défaut non sécurisés, les configurations copiées-collées et les outils de gestion exposés publiquement.
- En continu, surveiller les expositions, anormales des bases de données, ainsi que les identifiants divulgués, à l'aide d'outils de sécurité du cloud et de gestion de la surface d'attaque.
- Protégez l'intégrité des données avec des sauvegardes immuables, la rotation des identifiants et un contrôle des flux sortants afin de limiter l'exfiltration et l'impact sur la restauration.
- Testez et mettez régulièrement à jour les plans de réponse aux incidents afin d'assurer une détection, un confinement et une reprise rapides en cas d'exposition de bases de données ou d'extorsion.
Ces mesures aident les organisations à limiter l'ampleur des dégâts et à renforcer leur résilience.
Les erreurs élémentaires alimentent les rançongiciels MongoDB
Les rançongiciels MongoDB montrent comment certaines des menaces les plus persistantes réussissent non pas grâce à des exploits sophistiqués, mais en exploitant des fondamentaux négligés.
À mesure que les environnements cloud natifs évoluent et que les infrastructures sont rapidement réutilisées, de petits raccourcis de configuration peuvent discrètement se transformer en une exposition systémique à long terme.
Des situations comme celle-ci poussent les organisations à remettre en question la confiance implicite dans les infrastructures et à adopter des modèles zero trust qui vérifient continuellement les accès.