Un attaquant inconnu a ciblé des dizaines de milliers de serveurs Redis non authentifiés exposés sur Internet dans le but d’installer un mineur de crypto-monnaie.
On ne sait pas immédiatement si tous ces hôtes ont été compromis avec succès. Néanmoins, cela a été rendu possible grâce à une « technique moins connue » conçue pour inciter les serveurs à écrire des données dans des fichiers arbitraires – un cas de l’accès non autorisé qui a été documenté pour la première fois en septembre 2018.
« 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 vers ‘/etc/cron.d’) », Censys a dit dans une nouvelle rédaction.
La plate-forme de gestion de la surface d’attaque a déclaré avoir découvert des preuves (c’est-à-dire des commandes Redis) indiquant les efforts d’une partie de l’attaquant pour stocker des éléments malveillants. entrées crontab dans le fichier « /var/spool/cron/root », entraînant l’exécution d’un script shell hébergé sur un serveur distant.
Le script shell, qui est toujours accessible, est conçu pour effectuer les actions suivantes :
- Mettre fin aux processus liés à la sécurité et à la surveillance du système
- Purger les fichiers journaux et les historiques de commandes
- Ajoutez une nouvelle clé SSH (« backup1 ») à l’utilisateur root fichierauthorized_keys pour activer l’accès à distance
- Désactiver iptables pare-feu
- Installez des outils de numérisation comme masscan, et
- Installez et exécutez l’application d’extraction de crypto-monnaie XMRig
La clé SSH aurait été définie sur 15 526 des 31 239 serveurs Redis non authentifiés, ce qui suggère que l’attaque a été tentée sur « plus de 49 % des serveurs Redis non authentifiés connus sur Internet ».
Cependant, l’une des principales raisons pour lesquelles cette attaque pourrait échouer est que le service Redis doit être exécuté avec des autorisations élevées (c’est-à-dire root) afin de permettre à l’adversaire d’écrire dans le répertoire cron susmentionné.
« 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 », ont déclaré les chercheurs de Censys. « Mais dans ce cas, seul le conteneur est affecté, pas l’hôte physique. »
Le rapport de Censys a également révélé qu’il existe environ 350 675 services de base de données Redis accessibles sur Internet couvrant 260 534 hôtes uniques.
« Alors que la plupart de ces services nécessitent une authentification, 11% (39 405) ne le font pas », a déclaré la société, ajoutant que « sur le total de 39 405 serveurs Redis non authentifiés que nous avons observés, l’exposition potentielle des données est supérieure à 300 gigaoctets ».
Les 10 principaux pays avec des services Redis exposés et non authentifiés sont la Chine (20 011), les États-Unis (5 108), l’Allemagne (1 724), Singapour (1 236), l’Inde (876), la France (807), le Japon (711), Hong Kong ( 512), les Pays-Bas (433) et l’Irlande (390).
La Chine est également en tête en ce qui concerne la quantité de données exposées par pays, représentant 146 gigaoctets de données, les États-Unis venant loin derrière avec environ 40 gigaoctets.
Censys a déclaré avoir également trouvé de nombreuses instances de services Redis mal configurés, notant qu' »Israël est l’une des seules régions où le nombre de serveurs Redis mal configurés dépasse celui des serveurs correctement configurés ».
À atténuer les menacesil est conseillé aux utilisateurs d’activer l’authentification client, de configurer Redis pour qu’il ne s’exécute que sur des interfaces réseau internes, d’empêcher l’utilisation abusive de la commande CONFIG en la renommant en quelque chose d’indéniable et de configurer les pare-feu pour accepter les connexions Redis uniquement à partir d’hôtes de confiance.