Des centaines de bases MongoDB attaquées à cause de mauvaises configurations
Entrez, la porte est ouverte
Le 05 janvier 2017 à 16h20
4 min
Internet
Internet
Des centaines de bases de données MongoDB sont actuellement attaquées par un pirate, qui en remplace le contenu et demande une rançon. Une attaque qui ne se base sur aucun outil particulier, mais exploite des défauts de configuration.
Un pirate, se faisant appeler Harak1r1, s’attaque actuellement à des centaines de bases de données MongoDB dans lesquelles certaines étapes simples de configuration n’ont pas été accomplies par les administrateurs. Ces bases sont ainsi laissées ouvertes aux quatre vents, ceux qui savent où chercher pouvant s’y connecter depuis Internet sans que des identifiants particuliers ne soient réclamés.
Un vol de données contre une petite rançon en bitcoin
L’attaque a été découverte il y a maintenant un peu plus d’une semaine par Victor Gevers de la GDI Foundation, et ne cesse depuis de faire des victimes. Quand le chercheur s’est aperçu de la situation le 27 décembre, environ 400 bases avaient été attaquées. Quelques heures plus tard, le nombre de victimes était grimpé à 1 800.
Le schéma d’attaque est simple. Le pirate s’introduit dans la base et en télécharge les données. Puis il remplace chaque champ par un message, le mot « WARNING » apparaissant un peu partout. Il ne chiffre pas les données mais réclame une rançon de 0,2 bitcoin, soit un peu plus de 200 euros actuellement, le cours de la crypto-monnaie ne cessant de grimper.
Harak1r1 a obtenu la liste de ses victimes en scannant tout simplement Internet. Il ne s’agit pas d’un ransomware, puisqu’à aucun moment un malware n’intervient. Le pirate n’utilise pas non plus d’outil spécifique : il se contente de se connecter et de réaliser des opérations assez classiques sur une base de données, via un simple script en Python.
Une sécurité qui ne préoccupe pas assez
Qui est à blâmer ? Essentiellement les entreprises et autres structures qui déploient ces instances MongoDB, souvent à travers des services de cloud. Elles ne s’occupent plus après de la version utilisée, ni même d’une configuration adaptée. Or, les moutures de MongoDB se sont enchainées, notamment pour contrebalancer un problème récurrent de configuration. Mais ces versions n’ont pas été installées. Pour Victor Gevers, 78 % des instances ouvertes via Amazon Web Services par exemple sont vulnérables.
L'information n'est pas étonnante en elle-même. En février 2015, un groupe d'étudiants allemands avait déjà tiré la sonnette d'alarme sur ce problème : environ 40 000 bases étaient librement accessibles sur Internet. Une partie a visiblement été reprise en main, mais il resterait encore dans les 30 000 bases concernées, selon Bleeping Computer.
Environ 2 000 victimes ont été recensées à ce jour. Parmi elles, seules 18 ont accepté de payer pour l’instant (selon l’adresse Bitcoin utilisée), encouragées probablement par la faible somme demandée. L’immense majorité a résisté au chantage, et il est probable que des sauvegardes récentes des bases attaquées aient permis de gérer le problème. À condition de revoir la configuration de MongoDB et, encore mieux, de mettre à jour la version utilisée.
Quelques conseils simples de vérification et de protection
Dans tous les cas, aucun contact extérieur ne devrait être autorisé sur les bases de données, à moins qu’il ne soit expressément autorisé. Le fichier de configuration de MongoDB doit donc être édité et le paramètre « auth » doit passer en « true ». Il est également conseillé de configurer le trafic sur le port 27017, utilisé par MongoDB pour communiquer à distance.
Sachez que l’on peut également vérifier si la base de données a été visitée, notamment par Harak1r1 ou un autre pirate. Il faut commencer par inspecter la liste des comptes et chercher un éventuel utilisateur avec droits administrateur qui n’aurait rien à faire là. Les journaux de MongoDB gardent également la trace des connexions extérieures. On peut également vérifier GridFS à la recherche de fichiers qui auraient été entreposés.
Autant de conseils qui sont fournis par le site officiel de MongoDB, autour d’un guide des bonnes pratiques. Au vu du danger actuel, certains auraient d’ailleurs tout intérêt à se replonger dans ses explications.
Des centaines de bases MongoDB attaquées à cause de mauvaises configurations
-
Un vol de données contre une petite rançon en bitcoin
-
Une sécurité qui ne préoccupe pas assez
-
Quelques conseils simples de vérification et de protection
Commentaires (57)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 05/01/2017 à 16h32
Ouep, ça craint.
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
[…]
Remove test database and access to it? [Y/n] <– y
Reload privilege tables now? [Y/n] <– y
Edit : faute de frappe
Le 05/01/2017 à 16h38
Une configuration MongoLienne.
Je suis deja loin…
Le 05/01/2017 à 16h39
réclame une rançon de 0,2 bitcoin, soit un peu plus de 200 euros actuellement, le cours de la crypto-monnaie ne cessant de grimper.
" />Bitcoin vient de crasher. -18%
Toujours ça d’économisé " />
EDIT: -20%
Le 05/01/2017 à 16h40
Ma conf par défaut avait déjà cette config mais merci pour la piqûre de rapel " />
Le 05/01/2017 à 17h29
Ah oui, des backup non versionnées ça ne sert à rien effectivement ! " />
Le 05/01/2017 à 17h29
Le 05/01/2017 à 17h30
Le 05/01/2017 à 17h38
Le 05/01/2017 à 17h38
Le 05/01/2017 à 17h45
Le 05/01/2017 à 17h49
Le 05/01/2017 à 17h58
Le 05/01/2017 à 18h01
quoi, un backup c’est pas cp -ar données/ backup/ ? " />
(avec le serveur en fonctionnement ofc)
Le 05/01/2017 à 18h03
Le 05/01/2017 à 18h12
Le 05/01/2017 à 18h17
Le 05/01/2017 à 18h25
Réponse véridique que j’ai eu de la part d’un des audités à qui je demandais quelle politique de sauvegarde il avait mis en place. Je l’interrogeai sur la politique de rétention et les emplacements des backups.
Par décence, je ne ferai pas un copier coller de la réponse mais globalement Il m’a répondu qu’il n’y en avait pas mais qu’on avait rien à craindre car on était dans le cloud OVH et que le serveur loué était en RAID.
Il m’a précisé que cependant il faisait un export de base avant des grosses MAJ. Quand je lui ai demandé comment il les faisait, il m’a dit qu’il utilisait phpmyadmin. En grattant, c’était en http et le mot de passe était d’un niveau que je qualifierai de très amateur.
La boîte qui fait çà est à la base une agence Web d’une quinzaine de personnes et le produit en question était utilisé par une quarantaine de personnes comme outil métier assez critique. Comme l’a fait remarqué dufakeacademy, aussi invraisemblable que cela puisse paraître, ils n’ont pas d’admin, c’est un développeur qui s’occupe de monter les serveurs par ce que c’est “facile”
Et ce n’est malheureusement qu’une de mes nombreuses expériences en la matière, je pourrai en écrire un bouquin…..
Le 05/01/2017 à 18h45
J’imagine juste un mailing applicatif après l’attaque de la base :
WARNING, le NULL
W. WARNING WARNING,
il semble que, sauf erreur de notre part, vous êtes redevable de NULL € suite à notre prestation facturée le NULL référence #WARNING.
Nous vous remercions de procéder, W. WARNING WARNING au règlement de cette facture avant le NULL prochain.
WARNING WARNING, responsable clientèle.
Le 05/01/2017 à 18h56
“un groupe d’étudiants allemandes” ????? Je dirais plutôt “un groupe d’étudiants allemands”
Et j’aimerais tant : “un groupe d’étudiantes allemandes” " />
Plaisanterie à part, sécurisez vos accès web, VNC, ssh et encore plus vos bases de données, SVP pensez au bien de l’humanité ! " />
Le 05/01/2017 à 19h25
un tout petit peux plus compliqué
https://docs.mongodb.com/manual/security/
/usr/local/etc/mongodb.conf
Le 05/01/2017 à 16h41
Il y avait eut un article de nextinpact il y a presque 2 ans sur le sujet :
Next INpactFaut croire que ça n’a pas servi de leçon aux admins …
Le 05/01/2017 à 16h45
Ce qui est dingue au final, c’est que l’équipe de MongoDB, dans ses premières versions, n’a jamais fait le moindre effort pour sécuriser à minima une fresh install.
Le 05/01/2017 à 16h45
Le 05/01/2017 à 16h46
Le 05/01/2017 à 16h54
il est également conseillé de configurer firewallé le trafic sur le port 27017
Le 05/01/2017 à 17h03
Avec un simple tuto bien fait , super simple pour mettre en place la base … et ruleZZZZZ !
Le 05/01/2017 à 17h04
Le 05/01/2017 à 17h07
Bah justement, pour beaucoup de serveurs c’est pas admins sys qui les montent mais des gens qui croient s’y connaître en la matière.
J’ai fait des audits sur des solutions hébergées de ce type pendant plusieurs mois et c’est assez inimaginable le nombre de machines pas configurées que j’ai pas trouvé : pas de mises à jour, pas de sauvegarde, login par défaut sur les interfaces d’admins, etc.
Le 05/01/2017 à 17h07
Le 05/01/2017 à 17h12
eh oui les économies …
Le 05/01/2017 à 17h15
Le 05/01/2017 à 17h16
Tu as trouvé beaucoup de cas (d’entreprise) ou aucun backup n’est prévu ? Une erreur de conf, ça arrive facilement, mais ne pas prévoir de backup là ça relève de la faute professionnel.
Le 05/01/2017 à 17h16
Le 05/01/2017 à 17h18
Le 05/01/2017 à 17h23
Le 05/01/2017 à 17h24
J’ai même envie de dire, que si la bdd est accessible sans auth, il y a peu de chance d’avoir des backups dans cette entreprise " />
Et pour celles qui en auraient, je parie qu’une partie a ecrasé la sauvegarde sans versionning avec la version déjà piratée de la base avant de s’en rendre compte " />
Le 05/01/2017 à 19h50
Oui c’est vrai que j’ai zappé un peu cet aspect, en mutu tout est géré par l’hébergeur alors qu’un dédié c’est toi qui t’en occupe.
Le 05/01/2017 à 20h27
Le 05/01/2017 à 20h34
Le 05/01/2017 à 20h46
Le 05/01/2017 à 20h48
Le 05/01/2017 à 20h50
T’en es à 11, Ricards. Ça fait un peu beaucoup.
Allez, c’est la mienne!
" />
Le 05/01/2017 à 20h51
Le 05/01/2017 à 20h52
Le 05/01/2017 à 21h08
Le 05/01/2017 à 21h15
" />
ca va?
Allez, viens, on va te ramener.
Le 05/01/2017 à 21h44
Le 05/01/2017 à 22h26
Le 05/01/2017 à 23h12
Le 06/01/2017 à 01h02
Sur Sql server par défaut les connexions distantes sont bloqués en fait les ports ne sont pas ouvert et les protocoles genre tcp désactivé. Il faut passer par l’utilitaire de conf pour changer ce qui va bien pour avoir l’accès à distance avec obligatoirement un user/password.
Le 06/01/2017 à 06h02
C’est quoi ces admin système en carton ?
Le 06/01/2017 à 06h43
Pas sûr que ce soit des admin système…
Le 06/01/2017 à 08h16
Bon on commence tous par un tuto (oui c’est un des moments le plus fun !)… mais ensuite il y a l’expérience et le métier … de la prod justement ! (design, test, maquette, redaction, pilote, mise en pro, maintenance , rextex etc ….)
Moi ca fait plus de 25 ans … lol.
Le 06/01/2017 à 10h16
Le 06/01/2017 à 13h15
C’est pas des admins système.
C’est une floppée de webdevs front à qui des malades ont promis des technos backend adaptées à leur niveau.
Le 06/01/2017 à 15h03
Le 06/01/2017 à 15h51