Bases de données non sécurisées attaquées 18 fois par jour par des pirates
Si vous laissez une base de données non sécurisée sur le Web, combien de temps faut-il aux pirates pour la trouver et la voler ?
L’équipe de recherche en sécurité de Comparitech découvre régulièrement des serveurs non sécurisés ou mal configurés qui divulguent des données utilisateur sensibles sur le Web. Dans un scénario typique, des tiers non autorisés peuvent trouver, accéder et même modifier les données que les organisations ont laissées exposées sans mot de passe ni autre authentification, mettant ainsi en danger la confidentialité et la sécurité des utilisateurs.
Bien que nous fassions de notre mieux pour alerter rapidement les responsables des expositions que nous trouvons, les données restent souvent exposées et vulnérables pendant quelques heures jusqu'à quelques semaines pendant que nous traquons le propriétaire et attendons une réponse.
Le temps presse dans ces situations. Nous voulions savoir à quelle vitesse les données peuvent être compromises si elles ne sont pas sécurisées.
Donc, nous avons installé un pot de miel .
Notre équipe de recherche, dirigée par l'expert en cybersécurité Bob Diachenko, a créé une simulation d'une base de données sur une instance Elasticsearch (un type de serveur cloud dans lequel les données sont souvent stockées) et y a inséré de fausses données utilisateur. Ensuite, nous l'avons laissé exposé publiquement pour voir qui s'y connecterait et comment ils tenteraient de voler, d'extraire ou de détruire les données.
Voici ce que nous avons trouvé :
175 attaques commençant seulement 8 heures après le déploiement
Nous avons laissé les données exposées du 11 mai 2020 au 22 mai 2020. Pendant cette période, 175 demandes non autorisées ont été effectuées. Nous appelons généralement ces demandes des « attaques ». Notre pot de miel effectuait en moyenne 18 attaques par jour.
La première attaque a eu lieu le 12 mai, 8 heures et 35 minutes seulement après le déploiement.
Pour trouver des bases de données vulnérables, de nombreux attaquants utilisent un moteur de recherche Internet des objets (IoT) comme Shodan.io ou BinaryEdge. Shodan a indexé notre pot de miel le 16 mai, ce qui signifie qu'il a ensuite été répertorié dans les résultats de recherche.
Moins d’une minute après avoir été indexé par Shodan, deux attaques ont eu lieu. Le plus grand nombre d’attaques en une seule journée s’est produit le jour même de l’indexation de la base de données : 22 attaques au total.
Cela ne vaut rien que plus de trois douzaines d’attaques se soient produites avant même que la base de données ne soit indexée par les moteurs de recherche, démontrant combien d’attaquants s’appuient sur leurs propres outils d’analyse proactifs plutôt que d’attendre que des moteurs de recherche IoT passifs comme Shodan explorent les bases de données vulnérables.
BinaryEdge a indexé la base de données le 21 mai.
Les robots des moteurs de recherche indexant la base de données ont été exclus des résultats. Certains des attaquants pourraient vraisemblablement être des chercheurs en sécurité similaires à notre propre équipe, mais nous ne pouvons souvent pas faire la distinction entre un attaquant malveillant et un attaquant inoffensif.
Le robot Ransomware a détruit les données
Le 29 mai 2020, un robot malveillant a découvert le pot de miel. Il a lancé une attaque qui a supprimé le contenu de la base de données et laissé un message avec les coordonnées et une demande de paiement (expurgé par Comparitech) :
« Si vous souhaitez récupérer vos données, envoyez 0,06 BTC à [expurgé] et vous devez envoyer un e-mail à [expurgé] avec votre IP. Si vous avez besoin d'une preuve de vos données, envoyez simplement un e-mail. Si vous n’effectuez pas de paiement, toutes vos données peuvent être utilisées à nos fins et/ou seront divulguées/vendues »
Comme nos recherches étaient déjà terminées au moment de l'attaque, les chercheurs ont déjà supprimé la plupart des données de la base de données et seul un index de facturation Amazon Web Services existait encore. Cependant, le serveur honeypot était toujours ouvert et vulnérable.
L'attaque a commencé en regardant la liste des index avec la commande |_+_|. Une fois la liste des index reçue, l'attaquant a examiné le contenu de l'index par défaut avec la commande |_+_|. L’attaquant a ensuite créé un index dans lequel il a laissé le document contenant la demande de rançon.
Toutes les demandes ont eu lieu entre 9 h 10 min 27 s et 9 h 10 min 32 s EEST, ce qui signifie que l’attaque a duré cinq secondes. L'attaquant a utilisé les méthodes GET pour obtenir des informations d'index, DELETE pour supprimer et POST pour laisser des messages de requête.
L’adresse IP de l’attaquant est enregistrée aux Pays-Bas, tout comme son fuseau horaire.
Les attaques ont pour origine les États-Unis, la Roumanie et la Chine
Les emplacements ont été déterminés à l’aide des adresses IP des attaquants. Le plus grand nombre d’attaques provenait de trois pays :
- 89 venaient des USA
- 38 venaient de Roumanie
- 15 venaient de Chine
Les adresses IP peuvent être modifiées à l’aide d’un proxy pour masquer la véritable localisation de l’attaquant, alors prenez ces résultats avec des pincettes.
Quelles méthodes d’attaque ont été utilisées ?
La majorité des demandes visaient à obtenir des informations sur l'état de la base de données et ses paramètres.
- 147 attaques ont utilisé la méthode de requête GET
- 24 attaques ont utilisé la méthode POST, particulièrement populaire pour les attaques provenant de Chine
- 1 attaque a utilisé la méthode PUT dans le but de modifier la configuration du serveur
- 1 attaque a utilisé la méthode OPTIONS pour obtenir des informations sur la connexion
- 1 attaque a utilisé la méthode HEAD pour récupérer les en-têtes des requêtes sans recevoir les réponses
Autres types d'attaques
Les attaquants ne cherchaient pas seulement à voler des données. Certains voulaient détourner des serveurs pour exploiter des cryptomonnaies, voler des mots de passe et détruire des données.
Cryptojacking
L'une des attaques les plus courantes visait un exploit d'exécution de code à distance sur les serveurs Elasticsearch ( CVE-2015-1427 ). On a essayé d’installer un script de cryptomining. Le but de l'attaque est d'accéder à l'environnement Elasticsearch au moyen de fonctions Java et de télécharger le script bash mineur à l'aide d'unwgetcommande.
Les attaques provenaient de différentes adresses IP, mais la source de téléchargement du script était toujours la même. L'attaque a été réalisée à l'aide de deux requêtes : une avec le code source et une qui avait été masquée.
Vol d'identifiants
Une autre attaque courante ciblait les mots de passe contenus dans les identifiants du serveur./etc/mot de passedéposer. L'attaque exploite la même vulnérabilité que l'attaque du cryptominer, plus une autre vulnérabilité de traversée de chemin (CVE-2015-5531).
L'attaquant a utilisé une attaque par traversée de chemin en utilisant deux méthodes de requête, GET et POST. Le premier contenait le chemin dans l’adresse de la requête et le second utilisait des fonctions Java pour récupérer des fichiers.
Modifications de configuration
Un attaquant a tenté de modifier la configuration du serveur de manière à lui permettre de supprimer toutes les données qui y sont stockées. L'attaquant a tenté de désactiver le pare-feu du serveur en désactivant iptables.
