Il s’agit là d’une machine évaluée « Easy » tournant sous Linux.
Elle va se scinder en 2 macro-étapes :
- Récupération du flag user.
- Obtention du flag root.
1- Reconnaissance
Je démarre la découverte de cette machine par un scan Nmap :
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 :
- 22 : OpenSSH 9.6p1 (serveur SSH)
- 3000 : Port par défaut des projets React (associé au nom de la machine + les en-tête HTTP x-nextjs-* c’est suspicieux)
Petit tips que j’utilise désormais, j’ai nommé la commande xsltproc :
Cette outil permet de générer un fichier html à partir du xml en sortie de Nmap qui ressemble à ceci :
2- Mapping
Au vue des résultats de Nmap, je décide de jeter un coup d’oeil à ce qu’il se passe sur le port 3000.
Pour m’assister dans ma tâche je me repose sur l’excellente extension Wappalyzer :
Ces informations me confirme ce que je pressentais, il s’agit bien d’un serveur web sous React.
Je me penche alors sur une vulnérabilité récente ayant fait beaucoup de bruit : React2Shell, et je décide d’utilser l’outil suivant :
Je continue ma cartographie en vérifiiant si la cible est bien vulnérable à cette faille.
Excellente nouvelle je suis sur la bonne voie !
3- Exploitation
Je relance l’outil précédemment utilisé afin de valider la présence de la vulnérabilité, cette fois-ci afin d’obtenir un shell :
Génial ! J’obtiens mon shell tant attendu, en tant que l’utilisateur node.
En « fouillant » je trouve un fichier .env contenant une indication concernant une base de données sqlite :
Je décide ensuite naturellement de parcourir cette BDD.
Par acquis de conscience je vérifie le format des hashes :
Je me lance dans la récupération du mot de passe correspondant à chaque hash.
Pour celui lié au compte admin pas de succès, mais j’obtiens celui de l’utilisateur engineer :
Je tente alors une connexion SSH avec ces nouveaux creds obtenus.
J’en profite pour visiter les alentours, et je tombe alors sur le flag utilisateur, que je m’empresse de consulter.
Je me retrouve alors très satisfait de mon évolution, et repart avec ce joli flag en récompense :
353d06f4e5d9004f1f48b44c03961923
4- Elévation de privilèges
A partir de là, j’utilise LinPEAS afin de trouver un (ou des) vecteur(s) d’élévation de privilèges.
Je commence par l’uploader sur la machine :
Une fois lancé (je ne vais pas mettre toute la sortie ici ca alourdirait quelque peu l’article), je trouve un chemin potentiel (et toujours en rapport avec le « reactor »).
Je remarque aussitôt que le process « node » est lancé avec l’argment « –inspect » permettant ainsi le debugging de l’application sur le port 9229 en local.
Qu’à cela ne tienne, j’utilise un tunnel SSH afin d’exposer le port 9229 sur ma machine attaquante :
A partir de ce moment, je peux lancer mon navigateur afin de me connecter à l’application en attente de debuggage.
Via les outils pour développeurs, j’envoie une payload me permettant de déclencher un reverse shell sur ma machine :
Du côté de ma machine, j’avais au préalable lancé un listener qui va recevoir la connexion depuis le rev shell.
Il ne me reste plus qu’à terminer le travail en récupérant le flag root.
Me voila en possession de l’ultime césame, ouf !
dac18c857ccb08c54d900d149adc729e
5- Chaîne d’attaque
6- RETEX
Un bon retour d’expérience ça ne fait jamais de mal !
Il s’agit de ma première machine HackTheBox, je pratiquais presque exclusivement sur TryHackMe auparavant, et je dois avouer que c’est plutôt différent (voire déroutant ?).
En effet, j’ai le sentiment que les boxs THM sont plus « évidentes » à casser, et on est plus guider (et parfois même tenus par la main). Ce qui m’a le plus étonné c’est le fait qu’à l’obtention du 1er shell, je n’avais pas de flag ! Là ou sur TryHackMe j’ai l’impression que chaque « micro step » est courroné de flag à faire valider, ou alors lorsqu’une room se décline en 2 flags comme ici, le 1er s’obtient à la première compromission, et le second est ensuite plus ou moins simple à obtenir.
Pour une machine notée « Easy », j’estime avoir plus (trop) galéré qu’escompté initialement.
7- Conclusion
Pour conclure, je dirais qu’une fois passé l’étonnement j’ai pris beaucoup de plaisir à chercher et avancer (lentement au départ j’avoue), et j’ai constaté un réel gap de « complexité » entre une box « Easy » de THM et celle-ci pour laquelle j’ai voté « Not so easy » aux 2 résolutions de flag.
