Si les ransomwares sont efficaces contre les ordinateurs classiques, ils le sont également contre les serveurs. C’est particulièrement le cas pour les bases de données, comme plus tôt dans l’année avec MongoDB. Mais le problème existe également avec Hadoop pour le big data, comme l’indique John Matherly, fondateur du moteur Shodan.
WannaCrypt a rappelé que les ransomwares ont de beaux jours devant eux. Profiter d’une faille de sécurité et/ou d’une faiblesse de l’utilisateur, chiffrer les données puis réclamer une rançon pour lui redonner l’accès. Les sommes demandées sont souvent de l’ordre de quelques centaines d’euros, mais les pirates savent aussi qu’ils peuvent obtenir bien davantage en s’attaquant à de plus gros poissons.
L’efficacité d’un ransomware tient avant tout à la sensibilité des données présentes sur la machine. Si l’utilisateur n’a rien de vraiment important, il peut formater et réinstaller un système au propre. Autant s’attaquer donc à des structures où les informations ont nettement plus de chances d’être importantes. Notamment les serveurs.
Attaquer où sont les données, parce que c’est possible
Dans un billet de blog paru en fin de semaine dernière, le fondateur de Shodan, John Matherly, explique que les installations Hadoop sont en danger. Hadoop est pour rappel un framework libre développé en Java, qui permet de distribuer des données massives sur un grand nombre de nœuds, qui peuvent être eux-mêmes constitués de grappes de serveurs. On est donc clairement dans le big data.
Il s’est servi de son moteur de recherche, spécialisé dans le balayage massif de ports, pour trouver ainsi de vastes bases de données utilisant HDFS (Hadoop Distributed File System). Il a trouvé plus de 4 500 d’entre elles, visibles sur Internet car disposant d’une IP publique et caractérisées par un problème bien particulier : elles sont accessibles puisque leur configuration n’intègre pas d’authentification.
Un problème qui n’est pas nouveau, mais qui s'intensifie
Des bases de données disponibles publiquement car des administrateurs n’ont pas fait correctement leur travail : un constat que l’on pouvait déjà faire il y a quelques mois. On se rappelle en effet qu’un lot de 47 800 serveurs étaient ainsi accessibles sur Internet, exposant des bases MongoDB qui n’avaient pas été correctement sécurisées. Là aussi, il était possible d’aller piocher dans les données sans avoir besoin de s’authentifier.
Matherly indique que la situation est d’ailleurs loin d’être réglée. Et tandis que de vieilles instances MongoDB sont toujours exposées et peuvent subir des attaques de ransomwares, le problème s’étend désormais aux bases Hadoop. Or, il peut avoir des conséquences plus importantes, puisque toujours selon le fondateur de Shodan, la quantité de données n’est plus la même : on parle ici de 5 Po, soit 5 000 To.
La plupart de ces bases sont dans des instances distances de type Amazon EC2 ou Alibaba. Sur les 4 500 bases trouvées via le moteur, 1 900 sont aux États-Unis, 1 426 en Chine, suivies loin derrière par 129 en Allemagne et 115 en Corée du Sud. Toutes ont le même trou béant dans leur sécurité : l’accès direct en lecture et écriture, avec donc la possibilité de voir les données chiffrées par un ransomware. Quand on sait qu'elles sont le plus souvent utilisées par de grandes entreprises, la situation a de quoi inquiéter.
Des bases créées rapidement avec une configuration par défaut
On ne peut évidemment pas savoir dans quel contexte sont exactement créées ces bases. La situation laisse toutefois imaginer qu’elles ont été mises en place dans des instances cloud « pour aller vite », les administrateurs ou développeurs n’ayant pas touché aux paramètres de sécurité. Elles ne devraient pas être accessibles via une IP publique, ou alors uniquement avec un mécanisme d’authentification.
Ce n’est pourtant pas faute du côté d’Hadoop d’avoir publié depuis longtemps un guide complet pour le Secure Mode abordant les bases de la sécurité, avec l’authentification, la confidentialité des données, la configuration du système HDFS, la gestion des ressources et des nœuds, le paramétrage de MapReduce (traitement des données) ou encore les installations multihome.
John Matherly se demande pour sa part pourquoi la situation n’évolue pas plus rapidement. 207 instances HDFS semblent déjà compromises et affichent un message que les administrateurs ne peuvent normalement pas manquer. Du côté de MongoDB, c’est encore pire : la majorité des instances semble toujours contaminée, et ce depuis plusieurs mois.
Matherly propose à la fin de son billet des explications sur la manière de créer un script en Python permettant de mesurer la quantité de données compromises.
La route vers la sécurité sera encore longue
Cette situation rappelle dans tous les cas le peu d’attention porté souvent à la sécurité de solutions embarquant de nombreuses données, parfois personnelles. Ce problème se retrouve largement dans le monde des objets connectés comme on a pu le voir avec Mirai. Il est différent de certaines attaques tablant sur des méthodes particulières et l’exploitation de failles techniques, puisque les pirates n’ont ici qu’à se servir.
L’accumulation d’actualités sur la sécurité depuis quelques années devrait pourtant inquiéter – à juste titre – les administrateurs et développeurs, mais la route semble encore bien longue.
Commentaires (14)
Concernant MongoDB, comment dire… On fait comment quand les développeurs n’utilisent aucun système d’authentification pour la base de données ?
J’ai le problème avec Etherpad et Habitica. Pour Etherpad, faut que je regarde la doc du logiciel, car j’avais rien dans le tuto de framasoft (plus trop à jour d’ailleurs), mais pour habitica, j’ai pas grand chose non plus.
Ceci dit, y’a quasiment rien dessus, rien d’important et surtout, elles ne sont pas accessibles depuis le net, c’est déjà ça.
Par contre, pour Hadoop, là, j’en suis baba qu’à ce niveau, les admins ne sécurisent pas, surtout que c’est expliqué dans la doc, et que ça ne se déploie pas comme ça surtout. Y’a un minimum de réflexion à avoir quand on bosse avec Hadoop.
y’a pas un équivalent pour hadoop de mysql_secure pour mariaDB ou MySQL ? je ne sais pas, je ne connais pas. Par défaut hadoop écoute partout ? parce que mariaDB par défaut ça n’écoute que 127.0.01 (local donc)
La situation laisse toutefois imaginer qu’elles ont été mises en place dans des instances cloud « pour aller vite », les administrateurs ou développeurs n’ayant pas touché aux paramètres de sécurité.
Il faut se faire à l’idée que le déploiement d’appli (notamment web/internet) n’est plus l’affaire de spécialiste de cette discipline (aka. sysadmin/netadmin).
C’est le développeur (en chef) qui s’occupe de plus en plus de cette partie. Au mieux il suivra un tutoriel trouvé sur google et au pire, comme ici, il copie/colle l’environnement de dev sur un serveur prod.
Moralité: on fait remonter le problème upstream => le composant (ici Hadoop) doit assurer sa propre sécurité car on ne peut pas faire confiance au dev applicatif pour sécuriser son application… c’est triste.
Les éditeurs de ces solutions appâtent les utilisateurs par des setups en 2 clics qui permettent de démarrer un tuto rapidement pour un effet whaou maximum (apt install mongodb -> mongo -> requête -> ça marche !).
Ils négligent complètement l’aspect sécurité pour ne pas rebuter les développeurs enthousiastes et souvent peu expérimentés qui viennent grossir la communauté et font de la solution le standard de fait. Il s’agit d’un domaine extrêmement concurrentiel, alors les bonnes pratiques sont considérées comme secondaires par rapport au buzz que doit générer la solution.
Ce monde merveilleux des solutions géniales et faciles masquent complètement le fait qu’administrateur de bases de données est un vrai métier qui ne s’improvise pas entre deux scripts vite faits. Ces piratages à répétition sont là pour nous le rappeler.
mais tant mieux, que ça crashe et rançonne à tout va, ça fera du boulot
" />
" />
bande d’amateurs bobo-commerciaux
Je suis amateur des solutions apt install pif paf pouf ca fonctionne mais jamais je ne néglige la sécurité. C’est même ma première préoccupation des la fin de l’install.
Concernant Etherpad, pour en avoir installé un récemment c’est expliqué pour l’authentification de la base de données, dans leur exemple mongoDB au lieu de dirty.
Le lien qui va bien :https://framacloud.org/cultiver-son-jardin/installation-detherpad/
J’aime bien le nom du moteur….SHODAN. John Matherly est un fan de System Shock?
" />
Oui 
" />
Justement, quand tu regarde la connexion à la base MongoDB, y’a pas de login mot de passe pour MongoDB.
Par contre, la conf MySQL, là, on te demande la totale.
Après, c’est comme Redis, quand tu regarde la doc de Redis, on te dis clairement que Redis ne doit pas être accessible de l’extérieur, car en gros, il n’y a quasiment pas de sécurité.
Le problème d’Hadoop c’est qu’il y a 15 000 composants qui s’installe et doivent écouter sur différents ports. Du coup, même les guides officiels d’installation demande aux utilisateurs en pré-requis de désactiver les firewall des machines… A partir de ce moment là, sécuriser je veux bien mais si c’est pour passer 1 semaine à faire tout fonctionner (PI : la liste des ports est rarement fournis)
Dans ces cas là il faut soit changer de produit, soit tout coller derrière un firewall.
Même si on ne fait pas trop attention à son install, je ne comprends pas comment on peut se retrouver avec des machines exposées sur internet par accident (ou avec ‘trop de ports ouverts’ par accident). Même les routeurs grand public nécessitent une opération manuelle pour rendre des serveurs/ports accessibles.
Et ça c’est clairement le rôle des admins, ça devrait pas être les devs qui se retrouvent à le gérer comme ça peut arriver avec l’install du serveur de BDD.
D’ailleurs, même le dev, s’il ne comprends rien à la sécurité (le mdp c’est quand même le niveau zéro), c’est assez inquiétant.