Bases de données. EXPOSÉ ! (Redis)

Publié le 09.19.2022

Partie 1 : Redis

A retenir

• Il existe 39 405 services Redis non authentifiés sur un total de 350 675 services Redis sur l'internet public.
• Près de 50 % des services Redis non authentifiés sur Internet présentent des signes de tentative de compromission.

Préface

Dans cette nouvelle série de billets, nous avons décidé de répondre à la question : "Quel est l'état des bases de données sur Internet ?". Nous pouvons répondre à cette question de manière extrêmement détaillée en utilisant notre ensemble de données.

Ce rapport est le premier d'une série. Au cours des prochains mois, nous publierons une analyse détaillée de plusieurs technologies de bases de données différentes, et nous commencerons notre voyage dans "Bases de données. EXPOSÉ !" avec la populaire base de données en mémoire : Redis

Mais avant d'aller plus loin, parlons de ce que signifie pour une base de données d'être "exposée" sur l'internet. Notre scanner tentera de parler la langue maternelle du service que nous essayons d'énumérer. Par exemple, notre scanner construira un paquet que seul un serveur MySQL sait traiter, et en retour, nous recevrons une réponse qui nous donnera plus d'informations sur ce service en cours d'exécution.

Réponse d'un serveur MySQL à la poignée de main.

Censys n'essaiera jamais de s'authentifier auprès des services de base de données qu'il trouve. Nous établissons une poignée de main avec le serveur distant en utilisant le protocole natif et analysons les réponses dans un ensemble de champs, ce qui facilite la recherche.

Au moment où nous écrivons ces lignes, 220 010 967 hôtes disposent d'un ou de plusieurs services Internet exposés. Parmi eux, 5 889 954 hôtes (2,6 % du total) utilisent au moins l'une des douze technologies de base de données dont nous parlerons tout au long de cette série. Le graphique ci-dessous présente les principales bases de données classées en fonction du nombre de services.

(Services de base de données trouvés par Censys)

Notes :

• Lorsque nous parlons d'"hôte" ou d'"hôte unique", nous faisons référence à une seule adresse IP.
• Lorsque nous parlons de "service" ou de "services", nous faisons référence à un ou plusieurs services sur un hôte.

Introduction.

Redis est le quatrième moteur de base de données le plus utilisé dans cette série. Contrairement aux bases de données relationnelles traditionnelles, Redis n'a pas été conçu dans un souci de sécurité, avec l'idée qu'il devrait toujours être réservé aux communications internes et privées (c'est-à-dire qu'il ne devrait pas être directement connecté à l'internet et se trouver derrière un pare-feu). La citation suivante est tirée de la documentation de Redis à ce sujet :

Redis est conçu pour être accessible par des clients de confiance dans des environnements de confiance. Cela signifie qu'il n'est généralement pas judicieux d'exposer l'instance Redis directement à l'internet ou, en général, à un environnement dans lequel des clients non fiables peuvent accéder directement au port TCP ou au socket UNIX de Redis.

Dans les versions les plus récentes (à partir de la version 3.0.0), Redis s'est attaqué au problème croissant des serveurs sans mot de passe exposés à l'internet en fonctionnant dans un "mode protégé" s'il se trouve dans la configuration par défaut. Ce mode protégé ne répondra qu'aux requêtes sur l'interface loopback et bloquera les requêtes provenant d'Internet. Cependant, comme nous le verrons plus loin dans ce billet, le problème persiste.

Les services Redis n'activent pas l'authentification par défaut, et c'est à cause de ce manque de sécurité que Censys peut voir des dizaines de milliers de déploiements Redis non authentifiés sur Internet.

Exposition.

(Carte géographique des hôtes Redis sur Internet)

Au moment de la rédaction de cet article, Censys a observé 350 675 services Redis accessibles par Internet sur 260 534 hôtes uniques. Si la plupart de ces services requièrent une authentification, 11 % (39 405) n'en requièrent pas.

"11% des services Redis sur Internet ne nécessitent pas d'authentification".

Voici les dix premiers pays disposant de serveurs Redis exposés à l'internet, classés en fonction du nombre total de services. La Chine occupe la première place avec 130 839 services Redis accessibles sur l'internet, dont 15 % (20 011 services) ne nécessitent pas d'authentification. Les États-Unis occupent la deuxième place avec 96 904 services Redis au total, dont seulement 5 % (5 108 services) sont ouverts sans authentification.

