IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La nouvelle attaque "Meow" a maintenant effacé près de 4 000 bases de données,
Ciblant les instances ElasticSearch, MongoDB et d'autres systèmes non sécurisés

Le , par Stan Adkens

632PARTAGES

13  0 
Environ 4000 bases de données en ligne ont été effacées de manière permanente par un mystérieux attaquant, sans autre raison apparente que celle d'être mal configurées et exposées à l'Internet public. L’agresseur ne laisse aucune revendication à part le mot "Meow", selon les recherches effectuées sur Internet par des chercheurs. L'attaque automatisée a commencé en début de la semaine dernière en frappant des instances Elasticsearch et MongoDB non sécurisées sans laisser d'explication, ni même de demande de rançon. Les attaques se sont ensuite étendues à d'autres types de bases de données et aux systèmes de fichiers ouverts sur le Web, d’après les chercheurs.

En début de semaine, les recherches effectuées par des chercheurs en sécurité sur le moteur de recherche Shodan ont initialement trouvé des dizaines de bases de données qui ont été touchées par cette attaque. Mais le nombre de bases de données effacées a rapidement augmenté pour passer à plus de 1800. Ces attaques ont poussé les chercheurs dans une course pour trouver les bases de données exposées et les signaler de manière responsable aux propriétaires avant qu'elles ne soient la cible de la nouvelle attaque.


Le chercheur Bob Diachenko a été le premier à remarquer la campagne après avoir découvert une base de données mal configurée appartenant à UFO VPN basé à Hong Kong, dont les détails des utilisateurs de VPN qu’elle stockait avaient été détruits. Le 1er juillet 2020, le chercheur avait déjà découvert la base de données Elasticsearch qui exposait des journaux d'utilisateurs et d'enregistrements d'accès à l'API sur le Web sans mot de passe ou toute autre authentification requise pour y accéder. Il a immédiatement alerté l'entreprise dès la découverte des données exposées.

Après que les données ont été sécurisées, elles ont refait surface une seconde fois le 20 juillet à une adresse IP différente, avec un ensemble de données encore plus important qui contenait des enregistrements plus récents. Cette deuxième fois, cependant, UFO VPN n'a plus reçu de notification bien intentionnée pour protéger à nouveau les données utilisateur ainsi que celles de l’entreprise. Au lieu de cela, les attaquants ont été les premiers à découvrir l’exposition, et presque tous les enregistrements ont été effacés, en laissant les mots "Meow" et une chaîne de nombres aléatoires.


Les données écrasées comprennent les mots de passe des comptes en texte clair, les jetons de session VPN, les adresses IP des appareils des utilisateurs et des serveurs VPN auxquels ils se sont connectés, l’horodatage des connexions, les caractéristiques des appareils et du système d'exploitation, les domaines apparents à partir desquels des publicités sont injectées dans les navigateurs Web des utilisateurs gratuits, et bien d’autres données.

Ces données sont découvertes par les chercheurs alors que le fournisseur de VPN hongkongais avait déclaré ne pas conserver de journaux sur les utilisateurs : « Nous ne collectons aucune information pour l'enregistrement », avait déclaré le porte-parole de UFO VPN. « Dans ce serveur, toutes les informations collectées sont anonymes et ne sont utilisées que pour analyser les performances et les problèmes du réseau de l'utilisateur afin d'améliorer la qualité du service. Jusqu'à présent, aucune information n'a fait l'objet de fuites ».

La société a réagi après la notification de Diachenko en déplaçant la base de données vers un autre endroit, mais une fois de plus, elle n'a pas réussi à la sécuriser correctement. Peu de temps après, l'attaque Meow l'a anéantie. « Après que les données exposées aient été sécurisées, elles ont refait surface une seconde fois le 20 juillet à une adresse IP différente - tous les enregistrements ont été détruits par une nouvelle attaque du robot "Meow" », a tweeté Diachenko en début de semaine.


Victor Gevers, le président de la fondation à but non lucratif GDI, a également été témoin de la nouvelle attaque. Il affirme que l'acteur s'attaque également aux bases de données MongoDB exposées. Le chercheur a observé jeudi que celui qui est derrière l'attaque vise apparemment toute base de données qui n'est pas sécurisée et accessible sur Internet.

