Le piratage de MongoDB et l’importance des paramètres sécurisés par défaut

Si vous avez installé MongoDB, c’est le moment de vérifier que votre installation est sécurisée. Depuis juste avant Noël, plus de 28 000 installations MongoDB accessibles publiquement ont été piratées. Les attaquants retiennent les données volées en otage et exigent que les entreprises paient en bitcoins pour les récupérer. À première vue, au moins 20 entreprises ont déjà cédé et payé la rançon. Cet article explique le piratage, comment vous protéger et ce que nous pouvons en retenir.

Comprendre le piratage

Le piratage lui-même est alarmant de simplicité. À partir de la version 2.6.0, MongoDB inclut un fichier de configuration par défaut qui lie MongoDB à 127.0.0.1 par défaut. La base de données n’écoute donc que les connexions locales.

Ce n’était pas le cas avant la version 2.6.0. Par défaut, MongoDB était accessible aux connexions à distance. L’authentification n’étant pas non plus obligatoire par défaut, les installations de MongoDB antérieures à la version 2.6.0 acceptaient sans problème les connexions distantes non authentifiées.

Les utilisateurs pouvaient tout de même limiter l’accès aux connexions locales en prenant le temps de configurer l’installation, mais il fallait pour cela ajouter manuellement une ligne à leur fichier mongodb.conf. Comme ce n’était pas la configuration par défaut, de nombreuses installations existantes n’ont jamais bénéficié de cette étape cruciale.

Pour ne rien arranger, il est facile d’identifier les installations MongoDB susceptibles d’être attaquées. Le port par défaut de MongoDB est le 27017. À l’aide d’un moteur de recherche comme ZoomEye, vous pouvez rechercher des installations MongoDB, voir sur quels ports elles sont accessibles et trouver environ 100 000 installations vulnérables.

Cette vulnérabilité n’a rien de nouveau. Le problème a été signalé pour la première fois en 2012 et rendu public vers 2015. Toujours au début de 2015, John Matherly avait fait parler de lui en signalant avoir trouvé environ 30 000 installations MongoDB mal sécurisées. Autrement dit, tout le monde aurait pu être au courant depuis longtemps.

Le problème des paramètres par défaut non sécurisés

L’absence de paramètres par défaut sécurisés n’est pas un problème mineur. Étude après étude après étude, les résultats montrent que la plupart des gens conservent les paramètres par défaut qui leur sont proposés. Les paramètres par défaut comptent.

Certains pourraient faire valoir que ces paramètres par défaut non sécurisés visent à trouver un équilibre entre facilité d’utilisation et sécurité, et qu’ils reposent sur des hypothèses raisonnables. Par exemple, si l’on peut raisonnablement supposer que, dans la grande majorité des cas, une base de données sera installée derrière un pare-feu, on peut décider que ne pas limiter une base de données aux connexions locales constitue un paramètre par défaut raisonnable.

Mais de telles hypothèses sont dangereuses, car lorsqu’une personne fait quelque chose qui invalide cette hypothèse, et non si cela arrive, elle devient vulnérable aux attaques, sans même forcément le savoir. Les risques de sécurité potentiels liés à ces paramètres par défaut sont loin d’être connus de tous. À moins qu’une entreprise ne dispose d’experts en sécurité chargés d’examiner chaque décision (ce qui est une bonne idée, mais pas toujours le cas), ces paramètres par défaut non sécurisés peuvent — et souvent vont — passer inaperçus.

Suivre les paramètres par défaut non sécurisés

Le problème des paramètres par défaut non sécurisés ne s’arrête pas là.

Imaginons que votre organisation soit responsable et utilise un outil comme Snyk pour analyser ses outils et dépendances à la recherche de vulnérabilités. Ces outils ne signaleront pas ce problème, car les paramètres par défaut non sécurisés ne sont généralement pas considérés comme des vulnérabilités. En effet, il ne s’agit pas ici d’un bogue ou d’une vulnérabilité dans le code, mais d’un problème de configuration.

Cela se comprend dans une certaine mesure, mais la question se pose : devrait-il exister un identifiant officiel et une base de données consacrés aux paramètres par défaut non sécurisés ?

D’un côté, un service signalant les paramètres par défaut non sécurisés générerait inévitablement du bruit. Il en existe beaucoup, et certaines organisations les auront déjà corrigés. Elles devraient alors déterminer si le problème les concerne encore, ce qui n’est pas toujours simple. Dans le cas contraire, elles pourraient simplement ignorer le signalement et passer à autre chose.

Mais signaler les paramètres par défaut non sécurisés pourrait être précieux pour les utilisateurs qui n’ont pas encore repéré ces problèmes. Cela pourrait les alerter sur des risques de sécurité qui, autrement, resteraient ignorés et ne seraient pas corrigés — potentiellement pendant des années, comme dans le cas de MongoDB.

Signaler les paramètres par défaut connus comme non sécurisés dans une base de données open source (comme nous le faisons pour signaler les vulnérabilités connues) n’aurait pas empêché cette attaque, mais aurait pu éviter qu’au moins certaines bases de données soient touchées.

Et maintenant ?

Tout d’abord, sécurisez votre installation MongoDB. Nous attendons.

Maintenant que vous êtes de retour, ce piratage montre à quel point les paramètres sécurisés par défaut sont essentiels. La sécurité est trop importante pour être laissée au hasard. Tout comme le secteur a progressivement admis que les sites devaient utiliser HTTPS par défaut, les auteurs de packages devraient faire leur possible pour que leurs packages soient sécurisés par défaut. Un paramètre par défaut non sécurisé peut causer autant de dégâts qu’une vulnérabilité connue. On comprend que les développeurs de ces outils souhaitent proposer une installation aussi simple que possible, mais si le paramètre par défaut est aussi non sécurisé, on aboutit à des situations comme celle que les utilisateurs de MongoDB connaissent actuellement.

Ces attaques soulèvent une autre question : est-il temps de commencer à répertorier les paramètres par défaut non sécurisés dans une base de données open source ? Chez Snyk, nous discutons régulièrement de la pertinence de classer ces défauts comme des vulnérabilités, et nous continuerons probablement à en débattre encore longtemps. Si vous avez un avis tranché sur la question, dites-le-nous, par e-mail ou sur Twitter. En attendant, si vous souhaitez vérifier si vos dépendances cachent des risques de sécurité, analysez rapidement vos dépôts avec Snyk.