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.