Des instances Elasticsearch, MongoDB, Redis et d’autres systèmes non sécurisés ciblés par l’attaque "Meow"

En plus des bases de données Elasticsearch et MongoD, Gevers a vu ces attaques d'effacement de données sur des systèmes fonctionnant sous Cassandra, CouchDB, Redis, Hadoop, Jenkins, ainsi que sur des périphériques de stockage connectés au réseau. A la date du 22 juillet, l’attaque avait surtout touché les bases de données Elasticsearch (1 395 instances), suivies de MongoDB (383 instances) et de Redis (54 instances). De nouvelles recherches effectuées samedi sur Shodan ont montré que plus de 3800 bases de données ont des noms d'entrées correspondant à l'attaque "Meow". Plus de 97 % d'entre elles sont des bases de données Elasticsearch et MongoDB.

Selon LeakIX, un projet qui indexe les services ouverts, Apache ZooKeeper a également été ciblé par l’attaque. Une autre attaque, moins malveillante, a également marqué 616 fichiers ElasticSearch, MongoDB et Cassandra avec la chaîne "university_cybersec_experiment". Les chercheurs ont suggéré que, dans ces attaques, les attaquants semblent démontrer aux responsables des bases de données que les fichiers sont vulnérables à la visualisation ou à la suppression.

Ce n'est pas la première fois que des attaquants ciblent des bases de données non sécurisées, qui sont devenues de plus en plus courantes avec l'utilisation croissante des services de Cloud Computing d'Amazon, de Microsoft et d'autres fournisseurs. Dans certains cas, la motivation est de gagner de l'argent grâce aux demandes de rançon. Dans d'autres cas, notamment les attaques Meow actuelles, les données sont simplement effacées sans note de rançon ni autre explication.

« Je pense que dans la plupart [des derniers] cas, les acteurs malveillants derrière les attaques le font juste pour le plaisir, parce qu'ils le peuvent et parce que c'est vraiment simple à faire », a dit Diachenko dans une déclaration. « Ainsi, c'est un nouveau signal d'alarme pour l'industrie et les entreprises qui ignorent la cyber hygiène et perdent leurs données et celles de leurs clients en un clin d'œil ».

Diachenko a aussi déclaré la semaine dernière que les attaques Meow ont commencé il y a quelques jours, mais qu’elles ne montraient aucun signe de relâchement. Il s'attendait, par ailleurs, à ce que le nombre de bases de données touchées continue d’augmenter. Boris Cipot, ingénieur sécurité senior chez Synopsys, a décrit ces attaques, dans une déclaration, comme un « changement de jeu » qui peut en fait motiver les organisations à suivre les meilleures pratiques de sécurité.

« Nous voyons des organisations qui se précipitent pour identifier et sécuriser les bases de données exposées, ce qui est une mesure nécessaire et attendue depuis longtemps pour de nombreuses entreprises. Il est alarmant qu'en lançant une seule recherche dans Shodan, nous puissions voir combien de dispositifs et de services non sécurisés existent - qui sont tous des vecteurs d'attaque potentiels », a-t-il déclaré.

« Il est possible que l'attaquant n'abuse pas des données de l'utilisateur avant leur suppression. Si c'est le cas, les attaques Meow pourraient en fait protéger les utilisateurs contre des attaquants malveillants à motivation financière. Bien que l'utilisateur soit touché dans les deux cas, au moins, ces données ne sont pas rançonnées ou vendues sur le Web noir, par exemple ».

Certains commentateurs pensent également que « Cela peut faire plus de bien que de mal », a écrit l’un d’entre eux. « Si les données ont disparu, elles ne feront pas partie d'une autre violation de données ! », a ajouté un autre. Et vous, qu’en pensez-vous ?

Sources : Tweet (1 & 2)

Et vous ?

Qu’en pensez-vous ?
Pensez-vous aussi que l’attaque Meow peut faire plus de bien que de mal ?
Pensez-vous que l’attaquant pourrait avoir téléchargé les données avant de les supprimer ?
Selon vous, pourquoi les bases de données contenant des données utilisateur continuent d’être exposées sur Internet ?

Voir aussi :