En examinant les pays disposant de plus de 100 services Redis, nous pouvons visualiser quelles régions du monde ont le pourcentage le plus élevé d'installations Redis mal configurées. Dans le graphique ci-dessous, nous voyons que le pays d'Israël n'a que 187 services Redis, mais que plus de 72 % d'entre eux n'ont pas d'authentification. Israël est l'une des seules régions où le nombre de serveurs Redis mal configurés est supérieur à celui des serveurs correctement configurés.

Par défaut, le service Redis s'exécute sur le port TCP 6379. Cependant, Censys a observé qu'il fonctionnait sur plus de deux mille autres ports, allant du port TCP 6380 avec 10 143 hôtes uniques au port TCP 24491 avec un seul hôte. Vous trouverez ci-dessous les cinq principaux ports sur lesquels nous avons constaté que Redis fonctionnait.

Redis conserve toutes ses données en mémoire, et lorsque notre scanner envoie une commande `INFO` non intrusive au service (qui nous donne une vue d'ensemble de l'état de fonctionnement actuel), nous pouvons voir la quantité de mémoire utilisée et, par conséquent, la quantité de données exposées à l'internet public. Bien que nous ne demandions ni ne voyions jamais le contenu des données d'un service Redis exposé, un utilisateur malveillant pourrait facilement vider toutes les données stockées dans le service.

En agrégeant le champ de recherche Censys "services.redis.used_memory", nous pouvons calculer que sur les 39 405 serveurs Redis non authentifiés que nous avons observés, l'exposition potentielle des données est supérieure à 300 gigaoctets.

Services Redis non authentifiés par AS	Données Redis exposées par AS

TENCENT-NET-AP (AS45090) possède le plus grand nombre de déploiements Redis non authentifiés, avec 13 359 services et environ 48 gigaoctets de données exposées. Mais ALIBABA-CN-NET (AS37963), bien que ne disposant que de 2 377 services Redis non authentifiés, a le plus grand nombre de données exposées à l'internet, avec un peu plus de 60 gigaoctets (62 341 142 583 octets) de données.

Du point de vue d'un attaquant, un petit nombre de services mal configurés avec une exposition de données plus importante est plus intéressant qu'un grand nombre de services mal configurés avec peu ou pas de données exposées.

Il est intéressant de noter que l'hôte le plus exposé aux données exécutait huit serveurs Redis sur huit ports différents, révélant plus de 6 gigaoctets de données au total. Ce qui est intéressant avec cet hôte, c'est que deux des huit services Redis en cours d'exécution requièrent une authentification. Cela signifie que les administrateurs de l'hôte étaient suffisamment conscients et compétents pour activer l'authentification sur certains services Redis, mais qu'ils ont négligé six des huit services. La raison peut être attribuée à une mauvaise configuration, à une erreur de déploiement ou à une règle de pare-feu permissive. Mais quelle que soit la raison sous-jacente, une chose est hautement probable : les propriétaires de l'hôte ne comprennent pas leur surface d'attaque externe.

Et ce n'est pas une circonstance unique ; nous avons découvert que 406 hôtes exécutant plusieurs instances de Redis avaient un mélange de services authentifiés et non authentifiés sur différents ports sur le même hôte. Cela confirme que certaines choses passeront toujours entre les mailles du filet, et qu'il est essentiel de comprendre son empreinte Internet pour assurer la sécurité continue d'une organisation.

En ce qui concerne la quantité de données exposées par pays, le graphique ci-dessus présente les dix premiers pays classés en fonction de la quantité totale de données exposées par des services Redis mal configurés. La Chine domine avec 146 gigaoctets de données exposées, et les États-Unis suivent avec environ 40 gigaoctets.

Versions.

Dans l'introduction de ce billet, nous avons indiqué que les développeurs de Redis ont tenté de résoudre le problème des serveurs sans mot de passe sur Internet en introduisant un "mode protégé", à partir de la version 3.0.0. Lorsque Redis écoute sur toutes les interfaces (0.0.0.0), et qu'un mot de passe n'a pas été configuré, ce mode protégé ne répondra qu'aux requêtes provenant de l'interface loopback (127.0.0.1) et rejettera les requêtes externes. Un administrateur peut désactiver manuellement ce mode en exécutant la commande Redis suivante : config set protected-mode no.

