Lien de la room: https://tryhackme.com/room/dreaming

On débute par un scan nmap, mais rien d’intéressant.

On cherche ensuite des répertoires ou fichiers sur le serveur avec gobuster, via la commande gobuster dir -u 10.10.56.225 -w /usr/share/wordlists/dirb/big.txt.

On y trouve un répertoire /app.

On tombe ensuite sur une page qui est celle du CMS

En cliquant sur le lien admin, on a une page de connexion avec juste un mot de passe.

Après une recherche google et sur metasploit, il existe bien un exploit disponible de la version 4.7.13 du CMS pluck, qui permet un upload de fichiers dans Pluck CMS pour permettre un code d’exécution à distance. On peut donc essayer d’y téléverser un fichier qui va permettre une connexion en reverse shell sur notre machine.

J’ai d’abord essayé de manipuler le lien en tentant un LFI, mais on a un message d’erreur. Il semble y avoir un filtre qui bloque les injections LFI.

On essaie de bypasser la page de login trouvé un peu plus haut avec du brute force avec hydra. En examinant le code source de la page de login.php, on a des infos sur les paramètres à utiliser dans la commande avec hydra

On essaie la commande hydra -l admin -P /usr/share/wordlists/rockyou.txt 10.10.56.225 http-post-form "/app/pluck-4.7.13/login.php:cont1=^PASS^&bogus=’’ : Password incorrect"

Cette commande envouie une requête POST vers /app/pluck-4.7.13/login.php, la page du formulaire. cont1 et bogus sont les noms des champs pour le mot de passe et le nom d’utilisateur. Mais celui du nom d’utilisateur n’intervient pas dans la connexion donc on le met à vide.

Après avoir testé les mots de passe un à un, le mot de passe valide est password. On tombe sur page admin.php.

En parcourant un peu le site, on a une section qui nous permet de téléverser un fichier. On va donc créer un reverse shell en PHP.

Une fois le fichier téléversé, il a été modifié en rev_shell.php.txt, ce qui empêche l’exécution directe du code vu que le sevreur le considère juste comme un fichier texte.

On va donc renommer le fichier en ajoutant une des extensions .phtml, .php5, .phar car celles-ci ne sont pas toujours filtrées.

Après avoir renommé puis téléversé, on appuie sur la loupe, ce qui permet d’accéder à http://10.10.2.49/app/pluck-4.7.13/files/rev_shell.phar

On a ensuite le reverse shell sur notre machine.

Lucien Flag

Une fois connecté sur la machine cible, on tentera de lire le flag de lucien.

www-data n’a pas les permssions. On peut juste le lire en étant connecté à lucien, le propriétaire du fichier lui-même.

Pareil pour le flag de death et celui de morpheus.

On essaie un sudo -l pour voir les commandes privilèges que l’utilisateur peut exécuter via sudo.

On obtient une erreur car sudo demande un mot de passe. On doit donc stabiliser le shell pour pouvoir utiliser sudo -l. Pour stabiliser le shell, utiliser les commandes suivantes:

python3 -c 'import pty;pty.spawn("/bin/bash")'
export TERM=xterm
CTRL+Z
stty raw -echo;fg
ENTRÉE
ENTRÉE

Après ca on a un shell interactif, mais on retente sudo -l et on a une demande de mot de passe.

Le user www-data n’est pas dans le fichier sudoers avec les droits nécéssaires, on ne peut donc pas passer par cette technique.

On va essayer la commande find / -type f -perm 4000 2>/dev/null pour trouver les fichiers SUID, qui sont des fichiers ou programmes qui s’exécutent avec les droits de leur propriétaire.

Mais on a rien 😕.

On essaie la commande find / -type f -group lucien 2>/dev/null, qui cherche les fichiers appartenant au groupe lucien. Vu qu’on avait trouvé plus haut que le fichier lucien_flag.txt appartenait au groupe lucien.

On y voit un fichier /opt/test.py qu’on peut lire.

On y voit une URL qui pointe vers localhost, et un mot de passe. Il s’agit peut-etre du mot de passe de lucien. On tente donc su lucien pour se connecter avec le mot de passe trouvé et bingo, on se connecte et on a le flag de l’utilisateur lucien 😁. On peut aussi se connecter avec ssh.

