MongoDB : « les développeurs ne veulent pas d'authentification par défaut »

Silicon.fr : Comment expliquez qu'autant d'instances de MongoDB soient librement accessibles sur Internet ? A ce jour, on recense environ 30 000 instances MongoDB prises en otages par divers groupes de cybercriminels.

Mat Keep : D'abord, il faut remettre les chiffres en perspective. Chaque jour, MongoDB est téléchargé environ 30 000 fois. On parle donc de très petits pourcentages d'utilisateurs rançonnés au regard de la base installée, même si, évidemment, les personnes ou organisations infectées trouvent ces chiffres trop élevés. Le problème est circonscrit à des utilisateurs qui ont négligé d'activer leur authentification ou leur contrôle d'accès. Rappelons que tous les outils pour mettre en place ces fonctionnalités sont disponibles dans MongoDB, mais que ces fonctions doivent être activées.

Réfléchissez-vous à activer ces fonctions par défaut ?

M.K. : Pour l'instant, les utilisateurs reçoivent un avertissement quand ils n'activent pas la fonction d'authentification. Nous réfléchissons à modifier cet état de fait. Mais nous devons tenir compte des attentes de certains développeurs, qui ne veulent pas se voir imposer une étape d'authentification à chaque redémarrage lors des étapes de développement d'une application. Un grand nombre de développeurs préfèrent activer cette fonctionnalité uniquement quand ils passent en production. Si nous imposons l'authentification, nous aurons une réaction de la communauté des développeurs, qui voudra désactiver cette fonction tant que l'instance ne passe pas en production. Ce qui, in fine, reviendrait à un statu quo par rapport à la situation actuelle.

Connaissez-vous la proportion d'instances prises en otage renfermant des environnements de développement, et celle des instances en production ?

M.K. : Rien dans le logiciel ne permet de déterminer la part d'instances en développement et celle en production. Mais, même si laisser une instance librement accessible sur Internet n'est pas une bonne pratique y compris lors des étapes de développement, on peut toutefois estimer qu'une large part des environnements pris en otages relève de ces étapes.

Dans un billet de blog, vous conseillez à vos clients victimes d'ouvrir un ticket de support en cas de détournement d'une de leurs bases. Combien de tickets de cette nature dénombrez-vous aujourd'hui ?

M.K. : Aucun, tout simplement parce que, pour ces applications critiques, pour lesquelles nos clients investissent en support, des services sont là pour s'assurer que l'authentification et tous les services de sécurité sont bien en place. Il en va de même du service Cloud Mongo DB Atlas, sur lequel l'authentification et le chiffrement SSL sont activés par défaut. Rappelons que les cybercriminels n'exploitent pas une vulnérabilité de MongoDB, mais se contentent de prendre le contrôle de bases laissées librement accessibles. Nous avons eu quelques contacts avec des utilisateurs de la communauté (ceux employant la version Open Source du produit, NDLR) dont les bases ont été prises en otages, et à qui nous avons conseillé de d'abord verrouiller leurs environnements avant de repartir de leurs sauvegardes. Mais ces contacts se comptent en dizaines, non en centaines. Et la plupart des environnements concernés étaient des environnements de production laissés de côté par leurs utilisateurs au moment de passer à une autre étape de leur projet.

A lire aussi :

Après MongoDB, les instances Elasticsearch rançonnées

Epidémie pour MongoDB : 28 000 serveurs pris en otage

Comment le ransomware est devenu le gagne-pain des cybercriminels