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.
Commentaires (59)
#1
Cela en fait des sommes potentiels.
" />
" />
Un de ces jours, certains en auront marre, et engagerons des personnes pour péter quelques rotules.
#2
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
#3
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…
#4
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…
#5
Et le coffre rempli de cadeaux
#6
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.
#7
#8
#9
#10
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.
#11
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é)
#12
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.
" />
#13
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.
#14
Comment payer la mongolance de devs info qui font des choix de bad design irresponsables…
#15
“Pour rappel, les administrateurs concernés ont laissé ouvert la possibilité de se connecter à distance sans même exiger des identifiants. ”
Pardon ?!
#16
#17
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.
#18
#19
Ç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…
#20
C’est violent d’avoir mis ça par défaut. :/
#21
#22
#23
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…
#24
#25
#26
#27
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.
#28
#29
#30
#31
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…
" />
" /> En même temps, comme on héberge des données sensibles, vaut mieux l’avoir 
" />
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
#32
#33
#34
Ç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.
#35
Edit : depuis mon mobile ça fait toujours un double post c’est gonflant
#36
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 ?
#37
Ils sont pas professionnelles et pourtant ils veulent prendre des décisions de professionnelles :)
#38
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 !
#39
#40
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
#41
#42
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…
#43
Le roolback d’une maj., on sait si ça marche seulement après avoir essayé.
#44
#45
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”.
#46
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 :)
#47
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.
#48
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?
#49
#50
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.
#51
#52
Hum ?
#53
Bonne nouvelle, si ca permet aux “directeurs” de comprendre qu’un bon sysadmin ca se paye…
… ou que, sinon, on finit par le payer.
#54
#55
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.
#56
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 …
#57
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 …
#58
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 …
#59