Death Flag

Ici aussi le fichier death_flag.txt ne peut-être lu que par son propriétaire. On essaie sudo -l

La dernière ligne indique que lucien peut exécuter le script getDreams.py, même si celui-ci appartient à l’utilisateur death.

On essaie donc de voir le contenu de getDreams.py, mais on ne peut pas le lire directement dans le répertoire de death. Je fais donc la commande find / -type f -name “getDreams.py“ -readable 2">/dev/null. On peut lire le fichier getDreams.py depuis le répertoire /opt.

En analysant le contenu, il s’agit d’opérations effectuées sur une base de données. La fonction getDreams() se connecte à la base de données library avec le compte death et un mot de passe #redacted . Elle récupère ensuite des données (dreamer et dream)de la table dreams puis les exécute dans une commande shell via subprocess.check_output().

Vu qu’on a des identifiants, je tente une connexion direct à mysql avec la commande mysql -u death -p #redacted -D library. Je tente aussi avec lucien mais rien.

Un peu compliqué ici, on a des mots de passe mais pas de connexion, pourtant il y a bien du sql. En retournant dans le dossier de lucien, il y a deux fichiers, mysql_history et bash_hisotry. En les consultant, on voit les commandes bash entrés par lucien, et donc la commande utilisée pour se connecter à mysql et aussi les commandes utilisées une fois connecté à mysql.

On arrive donc à se connecter

J’ai exécuté la commande trouvée plus haut dans le fichier getDreams.py.

Dans le fichier getDreamer.py, on avait ce bout de code

# Loop through the results and echo the information using subprocess
            for dream_info in dreams_info:
                dreamer, dream = dream_info
                command = f"echo {dreamer} + {dream}"
                shell = subprocess.check_output(command, text=True, shell=True)
                print(shell)

Et avec la sortie de sudo -l , l’utilisateur lucien peut exécuter /home/death/getDreams.py en utilisant python3 en tant que l’utilisateur death, et ce, sans fournir un mot de passe.

On trouve le même indice dans le fichier .bash_history.

On fait donc sudo -u death /usr/bin/python3 /home/death/getDreams.py et on a la commande echo qui s’exécute et la fonction subprocess.check_output().

La base de données peut être donc vulnérable à une injection de commande shell. J’essaie la commande INSERT INTO dreams VALUES('test','$(whoami)');.

Quand on exécute ensuite sudo -u death /usr/bin/python3 /home/death/getDreams.py, on a bien l’identifiant death qui s’affiche dû à l’injection de $(whoami).

On peut essayer de directement lire le flag de death.

On a le flag de death 🙂

On va aussi essayer de trouver le mot de passe de l’utilisateur death. Pour cela on fait une insertion dans la base de données avec INSERT INTO dreams VALUES('test','$(head -n 20 /home/death/getDreams.py)');. Cette commande permet de lire les 20 premières lignes du fichier /home/death/getDreams.py.

On a donc le mot de passe de l’utilisateur death et on peut se connecter via ssh.

Morpheus Flag

Dans le répertoire de morpheus, on retrouve plusieurs fichiers. Celui qui interpelle en premier est le fichier kingdom, mais rien d’intéressant. Par contre dans le fichier restore.py, la fonction copy2() de librairire shutil est utilisée pour copier un fichier vers un dossier de backup /kingdom_backup/kingdom

Mais on ne peut accéder à ce fichier.

On essaie de voir si il y a une faille autour de la librairire, mais rien.

En recherchant la libriaire shutil, on voit qu’elle est stockée dans /usr/lib/python3.8/shutil.py. Le fichier appartient à root mais est aussi modifiable par le groupe death.

On peut donc soit modifier le fichier /usr/lib/python3.8/shutil.py pour du reverse shell ou juste modifier les permissions du fichier morpheus_flag.txt avec l’utilisateur death, car c’est lui qui a les droits d’écriture. On ajoute os.system('chmod 777 /home/morpheus/morpheus_flag.txt') pour le rendre accessible à tous.

On a le flag 😁