40 000 BDD en accès libre c’est faramineux, d’autant que l’une proviendrait d’un opérateur français et contiendrait 8 millions d’entrées avec autant de données qui peuvent s’avérer sensibles : nom, coordonnées, emails, numéro de carte de crédit, etc. Ces données peuvent être non seulement copiées, mais également modifiées.
Si le CERT-FR (Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques) a été informé de la nouvelle par le groupe de recherche allemand, l’opérateur en question ne s’est toujours pas dévoilé. Ce qui ne devrait pas tarder puisque la CNIL, qui a ouvert une enquête, rappelle que « les fournisseurs de services de communications électroniques [ont] l’obligation de notifier les violations de données personnelles aux autorités nationales compétentes, et dans certains cas, aux personnes concernées. ».
D’autant que dans le cas présent, il n’est pas question d’une quelconque attaque informatique ou faille de sécurité à déplorer chez MongoDB mais d’une mauvaise configuration des administrateurs lors de l’implémentation de ces BDD. Ces derniers ont modifié les accès par défaut (bindIp: 127.0.0.1.), sans prendre en compte toutes les conséquences d’un tel acte. En modifiant cet accès par défaut, ils ont supprimé la restriction d’accès et donc ouvert grand la porte à leur(s) base(s) de données à toute IP qui s’y connecte.
Du côté des opérateurs, Bouygues Télécoms a assuré à 01net qu’il ne s’agissait pas de ses bases de données. Tous les regards se tournent vers Orange qui n’a pas communiqué là-dessus.
🟣 Pour ne manquer aucune news sur le Journal du Geek, abonnez-vous sur Google Actualités. Et si vous nous adorez, on a une newsletter tous les matins.
“une mauvaise configuration des administrateurs lors de l’implémentation de ces BDD. Ces derniers ont modifié les accès par défaut (bindIp: 127.0.0.1.), sans prendre en compte toutes les conséquences d’un tel acte. En modifiant cet accès par défaut, ils ont supprimé la restriction d’accès et donc ouvert grand la porte à leur(s) base(s) de données à toute IP qui s’y connecte”
C’est pas qu’une question de mauvaise configuration parce que si avec seulement çà leurs serveurs de BD sont accessibles direct depuis le web c’est qu’il y a un gros problème de conception de l’architecture.
ca serai bien de savoir de quel operateur il s agit…
Ce n’est effectivement pas une faille à proprement parler, mais quand même un sérieux manque dans la conception de cette base. On m’a toujours appris qu’en matière de sécurité, par défaut tout est fermé, et on ouvre les portes dont on a besoin. Hors, ici c’est plutôt l’inverse (certes au départ que sur du local, mais quand même).
D’un autre côté dans une infra un peu conséquente (i.e. autre chose qu’un serveur perso utilisé par 3 clampins quoi) tu bind pas les services sur la loopback (127.0.0.1) vu que les applications qui doivent y accéder ne tournent pas sur le même serveur.
Reste le problème de la configuration qui n’a pas été modifiée, mais je dirais pour la défense des admins qu’un produit qui a pour configuration par défaut de ne pas utiliser de mot de passe ce n’est pas franchement normal non plus en 2015 …
Effectivement, il serait mieux que commenter la ligne ferme l’accès à la base plutôt que l’ouvrir.
Mais : ça veut quand même dire que la personne accède à sa base de données depuis un autre serveur sans à rien configurer. Je pense qu’à ce moment là, pas mal de monde doit déjà réaliser que s’il peut se connecter depuis n’importe où sans aucune sécurité, n’importe qui peut le faire.
Que certains passent à côté, ça peut se comprendre, mais quand on a une base de 8 millions de clients avec très probablement des données privées, on s’attend quand même à un minimum de bon sens de la part de la personne en charge…
“Du côté des opérateurs, Bouygues Télécoms a assuré à 01net qu’il ne s’agissait pas de ces bases de données”
Bonne nouvelle pour moi ^^
Y’a un DBA qui doit faire pipi culotte en ce moment même ! ça doit même être mouillé devant derrière comme dit la chanson !
« Du côté des opérateurs, Bouygues Télécoms a assuré à 01net qu’il ne s’agissait pas de ces bases de données »
SES bases de données (les “S”iennes donc “ses” avec un S, c’est un bon moyen mnémotechnique)
qui ? c’est simple il suffit de chercher
http://www.mongodb.com/customers/orange-digital
et sfr aussi
SFR Customer service applications accessed via online portals and call centers
http://www.mongodb.com/hadoop-and-mongodb
Vous avez pas la bonne source, les étudiants ont utilisés Shodan, allez donc faire une petite recherche, ce n’est ni sfr ni orange… 🙂
Y’a un truc que je comprends pas, même si le serveur de BDD accepte des connexions venant de n’importe où, il faut quand même s’y connecter à la base ?
Sans les login/mdp, même en ayant accès au serveur, on n’y accède pas comme ça non plus…. ?
@marc
C’est bon pour orange, c’est .co.uk, ce sont pas nos données \o/ !
@Spamplemousse si je ne dis pas de connerie (à vérifier) par défaut quand tu créés une base, tout le monde est administrateur, tout est accessible. Si tu ne changes pas ça, c’est la cata quand ta base est accessible depuis n’importe ou. Mais ce que je dis là est à prendre avec des pincettes…
Moi je suis allé vérifier tout mes fichiers de conf 😀
@Spamplemousse
La réponse est simple : il n’y a pas de protection par login/pass dans mongoDB par défaut.
Avec un usage à petite échelle, ça ne pose pas de problème vu que l’application va être sur le même serveur que la base de données et que seul un accès local est autorisé.
Je suis pas familier avec les mesures à prendre quand on a une grosse base et plusieurs serveurs, mais je suppose que l’équipe de mongoDB aurait été ravie d’aider l’opérateur en question si les tutoriaux n’étaient pas assez complets. http://docs.mongodb.org/manual/administration/security/
Encore une fois, pas mal de sensationnalisme dans cet article.
BindIP, c’est bien, c’est sur. Ca ne permet pas de se connecter autrement que depuis le serveur lui-même. Malheureusement, dès que l’on va un peu plus loin dans les applications, on est obligé de fonctionner avec plusieurs serveurs, donc plusieurs IPs se connectent sur la même base, donc obligé de le retirer.
Non, retirer le BindIP n’est pas une erreur de sécurité. Le problème ne vient absolument pas de là ici. C’est juste une banale intrusion … C’est très simple :
1/ Je test une IP au hasard, ou je cible un serveur en particulier, et je lui demande de me connecter à MongoDB (ou n’importe quel autre service). Si celui-ci me répond que le service appelé existe mais requiert une authentification, alors c’est que j’ai visé juste, je peux donc continuer ma démarche.
2/ Je test une succession de login (root/db/prod/dev/ etc …). Si je tombe sur un login qui existe vraiment, alors le système me demandera un mot de passe.
3/ Je test tout d’abords une succession de mot de passe (pwd123, AZERTY, etc … Oui, j’ai déjà vu des système lourds protégés par des trucs dans ce style, les dictionnaires de mot de passe peuvent contenir des centaines de milliers de mots de passe les plus usuels), puis, si ça ne fonctionne pas, j’utilise du bruteforce simple, jusqu’à trouver la bonne combinaison.
Bref … Ca fait plusieurs articles où on peut lire de grosses aberrations dans vos allégations concernant les “failles de sécurité” … Et c’est vraiment lourd à la fin.
@Tilotiti On parle bien d’un soucis de configuration et de serveurs qui sont accessibles sans login/pwd ici.
Par défaut MongoDB ne créé pas de user et tant qu’on n’a pas défini son user, on peut y accéder en mode admin sans aucune autre information.
Et oui, il y a énormément de boites qui ont fait/font cette erreur.
Quand on enlève le binding sur 127.0.0.1.
Ce n’est pas une faille, mais ça reste critique.
En 2015, avoir un système qui a plus ou moins toutes les portes ouvertes “presque” par défaut, c’est pire qu’une catastrophe.
Maintenant c’est tout aussi catastrophique (même pire) de voir que des DBA ou des devs ignorent ces notions de sécurité ou ont une telle méconnaissance de leurs outils qu’ils ne comprennent même pas leur fonctionnement.
Donc avoir un BDD accessible depuis l’extérieur c’est une faille ? C’est quoi cette News sérieux. Quand je vois tous les Kévin qui écrivent n’importe quoi en commentaire, ils n’y connaissent absolument rien en architecture système et essaye de se la jouer.
Le JDG commence vraiment a baisser dans mon estime.
@reazy On se demande sincèrement qui est le kevin qui croit tout savoir ici^^
Avoir une DB accessible de l’extérieur n’est pas une faille en soit et, dans certains cas, peut tout à fait se justifier, mais si tu avais une mini notion en sécurité, tu saurai qu’on y applique une certaine sécurité en limitant aux IPs autorisées, qu’on ajoute des users, et qu’on ne donne que les droits nécessaires (lecture par exemple).
Et pour cela, il faut vraiment qu’il y ait une raison très très particulière.
Pour certaines DB, je peux tout à fait comprendre qu’on donne un accès depuis l’extérieur (et encore, on y préférera des webapi ou des webservices autant que possible, pour pouvoir garder un contrôle complet sur la consommation de la data).
En revanche, on parle aussi ici de bases de données avec plus de 8 millions d’entrées et quand on possède une DB pareille, on a simplement le devoir de protéger ces données avec toute une panoplie de règles.
Franchement, c’est avec ce genre de comportements qu’on créé les failles les plus graves en informatique.