Connexion
Abonnez-vous

Plus de 28 000 bases MongoDB ont été effacées contre rançon

La foire aux données

Plus de 28 000 bases MongoDB ont été effacées contre rançon

Le 10 janvier 2017 à 08h35

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)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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!



<img data-src=" />&nbsp; &nbsp;<img data-src=" />



Le sens de la justice US fait des émules par chez nous, what could possibly go wrong?

votre avatar







CryoGen a écrit :



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.





Non seulement ça, mais en plus pour sécuriser il va bien falloir mettre un mot de passe, ou configurer quelque chose… je vois pas comment ne pas passer par la case “config”.


votre avatar

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.

votre avatar







dylem29 a écrit :



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. <img data-src=" />&nbsp;





<img data-src=" />


votre avatar

Hum ?&nbsp;

votre avatar

Bonne nouvelle, si ca permet aux “directeurs” de comprendre qu’un bon sysadmin ca se paye…



… ou que, sinon, on finit par le payer.

votre avatar

<img data-src=" />

<img data-src=" />

votre avatar

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.

votre avatar

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 …

votre avatar

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 …

votre avatar

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 …

votre avatar







ndjpoye a écrit :



<img data-src=" />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.







jackjack2 a écrit :



Franchement vous plaisantez, vous pouvez pas mettre ça sur le dos des dev MongoDB





Un admin qui publie une BDD sans mdp est un gland, mais tout de même, c’est un peu pousse-au-crime de mettre par défaut une config aussi pourrie alors qu’il est extrêmement facile de limiter les connexions sans mdp à localhost.


votre avatar

Cela en fait des sommes potentiels.<img data-src=" />

Un de ces jours, certains en auront marre, et engagerons des personnes pour péter quelques rotules.<img data-src=" />

votre avatar

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

votre avatar

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…

votre avatar

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…





<img data-src=" />

votre avatar

Et le coffre rempli de cadeaux

votre avatar

La base Mongo dans ma boite n’est accessible que par le réseau interne. <img data-src=" />&nbsp;



Quelqu’un a des astuces pour mieux la sécuriser? Elle n’héberge pas de service critique, mais bon.&nbsp;

votre avatar







CryoGen a écrit :



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…





<img data-src=" />





<img data-src=" /> <img data-src=" />


votre avatar







Xylane a écrit :



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…





M’en parle pas… J’ai signalé le pb a certains de nos dev qui utilisent MongoDB, leur réponse c’est: on s’en fou elles ne sont pas accessible de l’extérieur.&nbsp;

Donc le fait que par défaut on puisse rentrer dans la BDD sans authentification ne les choquent absolument pas :(

&nbsp;

&nbsp;


votre avatar







dylem29 a écrit :



La base Mongo dans ma boite n’est accessible que par le réseau interne. <img data-src=" />&nbsp;



Quelqu’un a des astuces pour mieux la sécuriser? Elle n’héberge pas de service critique, mais bon.&nbsp;





ici ?&nbsphttps://www.mongodb.com/blog/post/how-to-avoid-a-malicious-attack-that-ransoms-y…


votre avatar



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.

votre avatar

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é)

votre avatar

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. <img data-src=" />&nbsp;

votre avatar

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.

votre avatar

Comment payer la mongolance de devs info qui font des choix de bad design irresponsables…

votre avatar

“Pour rappel, les administrateurs concernés ont laissé ouvert la possibilité de se connecter à distance sans même exiger des identifiants.&nbsp;”



Pardon ?!

votre avatar







eglyn a écrit :



M’en parle pas… J’ai signalé le pb a certains de nos dev qui utilisent MongoDB, leur réponse c’est: on s’en fou elles ne sont pas accessible de l’extérieur.&nbsp;

Donc le fait que par défaut on puisse rentrer dans la BDD sans authentification ne les choquent absolument pas :(

&nbsp;

&nbsp;







Ça devrait être considéré comme une faute grave, même sans accès malicieux


votre avatar

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.

votre avatar







jackjack2 a écrit :



Ça devrait être considéré comme une faute grave, même sans accès malicieux





C’est clair. Faudrait demander aux devs “Quand vous garez votre voiture dans un parking privé, je suppose que vous ne la verrouillez pas non plus, hein? Après tout, c’est pas accessible depuis l’extérieur, donc ça craint rien :-)”


votre avatar

&nbsp;Ç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…

votre avatar

C’est violent d’avoir mis ça par défaut. :/

votre avatar







shadowfox a écrit :



“Pour rappel, les administrateurs concernés ont laissé ouvert la possibilité de se connecter à distance sans même exiger des identifiants.&nbsp;”



Pardon ?!





C’est hallucinant…



J’avais eu du mal à expliquer à mes cadres de direction de l’entreprise où je travaille qu’il ne fallait pas laisser la base de données (Une PostgreSQL) avec les données clients et flotte dessus en accès libre sans indentifiants, j’ai réussi à leur imposer de justesse cette précaution de base.&nbsp;



Je met le lien vers cet article en copie dans un courriel à leur intention, afin qu’ils réfléchissent un peu plus la prochaine fois qu’ils me demandent de ne PAS sécuriser des données SENSIBLES, comme la position et le chargement des camions de la flotte que gère ladite base de données en temps réel…