Sept VPN gratuits ont exposé les données personnelles de 20 millions d'utilisateurs, via un serveur Elasticsearch non sécurisé
Les données personnelles de 7,5 millions d'utilisateurs d'Adobe Creative cloud exposées via une base de données Elasticsearch non sécurisée
90 millions d'enregistrements de données personnelles divulgués sur Internet par la Chine via un serveur ElasticSearch non sécurisé
COVID-19 : l'utilisation des VPN explose suite à une hausse considérable du télétravail, ainsi que de l'utilisation des services de divertissement qui appliquent des restrictions géographiques

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Neckara
Inactif https://www.developpez.com
Le 27/07/2020 à 12:22
A tout les coups, c'est une attaque sous fausse bannière (false flag) du C.C.C.
1  0 
Avatar de
https://www.developpez.com
Le 27/07/2020 à 15:26
Bonjour,

Pensez-vous aussi que l’attaque Meow peut faire plus de bien que de mal ?
Si l'attaque se limite à "supprimer" le contenu de la BDD , on va dire que l'attaque reste limitée et que les inscrits sur la BDD ont bien eu de la chance.

Pensez-vous que l’attaquant pourrait avoir téléchargé les données avant de les supprimer ?
C'est même fort probable. C'est une farce que de penser que les données n'ont pas été volées ...

Selon vous, pourquoi les bases de données contenant des données utilisateur continuent d’être exposées sur Internet ?
> manque de connaissance en sécurité
> manque de connaissance dans le parametrage des outils infos
> m'en foutisme
1  0 
Avatar de dadoonet95
Membre du Club https://www.developpez.com
Le 28/07/2020 à 3:56
Elastic a publié un article de blog (en anglais) expliquant comment il est possible gratuitement de se prémunir de ce type d'attaque.

Un autre article (en français cette fois) que je recommande de lire est "Comment éviter une intrusion sur le serveur Elasticsearch".
1  0 
Avatar de zaza576
Membre actif https://www.developpez.com
Le 28/07/2020 à 13:49
- Tant qu'il ne s'agit pas de tes propres données, osef

- Tant qu'il ne s'agit pas de données confidentielles, personnelles, ... comme tes données bancaires, tes données civiles, tes documents administratifs critiques (fiches de paies, retraite, impôts, ....) ..., données qui pourraient foutre ta vie en l'air si elles venaient à disparaître ... quoi que, pour les prunes / dettes bancaires etc ... ça serait top ;-)

Les banques et les sites gouvernementaux commenceraient-elles à trembler devant un tel remue-ménage ? Ca m'étonnerait, ils sont trop perchés dans leur tour d'ivoire pour comprendre ce qu'il va se produire si cela impacte leurs clients.

Mais bon, un client pigeon reste un client pigeon. Oser faire confiance à des sociétés qui promettent de sécuriser tes données et qui échouent lamentablement à cela, ...

Il habite où ce Elliot Anderson (référence à la série : Mr Robot) que j'aille lui serrer la main ?
0  0 
Avatar de zaza576
Membre actif https://www.developpez.com
Le 28/07/2020 à 13:57
Citation Envoyé par dadoonet95 Voir le message
Elastic a publié un article de blog (en anglais) expliquant comment il est possible gratuitement de se prémunir de ce type d'attaque.

Un autre article (en français cette fois) que je recommande de lire est "Comment éviter une intrusion sur le serveur Elasticsearch".
A la lecture de cet article, on est donc d'accord que le problème vient :
- non pas d'une question d'argent, de personnel qualifié, d'achat de licences de manque de fonctionnalité dans les SGBD / le tooling, ou manque de temps pour corriger la faille
- mais plutôt d'un manque de volonté des entreprises à réduire ces failles de sécurité asap => on ne prend pas assez au sérieux le risque encouru et les conséquences
- d'un manque de compétences dans la configuration et sécurisation des-dites bases de données ElasticSearchs et d'intérêt à protéger ces bases de données

Curieusement, c'est quand la guillotine tombe que les têtes pleuvent !

Je propose 50 coups de fouet à tout dév / RSSI / dirigeant qui laisserait entrevoir des failles aussi béantes que leur Stargate ! Au 49ème coup, on devrait enfin commencer à avoir des résultats sur l'avenir de ces entreprises :-)
0  0