Une petite chose à noter est que l'image Docker officielle de Redis ne semble pas avoir le paramètre protected mode activé par défaut. Voici un exemple de démarrage du service officiel Docker Redis et de récupération de la valeur de la configuration protected-mode. Comme nous pouvons le voir, ce mode protégé est désactivé lorsqu'il est exécuté sous Docker.

Malheureusement, nos conclusions montrent que ce mode protégé n'est pas une solution miracle, car la plupart des services Redis non authentifiés utilisent des versions supérieures à 3.0.0. Par exemple, la Chine compte 3 989 services Redis non authentifiés exécutant la version 6.2.6 et 3 730 services exécutant la version 3.0.504. Le tableau ci-dessous montre les vingt principales versions de Redis que nous avons trouvées sans authentification, réparties par pays, qui utilisent toutes des versions capables de fonctionner en mode protégé.

Vous trouverez ci-dessous un tableau des 10 premières versions de Redis (total pour toutes les régions) trouvées en ligne sans authentification activée. Nous pouvons voir un nombre assez large de versions utilisées dans la nature, mais une majorité de ces serveurs non authentifiés utilisent les versions v6.2.6 (avec 5 791) et v3.0.504 (avec 5 781).

Trouver des Redis abusés

Après avoir passé en revue les problèmes connus pour le serveur Redis sur GitHub, le problème #4791 a attiré notre attention. Cet utilisateur a rapporté que son serveur Redis accessible par Internet avait plusieurs clés qui contenaient une valeur formatée crontab qui tente d'exécuter un script shell récupéré à partir d'un serveur distant qu'il n'a pas défini lui-même. Inquiet de l'existence d'une vulnérabilité inconnue, l'utilisateur a demandé de l'aide aux développeurs. Un deuxième utilisateur est intervenu et a confirmé que son serveur avait été touché par quelque chose de similaire.

Il s'avère que les attaquants utilisent depuis des années une technique moins connue pour inciter les serveurs Redis à écrire des données dans des fichiers arbitraires. Cette technique, connue uniquement sous le nom de "Redis Unauthorized Access Vulnerability" (vulnérabilité d'accès non autorisé à Redis), retourne le système de configuration d'exécution de Redis contre lui-même. Cette attaque est très simple.

Tout d'abord, nous devons comprendre que Redis dispose d'un mécanisme pour stocker les données en mémoire sur le disque afin de survivre à un redémarrage ou à une panne. Les paramètres par défaut de ce mécanisme se trouvent dans la configuration de Redis :

Ce qui peut surprendre, c'est que ces valeurs de configuration peuvent également être définies à distance au moment de l'exécution en utilisant le protocole de messagerie Redis. L'idée générale de cette technique d'exploitation est de configurer Redis pour qu'il écrive sa base de données basée sur des fichiers dans un répertoire contenant une méthode pour autoriser un utilisateur (comme l'ajout d'une clé à ".ssh/authorized_keys"), ou pour démarrer un processus (comme l'ajout d'un script à /etc/cron.d), par exemple,

Ce qui précède indique au service Redis d'écrire le contenu de la mémoire dans le fichier "/root/.ssh/authorized_keys". L'objectif est d'écrire la valeur de la clé "backup1" dans ce fichier, en espérant que le service SSH ignore les données binaires que Redis pourrait ajouter au fichier, et accepte les clients utilisant cette clé SSH.

Remarque: le fichier authorized_keys de SSH permet à un utilisateur d'utiliser sa clé publique SSH à la place de l'authentification locale par mot de passe. Le serveur SSH acceptera une connexion sans vérifier le mot de passe local si vous possédez la partie privée d'une clé publique définie dans $USER/.ssh/authorized_keys.

Il n'y a pas que les deux utilisateurs du problème GitHub susmentionné qui ont été victimes d'une telle attaque. Nous avons trouvé des indicateurs montrant que quelqu'un a tenté cette attaque contre des dizaines de milliers de serveurs Redis non authentifiés sur Internet. Nous ne sommes pas en mesure de dire si les attaques ont réussi, mais nous pouvons signaler les artefacts laissés par ces tentatives.

Nous avons constaté que cette tentative spécifique utilisait plusieurs clés Redis préfixées par la chaîne "backup" pour stocker des entrées crontab malveillantes dans le fichier "/var/spool/cron/root" à l'aide des commandes Redis suivantes :

