Utiliser des solutions open source peut s’avérer dangereux

Le mois dernier, la base de données open source MongoDB, spécialiste du stockage d’information orienté document, star incontournable du monde du Big Data, était sous les feux de la rampe, mais pour de mauvaises raisons ; des failles de sécurité auraient permis le piratage de données.

À MongoDB s’est rapidement adjoint, pour des causes similaires, ElasticSearch, autre immanquable des solutions open source Big Data mais dans un domaine différent, l’indexation et la recherche de données.

Gare toutefois aux conclusions hâtives, l’histoire est plus surprenante qu’il n’y paraît ; d’autant plus qu’elle est récurrente, MongoDB a connu plusieurs fois ce type d’attaque dans le passé. Pourtant, aucun de ces produits prisés en entreprise de doivent directement être incriminés ; ils ont toutefois permis la résurgence d’un ancien débat sur internet : y a-t-il un risque à déployer de l’open source ?

Mais que s’est-il exactement passé ?

Posons tout d’abord le contexte.

Si virus et chevaux de Troie classiques sont encore légion, c’est sous l’apparence de ransomware que ces bouts de code sont les plus intéressants pour des cybercrimels car ils permettent de monnayer leurs activités. La philosophie du ransomware est en substance basique : kidnapper les données d’une entreprise ou d’un particulier et les échanger contre pécule. Ce pécule prend souvent la forme de BitCoin, la monnaie numérique ne nécessitant pas d’autorité centrale, permettant le paiement anonyme, en ligne, et à l’origine de la blockchain, cette technologie qui est si souvent relayée dans nos actualités IT, qui intéresse pour son côté novateur les banques, assurances et ceux qui gravitent autour des systèmes de paiement.

Le ransomware peut prendre plusieurs formes ; classiquement il s’infiltre dans un système via des failles de sécurité ou suite à des actions malencontreuses d’un utilisateur qui permet à son insu une installation. Une fois déployé le ransomware chiffre in situ, grâce à une clé informatique, les données ou systèmes d’exploitation auxquels il a accès. Il en monnaye ensuite le déchiffrage via un message précisant à l’utilisateur la démarche de paiement à suivre.

Autre fonctionnement, le ransomware peut copier les données d’un tiers avant de les effacer de son système puis exiger de l’argent pour leurs restitutions. Cette procédure peut s’avérer amplement plus simple que la précédente si le tiers protège mal ses données. Nul algorithme de chiffrement/déchiffrement, nul véritable piratage, nulle véritable intelligence ; une véritable aubaine pour un programmeur. Dans les technologies d’accès aux données, il y a toujours des méthodes documentées pour créer, lire, mettre à jour ou supprimer des données ; ce que l’on dénomme CRUD (Create, Read, Update, Delete) ; elles peuvent s’avérer suffisantes si un système n’est pas hermétique aux attaques.

Que s’est-il passé pour MongoDB et ElasticSearch ?

Fin décembre, un cybercriminel du nom de harak1r1 s’est évertué à attaquer des bases de données MongoDB avec cette dernière technique. Rien d’impressionnant techniquement, mais quelque chose de diablement efficace qui a rapidement inspiré d’autres pirates. Mi-janvier, environ 35 000 bases MongoDB étaient piratées selon des chercheurs en sécurité (Victor Gevers, Niall Merrigan), sur un ensemble de près de 100 000 bases piratables selon John Matherly, le fondateur de shodan.

Devant une telle propagation, d’autres pirates se sont attaqués à ElasticSearch, plus de 5000 bases ont ainsi été « kidnappées » alors qu’était estimé à 35 000 le nombre de déploiements ElasticSearch potentiellement attaquables.

Comment peut-on savoir ces chiffres ?

Il est possible d’estimer les bases attaquées et connaître potentiellement celles qui peuvent l’être via des moteurs de recherche comme shodan qui détectent les bases accessibles directement sur internet. Il est au demeurant possible de savoir les sociétés ayant accepté le paiement pour récupérer leurs données. En effet le bitcoin est d’une totale transparence sur les échanges même si l’identification des individus est problématique ; il suffit de connaître l’adresse de paiement, laquelle est fournie lorsque le ransomware a commis son méfait. Dans le cas de MongoDB, le pirate originel harak1r1 qui a été suivi par tous les autres a ainsi fait une vingtaine de transactions.

Que savoir ?

Il ne s’agit en réalité pas d’un problème de sécurité, et ce, ni pour MongoDB, ni pour ElasticSearch. Ces produits sont hors de cause, car il ne s’agit ni d’une faille ni d’un bug ou mauvaise implémentation ayant permis la réalisation de ces exploits. Il s’agit d’un problème de fond aux conséquences dramatiques : ceux qui ont utilisé ces produits avaient une méconnaissance totale des techniques de sécurisation de ces produits. Tant MongoDB qu’ElasticSearch possèdent le nécessaire pour sécuriser entièrement leurs données, mais leur déploiement par défaut est volontairement ouvert et d’une grande souplesse. Cette logique est explicitée dans leur documentation : ils reposent sur une logique d’architecture où par défaut les données sont isolées du reste du monde avec un mode d’accès simple, extrêmement puissant et performant dans leurs cas d'usage. En dehors de ce modèle, il faut être d’une vigilance extrême ; c’est indiqué, connu et répété par ces éditeurs. Cette vigilance doit s’accroitre au fur et à mesure que l’on s’expose ; l’exposition au web est d’ailleurs à proscrire en termes d’architecture. Or toutes les bases qui ont été attaquées étaient majoritairement déployées dans le cloud ; ce qui n'est pas un souci ; mais elles étaient en plus accessibles, sans la moindre mise en œuvre de mécaniques de protection pourtant indiquées et surtout recommandées par les éditeurs. MongoDB Inc a ainsi intensément communiqué sur les procédures à suivre pour rectifier ces réglages tout en insistant que ses clients, ceux qui font appel à son support, ses experts, qui utilisent ses solutions de déploiement ou son service de cloud (Atlas) n’ont eu de souci.

Utiliser des solutions open source, est-ce dangereux ?

Le débat a de nouveau fait rage entre les pros et les antis. Ne tergiversons pas, oui il est dangereux de déployer une solution open source. Mais, ne polémiquons pas, ça ne l’est ni plus ni moins, que déployer une solution non open source. Nous ne sommes en effet plus à l’ère d’un combat stérile entre les partisans d’un camp ou de l’autre ; les solutions open source comme les autres font leurs preuves tous les jours dans de multiples environnements. Mieux, elles travaillent de concert et en tirent des synergies. Microsoft n’hésite par exemple pas à s’afficher avec un « Microsoft loves Linux », ainsi que de mettre en avant une pléthore de solutions open source, notamment dans son cloud Azure. Oui, Microsoft aime Linux, mais aussi Docker, NodeJs, Hadoop, Cassandra,…

Tout logiciel porte en son sein une potentialité de bug ou de faille et est, ce faisant, dangereux si l’on ne connait ou ne considère pas les contraintes de sécurité lors des déploiements. Nous sommes en outre dans une époque où l’on cherche énormément de devops, à savoir des développeurs avec une dimension infrastructure, ce qui implique des connaissances système, réseau, bases de données. Cette vision transverse de plusieurs métiers IT est des plus intéressantes, mais elle ne signifie pas de se passer de conseils avisés d’experts, ou a minima de se renseigner tout azimut, lors de phases extrêmement importantes dans la vie d'un projet, notamment son déploiement. Car quand la sécurité est en jeu, tout est potentiellement dangereux.