votre avatar







jackjack2 a écrit :



Ça devrait être considéré comme une faute grave, même sans accès malicieux





Faudrait aussi blâmer en premier ceux qui ont développé MongoDB et laissé par défaut ce genre de config, c’est quand même aberrant…

&nbsp;


votre avatar

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…

votre avatar







Crysalide a écrit :



Comment payer la mongolance de devs info qui font des choix de bad design irresponsables…







C’est pas du bas design, c’est du “bad mise en oeuvre”. MongoDB est très bien, faut juste pas l’utiliser n’importe comment, un peu comme n’importe quelle techno en fait.


votre avatar







DorianM a écrit :



C’est pas du bas design, c’est du “bad mise en oeuvre”. MongoDB est très bien, faut juste pas l’utiliser n’importe comment, un peu comme n’importe quelle techno en fait.





Oui enfin, si on te donne un pistolet et que par défaut le pistolet est configuré pour te mettre une balle dans la tête, c’est qu’il y a un gros problème. Même si après en soi, le pistolet est très bien pour faire du tir en salle une fois bien configuré.


votre avatar







shadowfox a écrit :



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…





À la décharge de mes patrons, ce sont des professionnels du transport routier, pas de l’informatique.&nbsp;



J’ai le responsable marchés est-européens qui vient de me demander à l’instant si nous avons ce problème, je lui ai répondu que non, en lui rappelant la séance pénible lorsque j’ai mis en place notre système informatique.&nbsp;



Nosu gérons quand même des 44 tonnes dans notre entreprise, si Daesh tombe sur notre base de données parce qu’elle n’est pas sécurisée, ils ont de quoi faire un génocide, par exemple.


votre avatar

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.

votre avatar







jackjack2 a écrit :



Ça devrait être considéré comme une faute grave, même sans accès malicieux







Malicieux ? Vraiment ? <img data-src=" />&nbsp;


votre avatar







Torre Torinese a écrit :



À la décharge de mes patrons, ce sont des professionnels du transport routier, pas de l’informatique.&nbsp;





Oui mais c’est pour cette même raison que tu es en place et qu’ils ne devraient même pas discuter el coup quand il s’agit de sécurité étant donné que ce ne fait pas partie de leur domaine de compétences. :/


votre avatar







shadowfox a écrit :



Oui mais c’est pour cette même raison que tu es en place et qu’ils ne devraient même pas discuter el coup quand il s’agit de sécurité étant donné que ce ne fait pas partie de leur domaine de compétences. :/





Tout à fait.&nbsp;



J’ai eu du mal à leur arracher l’achat un pare-feu matériel de chez Zyxel, un modèle à 1000 € HT, et j’ai sorti cet argument en leur disant que le serveur HS pour cause de DDOS, ça risquait de mettre l’entreprise en faillite.&nbsp;



Quand un concurrent a été mis en liquidation judiciaire suite à ce genre de problème six mois plus tard, ils ont vite trouvé que 1000 € HT, c’était donné pour la sécurité de l’entreprise.&nbsp;



Depuis, ils me font quand même un peu plus confiance, et ils comprennent que les menaces contre lesquelles je leur demande de faire des investissements préventifs, ce ne sont pas des vues de l’esprit.


votre avatar

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… <img data-src=" />



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 <img data-src=" /> En même temps, comme on héberge des données sensibles, vaut mieux l’avoir <img data-src=" />

votre avatar

<img data-src=" />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.

votre avatar







Bourrique a écrit :



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.





Il n’en reste pas moins qu’une BDD accessible par défaut en admin sans mdp, même juste en local ça pique …

Après, oui, il y a le problème de l’installation et de la configuration, mais ça n’empêche qu’un truc qui est destiné à de la prod devrait au moins demander la création d’un mdp lors de la config initiale.


votre avatar

Ç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.

votre avatar

Edit : depuis mon mobile ça fait toujours un double post c’est gonflant

votre avatar

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 ?

votre avatar

Ils sont pas professionnelles et pourtant ils veulent prendre des décisions de professionnelles :)

votre avatar

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 !

votre avatar







linconnu a écrit :



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 !





Heeeee moi au contraire, ca me va.



C’est le style de système où t’as pas envie de tomber sur des régressions, des changement de performance, etc…. au hasard d’une MAJ auto.


votre avatar

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 <img data-src=" />

votre avatar







ndjpoye a écrit :



Heeeee moi au contraire, ca me va.



C’est le style de système où t’as pas envie de tomber sur des régressions, des changement de performance, etc…. au hasard d’une MAJ auto.





+1 gogol* <img data-src=" />



* : 10^100


votre avatar

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…&nbsp; <img data-src=" />

votre avatar

Le roolback d’une maj., on sait si ça marche seulement après avoir essayé.

votre avatar







Messenger a écrit :



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…&nbsp; <img data-src=" />





L’arrêt de prod, c’est pas anodin dans plein de structure.



Moi je préfère une 3ième solution : un gas qui s’occupe de la sécurité. C.a.d. se renseigne sur les MAJ, teste les MAJ, planifie la MAJ, etc…&nbsp;


votre avatar

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”.

votre avatar

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&nbsp;:)



&nbsp;

votre avatar

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.

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

Fermer