Developpez.com

Le Club des Développeurs et IT Pro

Plus de 2000 instances MongoDB prises en otage dans l'attente du paiement d'une rançon

Les administrateurs invités à vérifier leurs configurations

Le 2017-01-04 16:47:52, 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.

Dans une mise à jour, MongoDB a résolu ce problème en définissant par défaut dans les configurations un accès restreint à distance. Il semble que de nombreux administrateurs n’ont pas pris la peine d’effectuer la mise à jour. C’est en tout cas ce que suggère un évènement récent qui affecte MongoDB.

Victor Gevers, un chercheur en sécurité et accessoirement co-fondateur de la fondation GDI, un organisme à but non lucratif visant à rendre l'Internet plus sûr, a trouvé une instance MongoDB prise en otage. Si elles étaient encore 200 lundi dernier, selon un tweet de John Matherly, le fondateur de Shodan (un moteur de recherche de machines connectées) le nombre a été multiplié par 10 en l’espace de quelques jours. Selon Bob Diachenko, un chercheur de MacKeeper, parmi les victimes figurent une organisation dans le domaine de la santé aux Etats-Unis qui a perdu l’accès à 200 000 enregistrements.

Tout a commencé le 27 décembre lorsque, dans le cadre de ses activités au sein de la GDI, il a repéré une base de données MongoDB dont l’accès n’était pas protégé par un mot de passe. Cette dernière l’a interpellé parce qu’au lieu de voir du contenu, il est tombé sur le message « SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE ! ».


Pour Gevers, 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èmes. « 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é.

Si le procédé s’apparente à celui des ransomwares, notamment une prise en otage des données associée à une demande rançon, l’attaque ne fait pas appel à un malware de ce type. D’ailleurs Gevers le rappelle lorsqu’il dit que « ce n’est pas un ransomware. La base de données n’est pas chiffrée, mais simplement remplacée. Nous avons affaire à quelqu’un qui effectue cette opération manuellement ou via un simple script Python ».

L’entité derrière cette attaque, qui utilise le pseudonyme harak1r1, exige le paiement d'une rançon de 0,2 bitcoin (ce qui représente environ 200 euros dans le cours actuel de cette monnaie virtuelle) mais aussi d’être contacté par courriel avec l’IP du serveur pour que les données soient restituées.

Pour l’heure, 16 entités se sont déjà résolues à payer à en croire le Blockchain dédié au paiement de la rançon.

Lors de ses recherches, Gevers est tombé sur une base de données MongoDB ouverte disposant de plus de 850 milliards de métadonnées d’enregistrement d’appels téléphoniques. « J’ai dû cligner des yeux à deux reprises pour lire le nombre total ».


Source : John Matherly, Victor Gevers, Blockchain dédiée au paiement de la rançon
  Discussion forum
24 commentaires
  • Cafeinoman
    Membre éprouvé
    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.
  • maske
    Membre éprouvé
    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...
  • koyosama
    Membre éprouvé
    Envoyé par maske
    C'est vrai dans l'absolu, mais quand même. Quand j'installe un soft ou un outil, je ne m'attends pas à ce qu'il soit ouvert au monde entier par défaut.

    Ça me parait bizarre de reporter la faute exclusivement sur l'utilisateur, surtout de la part d'un outil open source qui vante sa simplicité d'utilisation (je ne parle pas de mongo spécifiquement).

    Deja j'ai envie de dire que "ouvert" n'a rien a voir avec le monde professionel. Tu peux mettre un mot de passe par defaut comme wordpress, my sql, cela va rien changer.
    Un utilisateur a des chances d'etre un developeur, sysadmin, deveops; whatever ils ont une responsabilite envers nos donnees. Celon le type d'applications, on joue avec la vie des gens. Le piratage est parfois une lecon par des crackers pour nous dire de mieux controller nos donnes. Est-ce que un medecin doit faire le minimum, c'est un peu trop facile. Il y a une limite a la feignantise.

    Quand on est paye 30-45 k, je m'attends a ce que le gars puisse au minimum creer un system utilisateur minimal. Si tu peux creer un compte user sur windows, tu peux largement prendre un heure pour lire, tester la securite de mongo de DB. Il faut arreter avec le poil de la main. Aujourd'hui on arrive dans une ere ou certaine donnes sont critiques pour n'importe quel utilisateur.



    Chercher pas d'excuse, faite le neccessaire.
  • TheGuit
    Membre régulier
    850 milliards
  • ypicot
    Membre confirmé
    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
  • Shepard
    Membre expérimenté
    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 ...
  • koyosama
    Membre éprouvé
    Je me rappelle ou le probleme ce n'était pas le système NOSQL mongodb, mais le RDMS mysql.

    On était tout content, on avait appris comment utiliser la couche LAMP stack (Linux Apache MySQL PHP) sur un site, a l'école, parfois par des "pros".
    Mais on n'avait jamais appris a le sécurisé, juste appris qu'il fallait soit installer wamp/xamp, soit installer la ligne magique sur Linux.

    Et aujourd'hui, on recommence la même connerie avec le MEAN stack (Mongo Express Angular Node).

    Je pense que le problème, c'est que beaucoup de debutant/pros ne sachent réellement configurer une base de données. Surtout qu'on apprend aux gens comment s'y connecter directement au lieu de créer un intermédiaire. Car créer un intermédiaire est plus compliqué dans le planning de développement d'une entreprise que d'utiliser les bonnes pratiques de la séparation des couches applicatives. Après tout ce n'est pas une connaissance basique de le savoir.
  • ça ne viendrait pas à l'idée de personne de simplement autoriser les connexions à Mongo uniquement depuis localhost !
  • ypicot
    Membre confirmé
    Envoyé par Shepard
    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
  • Shepard
    Membre expérimenté
    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 ...