Time to enter the warren…
On part sur une room à 2 niveaux :
- Récupération du flag utilisateur
- Récupération du flag root
1- Reconnaissance
On ne change pas une équipe qui gagne, je lance un scan Nmap pour voir un peu à qui on a affaire :
Explications sur la commande :
- -sS : On souhaite faire un TCP SYN (Stealth) scan (ou half open scan car on ne réalise pas l’intégralité du 3-way handshake TCP).
- -A : Aggressive scan options = active la détection d’OS (-O) , le scan de version (-sV), utilisation des scripts par défaut (-sC) et réalise un traceroute de la cible (–traceroute).
- -Pn : Considérer tous les hôtes comme étant connectés (saute l’étape de découverte des hôtes).
- -p- : Scan l’intégralité des ports possibles.
- -T4* : Choisit la « politique de temporisation » 4 (la plus rapide étant la 5, par défaut nmap utilise la valeur 3).
- -oA : Sortie dans les trois formats majeurs en même temps (normal, XML et grepable).
* Concernant la « politique de temporisation », je choisis volontairement une valeur élevée pour scanner plus rapidement, mais attention à 2 choses :
- Si votre connexion est mauvaise, il risque d’y avoir des retransmissions voire des échecs de communication, donc au final temps rallongé et résultat de scan bancal.
- En condition réelle de pentest plus le scan est « rapide » plus il va avoir de chance d’être vu avec des solutions IDS/IPS (Intrusion Detection/Prevention System) et des pics vont être immédiatement visibles sur un éventuel SIEM (Security Information and Event Management) donc privilégier un scan plus « lent ».
On observe que les ports suivants sont ouverts sur la machine cible :
- 21 : vsftpd 3.0.2 (serveur FTP)
- 22 : OpenSSH 6.7p1 (serveur SSH)
- 80 : Apache httpd 2.4.10 (serveur web)
2- Mapping
Je commence par visiter la page web hébergée par le serveur sur le port 80 :
Circulez, rien à voir !
Il s’agit de la page par défaut Apache2, une analyse du code source n’a rien donné (pas de commentaires trop verbeux ni de liens « cachés »).
Je ne lâche pas l’affaire pour autant, je poursuis mon énumération avec ffuf :
Petite astuce à connaître, ffuf permet de filter selon différents critères afin de ne pas être « polluer » de réponses inutiles (comme des réponse avec une taille à 0).
Dans notre cas, j’ai aborté l’énumération pour ne plus avoir les résultats inconsistants, et pour filtrer je me suis basé sur la taille (on remarque que tous les résultats inutiles ont une taille commune à 7853 octets).
Votre regard alerte verra l’ajout du paramètre -fs 7853, permettant comme indiqué plus haut … de filtrer les réponses ayant une taille de 7853 octets !
On obtient un répertoire au nom aguicheur : assets, je vais voir ça de plus près sans attendre !
Pour ceux qui se posent la question, oui, il s’agit bien du clip de Rick Astley (Never Gonna Give You Up), et oui j’ai regardé la vidéo, et non ce n’était pas une perte de temps ^^.
En effet, au beau milieu de la vidéo, la musique s’estompe pour laisser la place à une voix robotique délivrant un message nous indiquant qu’on cherche au mauvais endroit. Le message est agrémenté d’un joli rot (ou Burp ! en anglais).
J’ai donc tenté ma chance du côté du fichier css :
J’aperçois un message parlant d’une page cachée : sup3r_s3cr3t_fl4g.php, on y va 🤪 ?
Après avoir renseigné l’adresse de la page, je suis redirigé vers le dossier /sup3r_s3cret_fl4g/ et je suis attendu au tournant par une « alerte » javascript m’invitant à désactiver ledit javascript (je ne l’ai pas fait la première fois et j’ai été redirigé vers la vidéo de Rick Astley hébergée par un service très connu … rabbit hole !?).
Je retente ma chance, mais au préalable je désactive le javascript sur mon navigateur (Firefox dans mon cas) et pour cela je tape dans l’url about:config :
Le navigateur me demande si j’accepte les risque (Ah ! Ah ! Ah ! je me ris du danger !), et après validation je tombe sur la page demandée, et je saisi javascript.enabled :
Le navigateur ne m’affiche plus que le champ désiré, je double-clic pour passer de « true » à « false » le champ (et par la même occasion désactiver Javascript, oui c’est pour ça qu’on fait tout ça, j’avais presque oublié !).
Je retente ma chance, cette fois-ci Javascript est désactivé, et on n’est plus redirigé vers l’hébergeur de vidéos, mais on reste sur une page locale qui embarque … la vidéo de Rick Astley (oui encore lui …).
Je commence alors à regarder en détail les différents chargements dans l’onglet « Network » du panel développeur de Firefox et je vois une page dont l’URL me fait tiquer :
Dans un appel, on voit un fichier intermediary.php qui est appelé avec un paramètre passé via l’URL : hidden_directory=WExYY2Cv-qU.
Je n’ai pas tout de suite compris et j’ai tenté de « décoder » cette valeur avant de comprendre que c’était réellement le nom d’un dossier caché !
Nouveau répertoire découvert et nouveau fichier, j’ai nommé Hot_Babe.png.
J’avoue qu’avant de l’ouvrir j’ai quand même vérifié qu’il n’y avait personne derrière moi, ne sait-on jamais !
A première vue, rien d’anormal, mais d’expérience, je sais que les apparences sont souvent trompeuses, et également que les images peuvent cacher bien des choses.
Je vérifie en premier lieu les données EXIF de l’image en passant par le site exif.tools :
J’aperçois un warning m’avertissant qu’il y a des données présentes après les données utiles de l’image (quelqu’un aurait-il caché quelque chose à l’intérieur ?).
Je tente un strings sur le fichier pour voir si je trouve des anormalités (surtout en fin de fichier).
Bonne trouvaille !
J’extrais la liste des mots de passe du fichier et je me crée une wordlist sur mesure avec qui me servira avec le nom d’utilisateur fourni ftpuser.
3- Exploitation
Avec les informations récoltées lors de l’énumération web, je me lance sur le serveur FTP à l’aide d’Hydra :
On a un mot de passe !
5iez1wGXKfPKQ
Next move : je me connecte au service FTP avec mes tout nouveaux creds :
Connexion avec succès, et en prime on récupère un fichier au nom peu énigmatique !
Alors là … c’est joli mais ça ne me parle pas du tout.
J’ai demandé un coup de main à ChaCha et il m’a sorti une réponse fort utile :
Et un nouveau couple user/password dans la poche :
Utilisateur : eli
Mot de passe : DSpDiM1wAEwid
Je me connecte ensuite en SSH :
A la connexion, un message de la part de l’utilisateur root à destination d’une certaine Gwendoline apparaît indiquant qu’il (ou elle d’ailleurs, est-ce que root ne serait pas une femme ?) a laissé un message caché en indiquant une « leet s3cr3t hiding place » laissant penser à un dossier/fichier caché (nom commençant par un ‘.’) et nommé en « leetspeak ».
Après avoir perdu du temps à chercher des fichiers/dossiers cachés dans les repertoires utilisateurs, je me suis lancé dans une recherche des fichiers modifiés par l’utilisateur root :
Le fichier caché .th1s_m3ss4ag3_15_f0r_gw3nd0l1n3_0nly! me semble arrivé à point nommé.
Le message laissé par root contient le mot de passe de l’utilisatrice gwendoline :
MniVCQVhQHUNI
Here we go again … on lance une nouvelle connexion SSH sur la session de gwendoline.
On peut maintenant récupérer le flag utilisateur situé dans le répertoire /home/gwendoline :
Le flag utilisateur est à moi :
THM{1107174691af9ff3681d2b5bdb5740b1589bae53}
4- Elévation de privilèges
Pour la suite des évènements, il s’agit d’obtenir le flag root, et pour cela il nous faut monter en grade.
Je commence par vérifier si l’utilisatrice gwendoline peut (ou pas) exécuter certaines commandes en tant que root :
Bonne nouvelle, on peut exécuter l’éditeur vi, à la place de n’importe quel utilisateur sans demande de mot de passe … sauf root !
Cela me rappelle un contournement de ce genre de garde fou : la CVE-2019-14287 qui permet de contourner une configuration où un utilisateur peut exécuter une commande en tant que n’importe quel utilisateur sauf root (comme dans notre cas).
Cette vulnérabilité affecte la commande sudo en version < 1.8.28, je vérifie la version dans notre cas :
La version semble vulnérable, je tente ma chance.
L’éditeur vi s’ouvre et le contenu du fichier user.txt est affiché.
Vi est connu pour pouvoir exécuter des commandes directement depuis son interface d’édition, et je vais m’en servir pour lancer un shell … en tant que root !
Maintenant que je suis devenu le fameux utilisateur racine, je ne vais pas me gêner pour récupérer le flag associé :
Voici le flag root bien mérité :
THM{8d6f163a87a1c80de27a4fd61aef0f3a0ecf9161}
Chaîne d’attaque
Retour d’expérience
J’ai trouvé cette room très complète, aliant l’énumération en plusieurs étapes, la stéganographie de la force brute et un déplacement latéral nécessaire avant élévation de privilèges.
Point positif également sur l’utilisation de vulnérabilités CVE réelles
Plutôt d’accord sur le niveau du challenge positionné à easy, mais pas ennuyeux pour autant.
Conclusion
Une room que je qualifierais d’intéressante, permet de renforcer les enseignements de GTFOBins et du renforcement des privilèges sudo.
Elle m’a également permis de mettre en place une méthodologie plus rigoureuse.
