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.
Commentaires (57)
#1
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
#2
Une configuration MongoLienne.
Je suis deja loin…
#3
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%
#4
Ma conf par défaut avait déjà cette config mais merci pour la piqûre de rapel 
" />
#5
Il y avait eut un article de nextinpact il y a presque 2 ans sur le sujet :
https://www.nextinpact.com/news/93037-mangodb-bdd-librement-accessibles-dont-celle-dun-operateur-francais.htm
Faut croire que ça n’a pas servi de leçon aux admins …
#6
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.
#7
#8
#9
il est également conseillé de configurer firewallé le trafic sur le port 27017
#10
Avec un simple tuto bien fait , super simple pour mettre en place la base … et ruleZZZZZ !
#11
#12
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.
#13
#14
eh oui les économies …
#15
#16
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.
#17
#18
#19
#20
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
#21
Ah oui, des backup non versionnées ça ne sert à rien effectivement ! 
" />
#22
#23
#24
#25
#26
#27
#28
#29
quoi, un backup c’est pas cp -ar données/ backup/ ?
" />
(avec le serveur en fonctionnement ofc)
#30
#31
#32
#33
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…..
#34
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.
#35
“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é !
#36
un tout petit peux plus compliqué
https://docs.mongodb.com/manual/security/
/usr/local/etc/mongodb.conf
#37
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.
#38
#39
#40
#41
#42
T’en es à 11, Ricards. Ça fait un peu beaucoup.
" />
Allez, c’est la mienne!
#43
#44
#45
#46
ca va?
Allez, viens, on va te ramener.
#47
#48
#49
#50
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.
#51
C’est quoi ces admin système en carton ?
#52
Pas sûr que ce soit des admin système…
#53
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.
#54
#55
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.
#56
#57