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

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

La foire aux données

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

10/01/2017
59

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

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.

59

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

2 000 bases, puis 10 500, puis 28 000...

Presque 100 000 bases piratables

Les avertissements à double-tranchant

Commentaires (59)


Ami-Kuns Abonné
Le 10/01/2017 à 08h 42

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=" />


eres Abonné
Le 10/01/2017 à 08h 46

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 à 08h 46

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 à 08h 48

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=" />


Le 10/01/2017 à 08h 49

Et le coffre rempli de cadeaux


dylem29 Abonné
Le 10/01/2017 à 08h 50

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;


Le 10/01/2017 à 08h 51







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=" />



eglyn Abonné
Le 10/01/2017 à 08h 52







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;



Le 10/01/2017 à 08h 52







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…



Jarodd Abonné
Le 10/01/2017 à 08h 53



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 à 08h 55

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


dylem29 Abonné
Le 10/01/2017 à 08h 59

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;


Le 10/01/2017 à 09h 00

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.


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


Le 10/01/2017 à 09h 03

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



Pardon ?!


Le 10/01/2017 à 09h 07







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



Le 10/01/2017 à 09h 11

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 à 09h 14







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 :-)”



Otiel Abonné
Le 10/01/2017 à 09h 19

&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…


Le 10/01/2017 à 09h 20

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


Le 10/01/2017 à 09h 21







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…



eglyn Abonné
Le 10/01/2017 à 09h 22







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;



Le 10/01/2017 à 09h 29

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 à 09h 31







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.



Le 10/01/2017 à 09h 42







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



Le 10/01/2017 à 09h 43







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.



Le 10/01/2017 à 09h 47

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.


Vincent_H Abonné
Le 10/01/2017 à 09h 48







jackjack2 a écrit :



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







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



Le 10/01/2017 à 09h 52







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. :/



Le 10/01/2017 à 10h 10







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.



Jaskier Abonné
Le 10/01/2017 à 10h 36

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=" />


Le 10/01/2017 à 11h 08

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


Juju251 Abonné
Le 10/01/2017 à 11h 26







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.



Zulgrib Abonné
Le 10/01/2017 à 11h 30

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


Zulgrib Abonné
Le 10/01/2017 à 11h 30

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


Le 10/01/2017 à 11h 43

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 à 11h 52

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


Le 10/01/2017 à 11h 55

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 à 12h 01







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.



Le 10/01/2017 à 12h 07

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=" />


Le 10/01/2017 à 12h 12







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



Le 10/01/2017 à 12h 45

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=" />


Le 10/01/2017 à 13h 00

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


Le 10/01/2017 à 13h 01







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;



Le 10/01/2017 à 13h 15

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 à 14h 11

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;


Le 10/01/2017 à 14h 23

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.


Le 10/01/2017 à 16h 28

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?


jotak Abonné
Le 10/01/2017 à 16h 42







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



jotak Abonné
Le 10/01/2017 à 16h 46

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 à 17h 50







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=" />



dylem29 Abonné
Le 10/01/2017 à 19h 10

Hum ?&nbsp;


Le 10/01/2017 à 19h 30

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 à 19h 53

<img data-src=" />

<img data-src=" />


Le 10/01/2017 à 21h 58

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 à 14h 44

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 à 14h 44

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 à 14h 44

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 à 16h 48







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.