Les instances MongoDB prises en otage sont passées de 12 000 à plus de 27 000 en moins de 12 heures
D'après un chercheur

Le , par Stéphane le calme, Chroniqueur Actualités
Il y a près de deux ans déjà, un chercheur en sécurité identifiait plus de 33 500 instances MongoDB comportant un port d’administration ouvert, parmi lesquelles près de 19 000 ne demandaient aucune authentification. Les utilisateurs de MongoDB étaient donc prévenus du fait que des instances (près de 600 To de données) mettaient à la merci d’un pirate les sites et applications web qui s’appuyaient sur ces bases de données. Bien entendu ces instances MongoDB ne se retrouvaient pas en danger en raison d'un défaut logiciel, mais à cause d'une mauvaise configuration qui permet à un attaquant à distance d'accéder aux bases de données MongoDB sans même avoir à se servir d’un quelconque outil de piratage.

Si dans une mise à jour MongoDB a résolu ce problème, de nombreux administrateurs n’ont pas pris la peine de procéder à la mise à jour comme l’a suggéré un évènement récent : plus de 2000 instances MongoDB ont été prises en otage. L’entité derrière l’attaque, qui utilise le pseudonyme harak1r1, accède, copie et supprime des données provenant de bases de données non patchées ou mal configurées pour les remplacer par le message « SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE ! ». 22 victimes ont déjà cédé, à en croire le blockchain réservé au paiement.

Pour Victor Gevers, un chercheur en sécurité et accessoirement cofondateur de la fondation GDI, il est possible que l'attaquant trouve les installations MongoDB par un scan basique ou Shodan. Il est également possible de trouver des installations MongoDB qui soient vulnérables à différents exploits, comme le fait d'autoriser les utilisateurs authentifiés distants pour obtenir des privilèges système. « Les criminels ciblent souvent les bases de données open source pour déployer leurs activités de vol ou de rançonnage. Mais nous avons aussi vu des cas où des serveurs sont utilisés pour héberger des logiciels malveillants, des botnets et pour cacher des fichiers dans GridFS », a-t-il expliqué.

Selon Niall Merrigan, un chercheur en sécurité basé en Norvège, le nombre de serveurs compromis, qui étaient de 12 000 le 08 janvier 2017, a dépassé les 27 600 ce même jour dans l’après-midi.


Merrigan et ses associés ont indiqué avoir enregistré environ 15 attaquants distincts. Une entité se servant du pseudonyme kraken0 a compromis 15.482 instances MongoDB, en exigeant une rançon de 1 Bitcoin (855 euros) et de 0,1 Bitcoin pour la récupération de fichiers. Personne ne semble avoir payé la rançon de 1 Bitcoin pour l’heure, mais 67 transactions ont déjà été enregistrées pour la rançon de 0,1 Bitcoin. Own3d, une autre entité, a demandé 0,5 Bitcoin et a déjà reçu 5 paiements.

Merrigan et Gevers ont déjà aidé 112 administrateurs à sécuriser leurs bases de données MongoDB qui étaient exposées, selon une fiche de travail. Au total, 99 000 installations MongoDB sont exposées, estime Gevers.


