TryHackMe Room Expose

FIKARA BILALFIKARA BILAL
5 min read

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.

0
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