Cette commande supprime toutes les données du serveur Redis. Ceci est fait pour que le contenu des clés/valeurs suivantes soit écrit aussi près que possible du début du fichier de la base de données.

La clé "backup1" contient une tâche crontab qui récupère et exécute ce script init.sh à partir d'un serveur distant toutes les quatre minutes.

Cela définit le répertoire de données de Redis comme étant le répertoire "/var/spool/cron/" du système ; le répertoire par défaut où les crontabs des utilisateurs individuels sont trouvés et exécutés par le processus "crond".

Cela définit le nom du fichier de données de Redis à "root", ce qui signifie que le contenu de la base de données sera stocké dans "/var/spool/cron/root", c'est-à-dire dans le fichier crontab individuel de l'utilisateur root.

Enfin, cela demande au serveur Redis de synchroniser la mémoire sur le disque, et si cela réussit, le contenu de "/var/spool/cron/root" sera lu et exécuté par le processus crontab.

Ce script "init.sh" (tel qu'il apparaît dans la commande "SET backup1") était toujours accessible et pouvait être téléchargé et visualisé au moment de la rédaction du présent document. Ce script, lorsqu'il est exécuté, comprend de nombreuses actions néfastes, notamment

• Arrêter et désactiver tout processus en cours lié à la sécurité
• 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 relatifs au système et à la sécurité, y compris les historiques de l'interpréteur de commandes (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 d'analyse tels que "masscan"
• Installe et exécute l'application de minage de crypto-monnaies XMRig

Note: Dans le cas où ce script a été supprimé de l'Internet, nous avons créé un gist qui est une copie de l'original que le lecteur peut trouver ici.

En utilisant la liste la plus récente des services Redis non authentifiés fonctionnant sur le port TCP 6379, nous avons effectué un balayage unique qui recherchait simplement l'existence de la clé "backup1" (note : nous n'avons pas récupéré la valeur) sur chaque hôte. Nous avons constaté que sur les 31 239 serveurs Redis non authentifiés de cette liste, 15 526 hôtes disposaient de cette clé. Cela signifie que quelqu'un a tenté l'attaque décrite dans cette section sur plus de 49% des serveurs Redis non authentifiés connus sur Internet.

Cela ne signifie pas pour autant qu'il y a plus de 15 000 hôtes compromis. Il est peu probable que les conditions nécessaires à la réussite de cette vulnérabilité soient réunies sur chacun de ces hôtes. La raison principale de l'échec de ces tentatives est que le service Redis doit être exécuté en tant qu'utilisateur disposant des autorisations nécessaires pour écrire dans le répertoire "/var/spool/cron" (c.-à-d. root). Bien que cela puisse être le cas lorsque Redis est exécuté à l'intérieur d'un conteneur (comme docker), où le processus peut se voir exécuté 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.

Une fois de plus, nous ne pouvons que déterminer si cette attaque a été tentée, et non si elle a réussi.

Que peut-on faire ?

Redis est un produit fantastique. Mais il est également conçu pour être exécuté sur une infrastructure interne, et non sur des serveurs publics. Les administrateurs doivent s'assurer que les entités externes ne peuvent en aucun cas accéder à vos instances Redis. Une bonne première étape consiste à lire la documentation de Redis sur la sécurité de Redis. Mais en résumé :

• Activez l'authentification du client dans votre fichier de configuration Redis.
• Configurer Redis pour qu'il s'exécute uniquement sur les interfaces réseau orientées vers l'intérieur.
• Désactivez la commande "CONFIG" en exécutant "rename-command CONFIG """ pour éviter les abus de configuration.
• Configurez votre pare-feu pour qu'il n'accepte que les connexions Redis provenant d'hôtes de confiance.

Les administrateurs de réseaux et d'hôtes doivent également surveiller en permanence les services que leurs hôtes exposent à l'internet. Le meilleur moyen d'y parvenir est d'utiliser l'outil de recherche gratuit Censys pour voir comment le public perçoit vos hôtes connectés à Internet. Si vous avez un grand réseau ou si vous n'êtes pas sûr de l'inventaire de vos actifs, Censys Attack Surface Management est un produit qui peut automatiquement trouver les hôtes qui vous appartiennent et vous alerter sur tout serveur Redis non authentifié ou mal configuré.