Plus de 28 000 bases MongoDB ont été effacées contre rançon
La foire aux données
Le 10 janvier 2017 à 08h35
3 min
Internet
Internet
Le danger s’accroit pour les bases MongoDB qui seraient mal configurées. Alors que l’on comptait en milieu de semaine dernière environ 2 000 bases attaquées, on se rapproche désormais des 30 000. Le problème est toujours le même : l’absence de mise à jour et de configuration adaptée.
La semaine dernière, nous indiquions qu’environ 1 800 bases de données MongoDB avaient été vidées de leurs données par un pirate agissant sous le nom Harak1r1. Avant d’effacer les contenus, il les téléchargeait puis demandait une rançon de 0,2 bitcoin pour les récupérer. Jeudi dernier, seules 18 victimes avaient accepté de payer, la somme n’étant guère élevée. À l’heure où nous écrivons ces lignes, ce chiffre a légèrement augmenté : 26.
2 000 bases, puis 10 500, puis 28 000...
Mais en quelques jours, la situation a largement évolué. Les multiples articles ayant tiré la sonnette d’alarme ont également braqué la lumière sur une situation qui ne demandait finalement qu’à être exploitée par d’autres. Dès vendredi dernier, le nombre de bases exploitées grimpait ainsi déjà à 10 500, selon Victor Gevers qui avait découvert le problème.
Gevers et un autre chercheur, Niall Merrigan, ont suivi l’évolution de ces attaques de près. Dimanche, le nombre de victimes atteignait presque les 27 000. À l’heure actuelle, il est précisément de 28 322 bases attaquées et vidées, les statistiques étant maintenues dans un tableau Google Sheets.
Presque 100 000 bases piratables
On peut y voir que le pirate Harak1r1 a fait jusqu’à présent 4 174 victimes précisément. Cependant, avec l’envolée du nombre de bases attaquées, on se doute bien que d’autres se sont lancés dans la même activité. Celui qui possède l’adresse [email protected] a ainsi attaqué et vidé plus de 16 000 bases MongoDB, selon le même mode opératoire que Harak1r1. À la différence près qu’il réclame dans la plupart des cas 1 bitcoin, soit environ 860 euros. Pour l’instant, personne ne semble avoir payé autant, mais 67 ont accepté de verser 0,1 bitcoin quand cela leur était demandé.
Si on se rapproche des 30 000 bases attaquées, il reste encore de la marge aux pirates. Comme le signale en effet The Hackers News, le moteur de recherche spécialisé Shodan indique que 99 000 environ ont les caractéristiques nécessaires.
D’après le tableau des deux chercheurs, une quinzaine de pirates se sont lancés dans cette activité qu’ils espéraient sans doute lucrative. Les informations publiées par les chercheurs et la presse ont sans doute contribué à décider quelques autres pirates à se lancer dans l’aventure, certains très sérieusement d’ailleurs.
Les avertissements à double-tranchant
Malheureusement, il n’existe guère de moyen efficace d’avertir les victimes potentielles sans ébruiter la situation. Les bases concernées sont toujours anciennes, créées le plus souvent dans des instances sur des plateformes de cloud comme AWS (Amazon Web Services). Une fois en place, elles ne sont plus mises à jour et la configuration y est minimale. Pour rappel, les administrateurs concernés ont laissé ouvert la possibilité de se connecter à distance sans même exiger des identifiants. Un comportement que MongoDB avait déjà modifié, mais beaucoup n’ont pas installé les moutures suivantes.
Notez que MongoDB a également publié la semaine dernière un billet de blog centré sur ces attaques, et surtout la manière de les éviter.
Plus de 28 000 bases MongoDB ont été effacées contre rançon
-
2 000 bases, puis 10 500, puis 28 000...
-
Presque 100 000 bases piratables
-
Les avertissements à double-tranchant
Commentaires (59)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 10/01/2017 à 16h28
Franchement vous plaisantez, vous pouvez pas mettre ça sur le dos des dev MongoDB
J’ai acheté mon cadenas il était par défaut à 0000, je savais pas, du coup on m’a tout piqué! REMBOURSEZ!
" /> " />
Le sens de la justice US fait des émules par chez nous, what could possibly go wrong?
Le 10/01/2017 à 16h42
Le 10/01/2017 à 16h46
Ceci dit il y a fort à parier que parmi les bases piratées, il y a un bon pourcentage de déchets, des bases abandonnées ou utilisées pour des choses tout à fait secondaires, qui expliqueraient un tel laxisme.
Le 10/01/2017 à 17h50
Le 10/01/2017 à 19h10
Hum ?
Le 10/01/2017 à 19h30
Bonne nouvelle, si ca permet aux “directeurs” de comprendre qu’un bon sysadmin ca se paye…
… ou que, sinon, on finit par le payer.
Le 10/01/2017 à 19h53
" />
" />
Le 10/01/2017 à 21h58
Si ils ont un peu de temps devant eux, le memento “La défense en profondeur appliquée aux systèmes d’information” mis en avant par l’ANSSI est aussi intéressant à lire.
Le 11/01/2017 à 14h44
Si on enlève les bases de tests, le bases de formation les autres bases sans objet opérationnel et les bases oubliés dans un coin, il reste combien de base réellement qui ont une valeur ?
Simplement le fait que le prix de la rançon soit dérisoire est un signe. Sinon ça montrait bien plus haut …
Le 11/01/2017 à 14h44
Si on enlève les bases de tests, le bases de formation les autres bases sans objet opérationnel et les bases oubliés dans un coin, il reste combien de base réellement qui ont une valeur ?
Simplement le fait que le prix de la rançon soit dérisoire est un signe. Sinon ça montrait bien plus haut …
Le 11/01/2017 à 14h44
Si on enlève les bases de tests, le bases de formation les autres bases sans objet opérationnel et les bases oubliés dans un coin, il reste combien de base réellement qui ont une valeur ?
Simplement le fait que le prix de la rançon soit dérisoire est un signe. Sinon ça montrait bien plus haut …
Le 12/01/2017 à 16h48
Le 10/01/2017 à 08h42
Cela en fait des sommes potentiels." />
Un de ces jours, certains en auront marre, et engagerons des personnes pour péter quelques rotules." />
Le 10/01/2017 à 08h46
SI je ne me trompe pas, MongoDB avait déjà été pointé du doigt sur le problème de sécurité de la configuration par défaut… c’était il y a plus d’un an, non?
Edit : Affectivement oui, NXI avait même fait un article
Le 10/01/2017 à 08h46
Petite erreur de type : “Le danger s’accroit pour les bases MongoDB qui seraient mal configurées”.
D’un côté c’est triste de voir que certains “admin” n’ont strictement aucune notion de sécurité. Une BDD accessible à distance sans aucune identification, c’est un peu comme laisser une voiture avec les clés sur le contact et les portes ouvertes…
Le 10/01/2017 à 08h48
Et çà continue encore et encore
Ce n’est que le début d’accord, d’accord…
Quelque chose vient de tomber
le sysadmin sur le plancher
Il y a toujours des bases qui s’effacent
Libérer de l’espace,
Les data sont éparses…
" />
Le 10/01/2017 à 08h49
Et le coffre rempli de cadeaux
Le 10/01/2017 à 08h50
La base Mongo dans ma boite n’est accessible que par le réseau interne. " />
Quelqu’un a des astuces pour mieux la sécuriser? Elle n’héberge pas de service critique, mais bon.
Le 10/01/2017 à 08h51
Le 10/01/2017 à 08h52
Le 10/01/2017 à 08h52
Le 10/01/2017 à 08h53
Les bases concernées sont toujours anciennes, créées le plus souvent dans des instances sur des plateformes de cloud comme AWS (Amazon Web Services)
Anciennes ne veut pas forcément dire plus utilisées. On sait à qui elles appartiennent ? Ca peut être de la prod sensible, ou bien du dev de test qui pourrit dans un coin.
Le 10/01/2017 à 08h55
Donc en gros, certains, en plus de ne pas avoir sécurisé leur BDD une fois le problème mis en évidence, n’ont même pas de sauvegarde ? (vu qu’ils ont payé)
Le 10/01/2017 à 08h59
J’sais pas si c’est valable pour ma version, moi j’ai une version sans GUI, rien, juste la base, et vu que j’y connais rien en Mongo. " />
Le 10/01/2017 à 09h00
Ca peut même être du dev “test” mais avec de la vrai data (exportées de la base en prod) avec des données sensibles dedans genre des carnets d’adresses, des mdp en clair etc.
Le 10/01/2017 à 09h01
Comment payer la mongolance de devs info qui font des choix de bad design irresponsables…
Le 10/01/2017 à 09h03
“Pour rappel, les administrateurs concernés ont laissé ouvert la possibilité de se connecter à distance sans même exiger des identifiants. ”
Pardon ?!
Le 10/01/2017 à 09h07
Le 10/01/2017 à 09h11
Conf par défaut de mongodb… ca pique un peu oui.
Enfin il me semble que ce n’est plus le cas pour les nouvelles installations.
Le 10/01/2017 à 09h14
Le 10/01/2017 à 09h19
Ça ne m’étonne pas du tout, personnellement je configure les mots de passe avant la backup. Donc si le premier n’est pas fait…
Le 10/01/2017 à 09h20
C’est violent d’avoir mis ça par défaut. :/
Le 10/01/2017 à 09h21
Le 10/01/2017 à 09h22
Le 10/01/2017 à 09h29
J’ai moi même du mal à comprendre comment on peut être insensible à ce point à la sécurité et aux dangers auxquels on s’expose…
Le 10/01/2017 à 09h31
Le 10/01/2017 à 09h42
Le 10/01/2017 à 09h43
Le 10/01/2017 à 09h47
De ce que j’en sait, par défaut MongoDB ne demande pas d’identifiant, MAIS n’est accessible qu’en local.
Après, si tu bouge la config pour rendre accessible autrement, c’est à toi de prendre tes responsabilité et de sécuriser correctement.
C’est la même chose pour MySql et Postgres.
C’est comme ouvrir un port dans un firewall, tu le fais en connaissance de cause.
Le 10/01/2017 à 09h48
Le 10/01/2017 à 09h52
Le 10/01/2017 à 10h10
Le 10/01/2017 à 10h36
C’est exactement ça. C’est quand ça commence à les toucher d’assez prêt que les responsables accordent de l’importance à la sécurité informatique. Avant, pour eux, ça ne sert à rien… " />
Par contre, chez nous, la sécurité informatique, c’est quand même très important. On a même obtenu la certification ISO 27001 récemment " /> En même temps, comme on héberge des données sensibles, vaut mieux l’avoir " />
Le 10/01/2017 à 11h08
" />C’est pas de leur responsabilité. Ils mettent la conf qu’ils veulent par défaut, c’est quand même à celui qui installe et qui gère de faire un minimum de vérif.
Le 10/01/2017 à 11h26
Le 10/01/2017 à 11h30
Ça me fait penser au patron qui voulait mettre “soleil” en mot de passe car c’est trop compliqué sinon, et il n’y a rien de toute façon ici.
Le 10/01/2017 à 11h30
Edit : depuis mon mobile ça fait toujours un double post c’est gonflant
Le 10/01/2017 à 11h43
Pour ce que je connais, les logiciels pour NAs comme Openmediavault ou NAS4Free mettent par défaut un mdp bidon, et demandent expressément à l’utilisateur de le changer dès la première session.
Donc, pourquoi est-ce qu’une BDD ne prendrait pas a minima ce genre de précaution ?
Le 10/01/2017 à 11h52
Ils sont pas professionnelles et pourtant ils veulent prendre des décisions de professionnelles :)
Le 10/01/2017 à 11h55
Je ne comprends pas qu’en 2017 les systèmes de bases de données ne soient pas capables de se mettre à jour tout seul !
Le 10/01/2017 à 12h01
Le 10/01/2017 à 12h07
Tout seul ?
Et puis la “faille” est dans la config, pas dans le logiciel lui même. Ca me ferait chié qu’a chaque update la config de logiciel en prod saute pour une raison ou une autre " />
Le 10/01/2017 à 12h12
Le 10/01/2017 à 12h45
A voir si on préfère un arrêt de prod. pour regression (où il suffit de faire u rollback).. ou un vol/cryptolockage de ses données (ou de celle de ses client)…
Mais je préfère une mise à jour rapides des systèmes… " />
Le 10/01/2017 à 13h00
Le roolback d’une maj., on sait si ça marche seulement après avoir essayé.
Le 10/01/2017 à 13h01
Le 10/01/2017 à 13h15
En même temps, quand on voit le nombre de boites qui utilisent des salariés qui n’y connaissent pas grand chose mais à qui on demande gentiment de gérer le parc informatique et les serveurs parce qu’ “un vrai sysadmin, ça coûte cher m’voyez”, après, faut pas venir se plaindre…
Il y a qu’à voir le nombre de sysadmins dans les collèges, lycées, universités, mairies, etc. Ça frôle le 0. On refile la gestion à un prof/fonctionnaire/stagiaire qui s’y connait un peu (et qui est forcé de se porter volontaire).
Ça me rappelle une grosse crise de rire la fois où je m’étais logué en root sur le serveur du collège (root/password, faut le faire !). J’étais jeune en ce temps-là et je n’avais rien fait de mal, j’avais juste montré ça au prof de techno qui devait “sécuriser la bête”.
Le 10/01/2017 à 14h11
Après y’a des gens qui n’ont mis aucune sécurité et qui l’assument très bien.
Pour un projet de cours on avait monté une base mongoDB on cloud et tout laissé par défaut, mais bon on avait aucune donnée à perdre on s’en foutait royalement de la sécurité et des backups :)
Le 10/01/2017 à 14h23
Non mais là c’est pas le problème, il s’agit d’un problème de config, aucune mise à jour ne peut régler çà simplement en général. A moins d’y aller à coup de diff ou autre, ca ne peut être fait en automatique… on parle de solution pro tout de même.