Source : liste des acteurs (Google Docs)


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de maske maske - Membre éprouvé https://www.developpez.com
le 09/01/2017 à 17:15
Alors moi ça vient de m'arriver dimanche dernier sur mon serveur perso. 80 pages de notes et d'analyses perdues (appli maison perso que j'ai développé pour ma thèse), 6 mois de boulot.

Naivement j'avais juste installé mongo et comme ça marchait me suis pas posé de questions. Le pire c'est que depuis quelques semaines je me disais qu'il faudrait que je mette en place un système de sauvegarde et de restauration. J'avais pas pris la peine non plus de configurer une sauvegarde serveur ou de la base mongo (à vrai dire j'avais même pas les logs).

Ça m'apprendra...
Avatar de kilroyFR kilroyFR - Membre confirmé https://www.developpez.com
le 09/01/2017 à 21:11
Pb de ces BDD experimentales. Alors d'aucun diront que ca arrive aussi sur les grands noms egalement .. mais ce n'est pas du niveau de ces attaques ou c'est carrement de la purge de BDD !
Perso j'utilise pour faire joujou avec mon environnement .net (parce que c'est pratique et nouveau) mais jamais je ne mettrai une telle BDD en PROD.

La premiere fois que j'avais installé une telle BDD, j'avais demandé conseil a un gars qui en faisait depuis un an. Et machinalement quand je lui avais posé la question de l'administration/sauvegarde etc. la seule reponse qu'il m'avait sorti c'etait que la BDD etait redondée donc pas un soucis
Aujourd'hui je sais qu'il a subit egalement des attaques et sa BDD dans son labo de recherches a ete partiellement purgée. Aujourdhui je suis triste pour lui mais c'etait prévisible finalement quand on joue avec le feu sans le maitriser.
Avatar de Cafeinoman Cafeinoman - Membre éprouvé https://www.developpez.com
le 10/01/2017 à 6:05
Mouais fin bon, jouer avec le feu, c'est pas utiliser mongo en prod. Ca, c'est bien. Nan, jouer avec le feu, c'est a)exposer ses ports sur le wan, b)ne pas mettre d'authentification.
Une base, ca s'expose pas comme ca, quelque soit la techno, point.
Avatar de zellerda zellerda - Membre à l'essai https://www.developpez.com
le 10/01/2017 à 7:11
ça ne viendrait pas à l'idée de personne de simplement autoriser les connexions à Mongo uniquement depuis localhost !
Avatar de ypicot ypicot - Membre confirmé https://www.developpez.com
le 10/01/2017 à 7:24
Cela me rappelle ceci.

Règle de base : modifier tout ce qui est par défaut. Ne jamais utiliser le port 22 pour du ssh, supprimer le compte admin proposé par défaut (et en créer un autre), etc.
Même les dev doivent savoir ça.

Yvan
Avatar de Shepard Shepard - Membre éprouvé https://www.developpez.com
le 10/01/2017 à 7:38
J'avoue ne pas comprendre l'intérêt de ne pas utiliser le port 22 pour le ssh (sauf peut-être si c'est pour utiliser un port > 1024 sans l'accès root, mais bonjour les compliquations au niveau de la config des clients). Quand à supprimer le compte admin, c'est parfois impossible (postgres sous postgresql ne peut être supprimé), et encore une fois j'ai du mal à comprendre l'utilité d'une telle démarche ? En général la configuration par défaut est faite pour matcher un max de cas sans avoir à changer quoi que ce soit.

Par contre changer le mot de passe par défaut c'est une évidence ...
Avatar de ypicot ypicot - Membre confirmé https://www.developpez.com
le 10/01/2017 à 7:47
Citation Envoyé par Shepard Voir le message
J'avoue ne pas comprendre l'intérêt de ne pas utiliser le port 22 pour le ssh (sauf peut-être si c'est pour utiliser un port > 1024 sans l'accès root
Effectivement, le but est d'utiliser un port >1024 (et de virer l'accès root)
Le but est de rendre l'accès un peu plus difficile. C'est comme pour les serrures de porte : elles sont classées par temps moyen pour être fracturée.
L'idée est de faire perdre le maximum de temps (et donc de ressource) à l'attaquant.

Merci pour l'info sur postgresql, je ne savais pas. Ne peut-on pas réduire les droits d'accès de ce compte ?

Yvan
Avatar de Shepard Shepard - Membre éprouvé https://www.developpez.com
le 10/01/2017 à 7:49
Ok, je viens d'aller voir à quoi ressemblait la sécurité chez MongoDB. Par défaut, le serveur ne requiert pas d'authentification; tout le monde se connecte en tant qu'admin dessus ... Oo

https://docs.mongodb.com/manual/tuto...uthentication/

Je ne comprends pas bien ... Le cas d'utilisation principal de MongoDB est de stocker des données perso ? (comme kilroyFR) Je pensais que c'était l'un des leaders dans le NOSQL ...
Avatar de Shepard Shepard - Membre éprouvé https://www.developpez.com
le 10/01/2017 à 7:56
Citation Envoyé par ypicot Voir le message
Effectivement, le but est d'utiliser un port >1024 (et de virer l'accès root)
Le but est de rendre l'accès un peu plus difficile. C'est comme pour les serrures de porte : elles sont classées par temps moyen pour être fracturée.
L'idée est de faire perdre le maximum de temps (et donc de ressource) à l'attaquant.

Merci pour l'info sur postgresql, je ne savais pas. Ne peut-on pas réduire les droits d'accès de ce compte ?

Yvan
Pour l'analogie avec les serrures de portes, SSH (avec un bon mot de passe) c'est comme utiliser une porte blindée ronde de 60cm d'épaisseur comme on en voit dans les films

Quand quelqu'un arrive à passer c'est généralement en faisant sauter le sol (ou le toit). Du coup je ne suis toujours pas convaincu par l'utilité de changer le port utilisé ... D'autant plus qu'un scan des ports suffit à contourner cette mesure ...

Pour l'utilisateur postgres, je n'en ai aucune idée Mais par défaut on ne peut pas se connecter à ce compte à moins d'être déjà connecté en tant que l'utilisateur (unix) postgres local sur le serveur.
Avatar de koyosama koyosama - Membre éclairé https://www.developpez.com
le 10/01/2017 à 11:47
Citation Envoyé par ypicot Voir le message
Cela me rappelle ceci.

Règle de base : modifier tout ce qui est par défaut. Ne jamais utiliser le port 22 pour du ssh, supprimer le compte admin proposé par défaut (et en créer un autre), etc.
Même les dev doivent savoir ça.

Yvan

Parfaitement d'accord, toujours des excuses pour ne pas faire ce qui aurait du etre fait.
Contacter le responsable de la rubrique Accueil