Dans cette preuve de concept, nous utiliserons msfvenom pour générer la bibliothèque .so qui contiendra notre charge utile (dans notre cas, un reverse shell). Nous copierons ensuite ce fichier sur la machine vulnérable et spécifierons ce chemin dans la variable wsrep_provider, ce qui exécutera notre charge utile et nous donnera accès à la machine cible en tant qu'utilisateur disposant des privilèges super (ici l'utilisateur mysql) grâce à notre reverse shell.

Construction et lancement de l'image de la machine vulnérable

Pour cette expérience, vous aurez besoin que les paquets docker, msfvenom, openssh-client et mariadb soient installés sur votre machine.

Dans cette configuration, la machine cible est basée sur une image MariaDB 10.4.12 (qui est vulnérable à cette faille), sur laquelle tourne un serveur openssh sans connexion root autorisée. Nous avons donc créé pour vous un utilisateur non-root, myuser, dont le mot de passe est mypassword.

Construction de l'image vulnérable :

Lancement de la machine cible :

Exploitation

Créer la charge utile : un reverse shell

La charge utile est le binaire que nous voulons que la machine cible exécute une fois l'exploitation terminée. Ici, nous utilisons msfvenom pour créer la charge utile reverse shell sous la forme d'une bibliothèque .so, avec notre adresse IP (LHOST) et notre port (LPORT) comme paramètres. Dans un autre shell, exécutez :

L'adresse IP LHOST est celle définie dans docker-compose.yaml pour la passerelle du réseau, dans notre cas l'attaquant, c'est-à-dire vous.

Écouter le reverse shell

En arrière-plan, sur un troisième terminal, nous allons écouter toute connexion entrante de la machine cible sur le port auquel elle est censée se connecter.

Le port sur lequel nous écoutons, 4444, est celui que nous avons défini comme LPORT lors de la création de la charge utile.

Envoyer la charge utile à la machine vulnérable

Maintenant, nous devons copier la charge utile créée précédemment (payload-CVE-2021-27928.so) vers la machine cible via ssh en utilisant la commande scp, en tant qu'utilisateur système non-root myuser, dont le mot de passe est mypassword :

Comme nous ne pouvons pas copier directement un fichier via ssh vers /usr/lib, nous devons nous connecter à la machine et le déplacer manuellement au bon endroit (rappelez-vous que le mot de passe de myuser est mypassword) :

Nous aurions pu envoyer la charge utile dans un autre répertoire sous un autre nom, comme /tmp/exploit.so, et passer ce chemin comme chemin de la charge utile, mais la faille ayant depuis été corrigée sur tous les paquets mariadb, son exploitation a nécessité quelques ajustements que vous verrez à la fin de cette démonstration.

Exécuter la charge utile sur la cible en exploitant la faille

La dernière étape consiste à exploiter la faille MariaDB en envoyant une requête en tant qu'utilisateur système non-root mais administrateur de base de données compétent que nous sommes, avec pour requête de définir la variable globale wsrep_provider au chemin de notre charge utile.

Ici, root signifie « administrateur » au niveau de la base de données, et non l'utilisateur « root système ». Le mot de passe est donc celui du fichier docker-compose.yaml, MYSQL_ROOT_PASSWORD: myrootpwd.

Enfin, si tout s'est passé comme prévu, nous pouvons voir dans le terminal où nous écoutions les connexions entrantes que la machine cible s'est bien reconnectée à nous et que nous pouvons exécuter des commandes shell. Profitez-en :)

Le reverse shell n'est pas aussi agréable qu'un shell « classique » : vous n'avez ni autocomplétion, ni invite de commande, ni historique, c'est donc à vous de surveiller la bonne exécution de vos commandes. Ainsi, à titre d'exemple, n'hésitez pas à utiliser ls -la.

Vous pouvez exécuter whoami dans le shell netcat pour vérifier que vous êtes bien l'utilisateur système mysql !

Correctif

Selon le Jira de MariaDB, il semble qu'il n'y ait que peu (ou pas) de cas d'usage pratique pour que ces variables soient modifiées à l'exécution ; elles ne sont utilisées que dans les tests. Après la découverte de cette faille, le correctif a donc consisté à les rendre en lecture seule, ce qui a été un correctif simple et sûr, au prix de scripts de test légèrement plus complexes.

Ce n'était pas le cas auparavant, mais désormais, la seule valeur de chemin que wsrep_provider peut prendre est /usr/lib/galera/libgalera_smm.so. C'est pourquoi cette preuve de concept a nécessité quelques ajustements, comme donner des droits d'écriture sur le dossier /usr/lib/galera afin de pouvoir y déposer notre charge utile. Cette configuration est donc volontairement faillible dans le cadre de cette démonstration, mais elle n'est plus utilisable de cette façon sur la plupart des systèmes actuels.

Références

• CVE
• Problème du serveur MariaDB sur Jira
• Exemple d'exploit

Ce travail a été réalisé dans le cadre du cours de Sécurité des systèmes d'information dispensé en dernière année de la spécialisation Ingénierie des systèmes d'information à Grenoble INP - Ensimag, UGA.