D'après des chercheurs, plus de 35 000 instances Elasticsearch sont ouvertes sur internet. Lors de l'établissement des premières statistiques, 360 d'entre elles avaient été répertorié comme ayant subi une attaque dont le mode opératoire rappelle celui qui a été utilisé dans les attaques contre les instances MongoDB et ont fait tomber plus de 27 000 instances en l’espace d’une semaine : données dupliquées, originaux effacés puis demande de rançon avec un message à l’appui. L’un des administrateurs qui en a été la victime a partagé le message qu’il a trouvé, notamment « send 0.2 bitcoins to this wallet: 1DAsGY4Kt1a4LCTPMH5vm5PqX32eZmot4r if you want recover (sic) your database! Send to this email your service IP after sending the bitcoins p14t0s@sigaint.org (sic) ». Mais, le chercheur en sécurité Niall Merrigan, qui a suivi les attaques lancées sur MongoDB de près, a mis à jour ce chiffre et a signalé plus de 600 instances Elasticsearch prises en otage dont la plupart sont hébergés aux États-Unis (245 instances), mais aussi en Chine (59 instances) et en France (52 instances), ces trois pays étant les plus touchés par ces attaques.
Répartition des serveurs Elasticsearch exposés sur internet
Cette campagne d’attaques s’avère être une menace pour de nombreux services ouvert. D’ailleurs, des organismes comme l'Australian Communications and Media Alliance (ACMA) en établisse des statistiques journalières. Pour ce cas particulier, c’est son Australian Internet Security Initiative (AISA) qui se charge des observations sur le territoire australien. Le 11 janvier dernier par exemple, l’AISA a noté que 366 instances MongoDB étaient ouvertes, contre 141 du côté d’ElasticSearch.
Ces statistiques montrent également que l'Interface de gestion intelligente de matériel, (ou IPMI, Intelligent Platform Management Interface) pourrait également être la cible des attaquants par le nombre important d’instances ouvertes répertoriées (1362 le 9 janvier, contre 498 chez MongoDB le même jour). Pour rappel, l’IPMI est un ensemble de spécifications d'interfaces communes avec du matériel informatique (principalement des serveurs) permettant de surveiller certains composants (ventilateur, sonde de température, ...), mais également de contrôler l'ordinateur à distance, reboot, interrupteur, console à distance. En clair, IPMI peut être vu comme une technologie qui donne aux administrateurs un contrôle presque total sur les serveurs déployés à distance.
Itamar Syn-Hershko, consultant Elasticsearch, a publié un billet pour proposer aux administrateurs comment configurer les clusters Elastic afin de ne pas voir leurs données être victimes d’une prise d’otage. « Quoique vous fassiez, ne laissez jamais exposés vos nœuds de cluster au Web. Cela semble aller de soi, mais évidemment vous ne le faites pas tous. Votre cluster ne devrait jamais être exposé sur le web publique », a-t-il prévenu.
Mike Paquette, de l'équipe d'ingénierie d'Elastic, a également publié un blog expliquant comment protéger Elasticsearch contre ces attaques. Bien que la version d'Elasticsearch hébergée sur AWS soit sécurisée par défaut, Elasticsearch lui-même n'effectue pas d'authentification ou d'autorisation et doit donc être configuré correctement lorsqu'il est accessible par des utilisateurs non approuvés.
Selon les conseils de sécurité de la société en 2013: « Elasticsearch n'a aucun concept d'utilisateur. Essentiellement, quiconque peut envoyer des demandes arbitraires à votre cluster est un super utilisateur ».
Paquette a expliqué qu'Elastic « recommande fortement que les instances non sécurisées d'Elasticsearch ne soient pas directement exposées sur internet ».
Pour les clusters Elasticsearch non gérés par Elastic, la société recommande de prendre les mesures suivantes :
- effectuer des sauvegardes de toutes vos données dans un emplacement sécurisé et pensez à utiliser Curator ;
- reconfigurez votre environnement pour exécuter Elasticsearch sur un réseau non-routable isolé ;
- ou si vous devez accéder au cluster via Internet, restreignez l'accès à votre cluster depuis internet via un pare-feu, un VPN, un proxy inverse ou toute autre technologie.
Source : ACMA, Niall Merrigan, John Matherly, blog Elastic, conseils de sécurité de la société (2013), billet Itamar Syn-Hershkov
Voir aussi :
Les instances MongoDB prises en otage sont passées de 12 000 à plus de 27 000 en moins de 12 heures, d'après un chercheur 
