208500 Mongol DB a exposé l'extorsion facile qui convertit les bases de données en Bitcoin

Dans le paysage actuel de la cybersécurité, il y a des attaques qui préfèrent la subtilité et d'autres qui vont à la dure : ceux qui profitent des configurations ouvertes et en font de l'argent rapide pour les criminels. Dans ce cas, les points sont des exemples de MongolDB exposés à Internet sans les protections minimales, et la tactique récurrente est simple et rentable: une suppression automatique suivie d'une note de sauvetage avec une modeste demande en Bitcoin.

Une étude de la société de sécurité Flare a détecté un nombre alarmant de fonctionnaires de MongolDB : plus de 208 500 cas visibles sur Internet, dont environ 100 000 informations opérationnelles filtrées et environ 3 100 étaient disponibles sans aucune authentification. Lorsque les enquêteurs ont inspecté ce groupe sans contrôle d'accès, ils ont constaté qu'environ 45,6 % étaient déjà intervenus. Dans de nombreux cas, la base de données avait été vidée et avait laissé une instruction de payer 0,005 BTC - qui aujourd'hui 500 à 600 dollars- si le propriétaire voulait que les agresseurs "restaurent" l'information. Le rapport Flare peut être lu en détail dans sa publication technique: Flamme: Mongol Activité de rançon DB.

Ce type d'extorsion n'est pas nouveau; il y a eu des vagues précédentes les années précédentes où des milliers de bases de données ont été supprimées ou cryptées. Ces campagnes de masse ont montré que le cœur du problème n'est pas une vulnérabilité complexe de zéro jour, mais des erreurs de base de l'exposition et de l'absence d'authentification. Un historique des incidents liés aux bases de données ouvertes a été couvert par les médias de sécurité, par exemple dans l'article de Brian Krebs sur les bases de données MongolDB laissées sans protection : KrebsOnSécurité.

Au-delà de l'impact immédiat, il y a des signes qui aident à façonner l'agresseur. Flare a identifié seulement cinq adresses de portefeuilles dans les notes de sauvetage et l'une d'elles est apparue dans la grande majorité des cas, suggérant une opération automatisée et répétitive par le même acteur. Les chercheurs soulèvent également la possibilité que de nombreux cas exposés qui n'ont pas montré de signes d'effacement auraient pu auparavant payer pour éviter ou inverser les dommages, bien que ce ne soit pas quelque chose qui peut être confirmé en général.

Il est important de souligner que le paiement ne garantit rien : les extorseurs promettent de restaurer des données, mais il n'y a aucune certification qu'ils ont des copies utiles ou qu'ils se conformeront. C'est ce que souligne explicitement l'analyse de Flare : les paiements ne garantissent pas le recouvrement.

Pourquoi ces attaques fonctionnent-elles encore ? Parce qu'ils sont la définition de « fruits à portée de main » : les intrusions sont basées sur un accès illimité, des mots de passe par défaut ou des configurations copiées de guides de déploiement sans adapter la sécurité. En outre, une population considérable de serveurs exécutant d'anciennes versions de MongolDB se trouve: Flare a trouvé près de 95 000 cas exposés avec des versions sensibles aux pannes de n-jour. Dans de nombreux cas, la gravité de ces défaillances se limite au déni de service, mais la combinaison de logiciels périmés et de configuration médiocre multiplie le risque mondial.

Si vous administrez MongolDB ou avez des responsabilités en matière d'infrastructure de base de données, il est approprié de prendre des mesures pratiques et réalistes: éviter d'exposer des instances au public, sauf si cela est strictement nécessaire, activer des mécanismes d'authentification robustes, appliquer des règles de pare-feu et des politiques de réseau (y compris dans Kubernetes) qui limitent les connexions à des origines fiables, et ne pas réutiliser des configurations d'exemple sans les examiner. Mongol DB maintient un guide de bonnes pratiques de sécurité utile comme point de départ: MongolDB Liste de contrôle de sécurité.

En cas d'exposition ou d'engagement, les mesures recommandées sont claires : isoler l'instance, faire pivoter les références, examiner les dossiers pour détecter les activités non autorisées et restaurer de la sauvegarde propre. En outre, l'intégration d'une surveillance continue et d'un balayage régulier de la surface d'attaque réduit la probabilité qu'un serveur reste ouvert sans que personne ne le remarque. Outils publics comme Shodan permettre de vérifier si un service est visible depuis Internet, bien que son utilisation doit faire partie d'une stratégie défensive et avec les autorisations correspondantes.

Il n'y a pas de formules magiques contre l'extorsion, mais il y a des pratiques avec un fort rendement sur les investissements de sécurité. La prévention - la mise à jour du logiciel, le segmentage des réseaux, l'utilisation d'une authentification forte et la conservation d'une sauvegarde vérifiée - est ce qui sépare ceux qui souffrent d'une suppression et d'une note de sauvetage de ceux qui détectent simplement une tentative et la ferment avant qu'elle ne soit adressée aux personnes âgées. Et en cas de doute, documenter les incidents et les communiquer aux équipes d'intervention et, le cas échéant, aux autorités compétentes, aide à identifier les tendances et à atténuer les campagnes automatisées de ce type.

Si vous souhaitez approfondir la situation et revoir les chiffres et les recommandations techniques, en plus du rapport mentionné par Flare, vous pouvez consulter des ressources et des nouvelles de sécurité spécialisées pour comprendre l'évolution de ces campagnes et garder vos actifs protégés: Feu la documentation officielle MongolDB et les plates-formes de recherche de services publics, Shodan.