Pour commencer, briefing de mission :
You have been assigned to a client that wants a penetration test conducted on an environment due to be released to production in three weeks.
Scope of Work
The client requests that an engineer conducts an external, web app, and internal assessment of the provided virtual environment. The client has asked that minimal information be provided about the assessment, wanting the engagement conducted from the eyes of a malicious actor (black box penetration test). The client has asked that you secure two flags (no location provided) as proof of exploitation:
- User.txt
- Root.txt
Additionally, the client has provided the following scope allowances:
- Ensure that you modify your hosts file to reflect internal.thm
- Any tools or techniques are permitted in this engagement
- Locate and note all vulnerabilities found
- Submit the flags discovered to the dashboard
- Only the IP address assigned to your machine is in scope
(Roleplay off)
I encourage you to approach this challenge as an actual penetration test. Consider writing a report, to include an executive summary, vulnerability and exploitation assessment, and remediation suggestions, as this will benefit you in preparation for the eLearnsecurity eCPPT or career as a penetration tester in the field.
Note – this room can be completed without Metasploit
1- La reconnaissance, ou comment découvrir à qui nous avons 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 découvre 2 ports bien connus ouverts :
- 22 : SSH (OpenSSH 7.6p1)
- 80 : Web (Apache httpd 2.4.29)
2- Mapping
Une recherche sur le web s’impose, et je décide de commencer avec OpenSSH, et j’obtiens comme résultat des liens vers cvedetails, exploitdb ou encore github avec un exploit publié.
Je décide de regarder un peu plus près du côté de l’exploit disponible afin de voir ce qu’on peut obtenir avec.
Je tourne un peu en rond avec ces exploits python développés à l’ère de python en version 2.x associé à leurs modules ayant eux aussi évolués entre-temps, je met de côté le SSH pour me changer d’air et me tourne du côté du serveur web.
Pour cela je lance une énumération avec ffuf pour trouver quelques dossiers intéressants
Je trouve un dossier au nom évocateur (provocateur même !) : wordpress.
L’affichage de la page est pour le moins … désastreux, et je vois une lien qui pointe vers le site http://internal.thm/blog/ ça tombe bien c’est également un dossier découvert avec ffuf.
Je crée donc une ligne de résolution DNS manuelle dans le fichier hosts pour le nom internal.thm.
Un petit coup de WPScan pour continuer l’énumération.
On obtient un résultat unique : l’utilisateur admin.
Je réalise un second scan avec ffuf afin de vérifier si je ne trouve pas de nouvelles pistes dans le sous-répertoire /blog.
Je décide alors de tenter ma chance, et je m’élance vers un bruteforce de l’accès admin accessible via l’URL /blog/wp-admin avec WPScan.
Hourra ! On trouve le mot de passe de l’utilisateur admin : my2boys.
3- Exploitation
Je me connecte à l’interface d’administration de WordPress, et j’ouvre un article non publié et en « privé« , ce qui m’affiche :
J’obtiens une paire d’identifiant/mot de passe : william / arnold147, avec un message « à faire » laissé, indiquant qu’il ne faut pas oublier de réinitialiser les accès d’un certain « Will« .
Du côté de l’interface de WordPress, je ne trouve pas d’autre utilisateur, j’en déduis que William est un utilisateur permettant de se connecter en SSH ou un autre service de la machine.
J’essaie alors avec les identifiants trouvés, sans succès, je suppose que le mot de passe à bien été réinitialisé (ou modifié).
Je me créé alors une wordlist custom reprenant le mot de passe arnold147 afin de tester toutes les possibilités de arnold000 jusqu’à arnold999, mais toujours sans succès.
J’ai tourné un moment en rond, puis je me suis demandé si ce n’était pas un joyeux « rabbit hole« , alors j’ai décidé de mettre de côté cette information pour le moment.
Ayant accès au panel administrateur de l’instance WordPress, je décide d’uploader un reverse shell en remplaçant la page d’erreur 404 par exemple.
Je lance netcat en écoute sur ma machine avant d’appeler une page inexistante dans l’instance WordPress et ainsi déclencher l’appel au reverse shell.
J’ai ensuite stabilisé et amélioré l’interactivité de mon shell à l’aide de l’appel python ci-dessus suivi de :
- CRL+Z
- stty raw -echo; fg; ls; export SHELL=/bin/bash; export TERM=screen; stty rows 38 columns 116; reset;
4- Elévation de privilèges
A partir de ce moment-là, je découvre dans un premier temps manuellement mon environnement et je remarque l’existence d’un user aubreanna (via le fichier passwd, ainsi que par la présence de son dossier personnel dans /home).
Je poursuis avec l’upload du script LinPEAS afin d’automatiser la recherche du chemin pouvant me conduire à l’obtention d’un shell utilisateur autre que www-data.
Je trouve grâce au script un fichier wp-save.txt étrange dans le répertoire /opt et décide d’y jeter un œil et il me donne alors une information précieuse :
Bill,
Aubreanna needed these credentials for something later. Let her know you have them and where they are.
aubreanna:bubb13guM!@#123
Il est temps d’essayer ces nouveaux identifiants !
Je récupère alors le joli drapeau flottant joyeusement dans le dossier personnel d’aubreanna :
THM{int3rna1_fl4g_1}
Toujours dans le dossier /home/aubreanna, je trouve le fichier jenkins.txt
Je réalise un curl sur 127.0.0.1:8080, et j’obtiens une réponse m’indiquant qu’il y a bien une instance de Jenkins qui tourne et qu’elle nécessite des identifiants afin de s’y connecter.
Je pense tout de suite à utiliser un tunnel SSH afin de pouvoir explorer (et exploiter ^^) cette instance.
J’ai désormais accès à l’interface Jenkins depuis ma machine d’attaque via mon localhost sur le port 8080 !
J’ai essayé manuellement quelques identifiants par défaut sans succès, je passe à l’automatisation à l’aide de Metasploit.
Le bruteforce nous donne le mot de passe suivant pour le compte admin : spongebob.
On vérifie la connexion avec les identifiants fraîchement trouvés :
Je vérifie si la console de script est disponible via l’URL /script et qui me permettrait d’exécuter des commandes directement à partir de l’utilisateur ayant lancé l’instance de Jenkins à l’intérieur du container dans lequel il se trouve.
Un whoami me renvoie « jenkins« , je vais alors déployer un script me permettant d’obtenir un nouveau reverse shell depuis le container :
Je démarre alors netcat en écoute sur ma machine avant de déclencher l’exécution du script et j’obtiens alors un shell, que je stabilise comme vu précédemment dans le writeup.
Petite impression de déjà-vu, je trouve un fichier énigmatique note.txt dans le dossier /opt, je décide de l’ouvrir et j’obtiens alors le sésame !
Le mot de passe du compte root laissé ici sans surveillance et en clair le bougre : tr0ub13guM!@#123
Je lance une nouvelle connexion SSH depuis ma machine vers la cible en utilisant le compte root ainsi que son mot de passe offert sur un plateau.
Il ne me reste plus qu’à cueillir le flag root :
Chaîne d’attaque
Retour d’expérience
Une room sur laquelle j’ai passé beaucoup de temps, quelques heures par ci par là car je voulais vraiment la faire « proprement » et aussi car je n’ai pas forcément trouvé le temps nécessaire à y consacrer pour la faire d’une traite
Quelques « rabbit holes » qui font perdre pas mal de temps (je pense aux identifiants de ce sacré William, ou alors le phpmyadmin et également la base accessible par l’utilisateur wordpress qui ne révèle pas d’informations)
J’ai personnellement pris beaucoup de plaisir sur ce challenge, essayant de le traiter avec un maximum de rigueur, j’ai été très satisfait de ma progression ainsi qu’à chaque trouvaille (utile ou non ^^).
TryHackMe classe cette room comme hard, pour ma part je la mettrais en medium pour la partie technique pure, mais au vue des quelques pièges et du temps qui m’a été nécessaire je valide la classification !
Conclusion
Du pur plaisir, je recommande pour débutant souhaitant un peu de challenge et se creuser un peu la tête (mais pas trop ^^), ou pour une personne qui aurait plus d’expérience mais souhaitant s’aguerrir quelque peu sur des sujets déjà maîtrisés.
Un gros point positif concernant la diversité de cette room.
