On est en face d’une machine Linux évaluée à « Easy » par HTB.
Le découpage se fera au travers des 2 grandes étapes classiques :
- obtention du flag utilisateur
- obtention du flag root
Let’s go !
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)
- 80 : nginx 1.24.0 (serveur web)
- 110 : Dovecot pop3d (serveur mail – pop3)
- 111 : rpcbind
- 143 : Dovecot imapd (serveur mail – imap)
- 993 : Dovecot imapd (serveur mail – imaps)
- 995 : Dovecot pop3d (serveur mail – pop3s)
- 2049 : NFS (Network File System)
- 41125,42037,51699,52937,54185 : Ports liées à diverses RPC (Remote Call Procedure)
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 :
Au vue des ports énumérés, la première évidence est que l’on va devoir traiter avec un serveur mail, et en second me vient le port 2049 et la possibilité d’un système de fichiers accessible.
2- Mapping
Je démarre ma cartographie en rendant visite au site web hébergé sur le port 80 de l’hôte, et pour cela je commence par créer l’entrée suivante dans mon fichier hosts (la sortie nmap sur le port 80 met en exergue une redirection vers le domaine enigma.htb).
Je consulte ensuite la page enigma.htb qui m’affiche ceci :
Après quelques recherches infructueuses ainsi qu’un fuzzing peu bavard, je décide de me tourner vers un éventuel partage NFS exposé. Pour cela j’utilise d’abord la commande showmount :
Enfin quelque-chose à se mettre sous la dent ! Je tente alors de monter ce partage :
Bingo ! Ca se monte bien, et en plus on trouve un document prometteur.
Je découvre une vraie mine d’informations :
- Un nouveau sous-domaine (mail001.enigma.htb)
- Un nom d’utilisateur (kevin)
- Un mot de passe associé (Enigma2024!)
- Et un mail de « contact » (it@enigma.htb)
J’ajoute alors le nouevau vhost à mon fichier hosts et je me dirige vers l’URL fournie dans le document :
3- Exploitation
Une fois connecté à l’interface (roundcube pour celles et ceux qui n’auraient pas reconnu) avec les credentials fournis dans le document, je remarque que j’ai un mail dans ma boite de réception en provenance d’une certaine Sarah.
Je me dis alors que si notre cher Kevin n’a pas eu la présence d’esprit, ni le rappel, de changer de mot de passe, il se peut alors que Sarah également !
Allez on le tente :
A ma grande satisfaction (ainsi qu’à mon grand désarroi ^^), le mot de passe n’a pas été changé. Je me dirige alors vers la boite de réception qui contient là aussi un mail intéressant :
Je récupère donc un nouveau vhost à ajouter à mon fichier hosts ainsi qu’un couple user / password que je vais m’empresser de tester !
J’utilise donc les creds fournis dans le mail, et là encore ça fonctionne à merveille et j’arrive sur le dashboard de l’application web :
Je trouve assez rapidemend la version de l’application, qui me permettra ensuite de chercher si il y a quelque-chose d’exploitable de ce côté là.
En faisant quelques recherches, je trouve effectivement une vulnérabilité de type time-based blind SQL injection qui impacte cette version ainsi que les précédentes :
J’ai donc utilisé l’exploit public disponible afin d’obtenir le hash de l’administrateur stocké dans la base :
Malheureusement je n’ai pas réussi ni à reverse ni à casser le hash lié au compte admin, alors je continue de chercher car j’ai dû manquer quelque-chose. Et en effet, en fouillant sur l’application openstamanger, j’ai vu qu’un autre utilisateur était renseigné dans l’application, j’ai nommé haris :
Je modifie alors l’exploit (initialement prévu pour leak les infos de l’utilisateur admin) afin de récupérer les informations lié au compte haris fraîchement trouvé :
J’ai commenté les 2 premiers steps de l’exploit pour ne pas perdre de temps à récupérer des infos que j’avais déjà, et j’ai modifié la condition de récupération du hash de « WHERE id=1 » vers « WHERE id=2 » en espérant que mon petit haris soit bien le second enregistré (il n’y a que 2 utilisateurs mais bon ne sait-on jamais).
Après le lancement de l’exploit modifié, je récupère bel et bien un nouveau hash, correspondant au mot de passe de haris.
Je lance ensuite une recherche sur ce hash, mais je ne trouve pas de candidat, je passe alors à l’étape cassage brutal avec hashcat :
Super content d’en être arrivé jusqu’ici, je part donc à la conquête d’une connexion SSH avec ces creds, mais là, c’est le drame !
Je n’avais pas prếté attention, mais nmap me l’avait signalé, la connexion SSH ne se fait qu’à l’aide d’une clé publique, quelle déception.
Je retourne creuser du côté de l’app web, et je trouve une autre vulnérabilité permettant l’upload de fichier, la CVE-2026-38751 :
Au vue de la simplicité de la mise en place de l’exploit, j’ai pris la décision de la réaliser « manuellement », sans employer l’exploit public. Pour cela il m’a fallu un shell php (j’ai choisi p0wnyShell je l’aime bien), je l’ai ensuite nommé shell.php, placé dans un dossier nommé shell et à côté j’ai créé un fichier MODULE contenant les informations nécessaire pour se faire passer pour un module installable :
Contenu du fichier MODULE :
name = "shell"
directory = "shell"
version = "1.0"
compatibility = "2.10"
options = ""
icon = "fa fa-bug"
parent = "Dashboard"
J’ai ensuite zippé le dossier shell vers un fichier nommé shell.zip, que j’ai ensuite uploadé via la page dédiée de l’application :
Je me dirige vers le shell fraîchement uploadé (ici : http://support_001.enigma.htb/modules/shell/shell.php) :
YESSS ! Enfin mon premier shell, je vous jure que ça a fait du bien de le voir apparaître, parce qu’on dirait peut-être pas en lisant l’article, mais j’ai vraiment tatonner de partout avant d’arriver à ce résultat !
Première chose que je fais : obtenir un shell console pour être plus à l’aise :
Une fois mon listener connecté, j’en profite pour tester les creds de haris :
J’en profite pour attraper le flag utilisateur au passage.
Le flag utilisateur :
aa01041767e64529263ab77bbb167886
Comme dis juste avant, j’aime bien me sentir à l’aise, et avec un shell instable et incomplet je me sens … pas super à l’aise ! Qu’à cela ne tienne, je vais faire un peui de persistence et ajouter une clé SSH générée à partir de mon poste attaquant afin de me connecter en SSH et avoir un beau shell comme je les aime.
J’ajoute maintenant la clé publique générée aux clés autorisées :
Il ne me reste plus qu’à me connecter « proprement » avec ma clé privée :
Me voila à l’aise comme dans une vieille paire de chaussons …
Maintenant je pars à la conquête d’une élévation de privilège afin de récupérer le flag root !
4- Elévation de privilèges
Je commence par les classiques (sudo -l, vérification des tâches CRON, …), mais vu que je fais chou blanc, je décide d’utiliser un outil plus « costaud », j’ai nommé l’excellent LinPEAS :
Dans l’énoOorme quantité d’informations qui défilent, je finis par m’interroger à propos d’un port en écoute sur l’interface locale uniquement, le 1337 (suspect n’est-il pas ?).
Je vérifie de quoi il en retourne.
Un certaine OliveTin qui traîne par là, je décide d’exposer ce port 1337 sur mon PC attaquant via un tunnel SSH.
J’obtiens cette magnifique interface :
A partir de là de nouvelles recherches s’imposent, qui m’ont conduit à la CVE-2026-27626 :
Je décide de me faire mon payload à moi (et rien qu’à moi) que je sauve dans un fichier « revshell.sh » :
Pour faire fonctionner la chaîne complète, je dois mettre en place un serveur web afin que le payload puisse récupérer le script « revshell.sh ».
En faisant le tour dans l’application web je trouve (enfin) un candidat à cette exploitation dans la page « Backup database ».
J’ai aussi besoin d’un listener qui recevra la connexion de mon reverse shell :
Et voici le flag root :
4f4c3bd1c5e753692a6ce49fbf6642e4
5- Chaîne d’attaque
6- Retour d’expérience
Une machine notée Easy, mais pour laquelle j’ai positionné le flag root comme étant « Not so easy ».
Je commence à prendre mes marques sur les machines HTB, il s’agit de ma seconde et je sens que je m’en sors déjà mieux et que ce ne sera pas la dernière !
Comme toujours une expérience complète, loin, très loin de la simple exploitation sans compréhension du système, de ses contraintes et de tout ce qui l’entoure.
7- Conclusion
Partage NFS trop permissif, credentials en clair, réutilisation de mot de passe et absence de mise à jour sont d’autant de problèmes qui facilitent et même rendent possible la plupart des attaques informatique.
C’est autant de faiblesses que j’ai pu retrouver dans Enigma qui m’a personnellement fait par moment tourner en rond mais toujours avec plaisir !
