Plus de 39 000 services Redis non authentifiés sur Internet ciblés par une campagne de crypto-monnaieSecurity Affairs
Les acteurs de la menace ont ciblé des dizaines de milliers de serveurs Redis non authentifiés exposés sur Internet dans le cadre d’une campagne de crypto-monnaie.
Redis est un outil de structure de données open source populaire qui peut être utilisé comme base de données distribuée en mémoire, courtier de messages ou cache. L’outil n’est pas conçu pour être exposé sur Internet, cependant, les chercheurs ont repéré des dizaines de milliers d’instances Redis accessibles au public sans authentification.
Le chercheur Victor Zhu a détaillé une vulnérabilité d’accès non autorisé Redis qui pourrait être exploitée pour compromettre les instances Redis exposées en ligne.
« Sous certaines conditions, si Redis s’exécute avec le compte root (ou même pas), les attaquants peuvent écrire un fichier de clé publique SSH sur le compte root, se connectant directement au serveur victime via SSH. Cela peut permettre aux pirates d’obtenir des privilèges de serveur, de supprimer ou de voler des données, ou même de conduire à une extorsion de cryptage, mettant gravement en danger les services commerciaux normaux. lit le billet publié par Zhu le 11 septembre 2022.
Maintenant, les chercheurs de Censys mettent en garde contre des dizaines de milliers de serveurs Redis non authentifiés exposés sur Internet qui sont attaqués.
Les pirates ciblent ces instances pour installer un mineur de crypto-monnaie.
« Il y a 39 405 services Redis non authentifiés sur 350 675 services Redis au total sur l’Internet public. » avertit Censys. « Près de 50 % des services Redis non authentifiés sur Internet montrent des signes d’un tenté faire des compromis. »
« L’idée générale derrière cette technique d’exploitation est de configurer Redis pour écrire sa base de données basée sur des fichiers dans un répertoire contenant une méthode pour autoriser un utilisateur (comme ajouter une clé à ‘.ssh/authorized_keys’), ou démarrer un processus (comme ajouter un script pour ‘/etc/cron.d’) », ajoute Censys.
Les experts ont trouvé des preuves qui démontrent la campagne de piratage en cours, les acteurs de la menace ont tenté de stocker des entrées crontab malveillantes dans le fichier « /var/spool/cron/root » en utilisant plusieurs clés Redis précédées de la chaîne « backup ». Les entrées crontab ont permis aux attaquants d’exécuter un script shell hébergé sur un serveur distant.
Le script shell a été conçu pour effectuer les actions malveillantes suivantes :
- Arrête et désactive tout processus lié à la sécurité en cours d’exécution
- Arrête et désactive tous les processus de surveillance du système en cours d’exécution
- Supprime et purge tous les fichiers journaux liés au système et à la sécurité, y compris les historiques du shell (par exemple, .bash_history).
- Ajoute une nouvelle clé SSH au fichier authorized_keys de l’utilisateur root
- Désactive le pare-feu iptables
- Installe plusieurs outils de piratage et de numérisation tels que « masscan »
- Installe et exécute l’application d’extraction de crypto-monnaie XMRig
Les chercheurs ont utilisé une liste récente de services Redis non authentifiés s’exécutant sur le port TCP 6379 pour exécuter une analyse unique qui recherchait l’existence de la clé « backup1 » sur chaque hôte. Censys a découvert que sur les 31 239 serveurs Redis non authentifiés de cette liste, 15 526 hôtes avaient cet ensemble de clés. Ces instances ont été ciblées par des acteurs de la menace avec la technique décrite ci-dessus.
La plupart des serveurs Redis exposés à Internet sont situés en Chine (15,29 %), suivi de l’Allemagne (14,11 %) et de Singapour (12,43 %).
«Pourtant, cela ne signifie pas qu’il y a plus de 15 000 hôtes compromis. Il est peu probable que les conditions nécessaires au succès de cette vulnérabilité soient réunies pour chacun de ces hôtes. La principale raison pour laquelle bon nombre de ces tentatives échoueront est que le service Redis doit être exécuté en tant qu’utilisateur disposant des autorisations appropriées pour écrire dans le répertoire « /var/spool/cron » (c’est-à-dire root) ». conclut le rapport. « Bien que cela puisse être le cas lors de l’exécution de Redis dans un conteneur (comme docker), où le processus peut se voir s’exécuter en tant que root et permettre à l’attaquant d’écrire ces fichiers. Mais dans ce cas, seul le conteneur est affecté, pas l’hôte physique.
Le rapport comprend également une liste d’atténuation de ces attaques.
Suis moi sur Twitter: @affairesdesecurite et Facebook
Pierluigi Paganini
(Affaires de sécurité – piratage, minage)
Partager sur