TryHackMe Room Expose

Table of contents

Lien de la room: https://tryhackme.com/room/expose
User Flag
On débute par un scan Nmap. On voit 4 ports ouverts dont la 1337.
En examinant cette page et le code source, rien qui pourrait nous servir.
Je tente alors une commande avec gobuster
pour énumérer des répertoires ou fichiers cachés. On trouve ici deux répertoires: admin
et admin_101
.
La page http://10.10.194.184:1337/admin/
est un formulaire de connexion.
La page http://10.10.194.184:1337/admin_101/
héberge le même formulaire, mais ici la valeur de l’email est défini par défaut à hacker@root.thm
.
J’ai tenté de voir avec Burp. Après avoir envoyé la requête dans le Repeater, on a une requête SQL mais qui n’inclue pas le mot de passe.
On va donc tenter une injection SQL ici. On voit aussi que larequête est envoyée par POST
à includes/user_login.php
.
On teste avec ffuf
avec une liste de payloads d’injection SQL. Mais on a aucun résultat.
Un autre moyen est de le faire avec sqlmap, un outil d’exploitation par injections SQL. On exécute la commande suivante: sqlmap -u "http://10.10.230.197:1337/admin_101/includes/user_login.php" --data="email=hacker@root.thm&password=test" --batch --dbs --dump
. Cette commande va permettre de lister toutes les bases de données disponibles et de récupérer le contenu des bases de données identifiées.
On voit donc trois base de données, dont une du nom de expose
qui contient 2 tables: config
et user
.
On a maintenant le nom d’utilisateur hacker@root.thm
et son mot de passe. On arrive ensuite à se connecter, mais la page n’est pas tant utile et on a rien dans le code source.
En visitant /file1010111/index.php
, trouvé dans la table config, on tombe sur un formulaire qui demande un mot de passe.
Le mot de passe fourni dans la table est peut-être codé. En allant sur dcode, on l’obtient en clair.
On tombe à nouveau sur une autre page.
Dans le code source , on a une sorte d’indice qui nous dit d’essayer avec des paramètres.
On va donc manipuler l’URL. J’ai essayé http://10.10.230.197:1337/file1010111/index.php?file=test
ou encore http://10.10.230.197:1337/file1010111/index.php?file=1
, mais rien.
Dans la deuxième entrée de la table config, il y avait une autre URL qui indiquait ONLY ACCESSIBLE THROUGH USERNAME STARTING WITH Z. Il faut donc voir pour des username, faisant allusion à /etc/passwd
. J’ai donc tenté http://10.10.230.197:1337/file1010111/index.php?file=../../../../../etc/passwd
.
On a bel et bien un nom d’utilisateur débutant par z.
On tombe sur une page qui permet d’upload un fichie, via le répertoire /upload-cv00101011
.
En regardant le code source, on voit que le site accepte juste un fichier jpg
ou png
.
On y upload une photo.
On regarde à nouveau le code source, on voit que les fichiers sont téléversés dans le répertoire /upload_thm_1001
.
Les photos sont sous le répertoire /upload_thm_1001
.
Ce qu’on va donc faire cest téléverser un fichier qui sera notre reverse shell. Vu que le serveur utilise php, on utilisera un reverse shell en php. On peut créer un revshell sur Online - Reverse Shell Generator.
J’ai créé un fichier rev_shell.php
mais que jai renommé rev_shell.png
, pour que l’upload réussisse.
Il faut donc renommer le fichier une fois dans Burp en rev_shell.php
puis forward la requête
On retourne dans le répertoire /upload_thm_1001
et on voit que le fichier rev_shell.png
que j’ai renommé dans la requête en rev_shell.php
a bien été téléversé comme le montre la photo ci-dessous.
Il suffit donc de cliquer sur la photo, et on a le shell.
On est connecté en tant que www-data. Mais une fois connecté, je ne peux pas lire le flag de l’utilisateur. Mais le fichier ssh_creds.txt contient ses identifiants avec lesquels on peut juste se connecter.
J’ai donc changé d’utilisateur, avec la commande su zeamkish
pour passer de www-data
à zeamkish
, entré son mot de passe, et j’ai accès à flag.txt
.
Root Flag
La commande sudo -l
ne nous sort rien. Donc zeamkish n’a aucun privilège root.
On essaie aussi de voir un fichier potentiel de flag contenant le terme root, mais rien.
Finalement, on regarde les fichiers SUID, qui sont des fichiers ou programmes qui s’exécutent avec les droits de leur propriétaire, souvent root. Avec la commande find / -type f -perm -u=s 2>/dev/null
ou find / -type f -perm 4000 2>/dev/null
.
On a une liste de binaires SUID avec le bit s, et qui appartiennetnt à root. Il est possible ici d’utiliser plus d’un.
/usr/bin/nano
Le binaire /usr/bin/nano
permet de modifier des fichiers avec des privilèges root. On peut donc modifier le fichier /etc/shadow
qui contient les mots de passes des utilisateurs. Pour cela, on génère d’abord le hash du mot de passe avec openssl
.
On copie ensuite ce hash, au niveau de root, juste après root:
avec la commande /usr/bin/nano /etc/shadow
On passe maintenant à root, et on a le flag.
/usr/bin/find
On peut aussi utiliser le binaire find pour directement trouver le flag de root. On peut utiliser la commande /usr/bin/find . -exec /bin/sh -p \; -quit
. Cette commande utilise le binaire find pour exécuter un shell avec les privilèges SUID.
/usr/bin/find
est le chemin du binaire trouvé un peu plus haut.-exec /bin/sh -p \;
exec est une option de find qui permet d’exécuter des commandes. L’option-p
permet de conserver les userid effectif (celui de root), ce qui me donne un shell en étant root. On peut le voir dans la capture ci dessous. Sans l’option -p, le shell détecte une différence entre l’UID réel et l’UID effectif et redescend à l’UID réel (celui de l’utilisateur zeamkish).
On peut ensuite lire le flag.txt dans le fichier flag.txt
de /root
.
Subscribe to my newsletter
Read articles from FIKARA BILAL directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
FIKARA BILAL
FIKARA BILAL
As a newcomer to the cybersecurity industry, I'm on an exciting journey of continuous learning and exploration. Join me as I navigate, sharing insights and lessons learned along the way