heventafese/penetration-testing-walkthrough-hacksudo-thorBlack-box penetration test against HackSudo Thor : CVE-2014-6271 Shellshock RCE through Apache mod_cgi, chained with sudo misconfiguration and bash eval injection for full privilege escalation. Includes custom CSRF-aware brute force tooling and Metasploit RPC automation.
Cible : HackSudo Thor de VulnHub
Objectif : Obtenir un accès root et lire/root/proof.txt
Environnement : Laboratoire VirtualBox isolé segmenté par un pare-feu pfSense
Ce référentiel documente un test de pénétration en boîte noire partiel mené sur HackSudo Thor, une machine virtuelle intentionnellement vulnérable publiée sur VulnHub par Vishal Waghmare. L'objectif était de simuler une attaque réelle où un attaquant externe tente de compromettre un système interne isolé avec pour objectif principal d'obtenir un accès root et de lire le contenu de /root/proof.txt.
L'évaluation suit le cycle de vie complet du test de pénétration : reconnaissance passive, découverte du réseau, énumération, évaluation des vulnérabilités, exploitation, élévation de privilèges, post-exploitation et dissimulation des traces.
Les principaux outils utilisés étaient Nmap pour le scan réseau, Nessus pour l'évaluation des vulnérabilités, et le Metasploit Framework comme plateforme principale d'exploitation et de post-exploitation. John the Ripper, Hashcat et des Rainbow Tables en ligne ont été utilisés pendant l'étape de cassage de mots de passe, bien que toutes les tentatives aient finalement échoué en raison de la robustesse de l'algorithme de hachage utilisé.
Le laboratoire virtuel a été entièrement construit dans VirtualBox et conçu pour simuler un réseau d'entreprise réaliste avec trois zones de sécurité distinctes, toutes gérées par un pare-feu pfSense 2.7.2. Les trois réseaux NAT ont été configurés comme suit : une zone WAN simulant l'internet public où se trouve la machine attaquante Kali, une zone DMZ hébergeant la machine cible, et une zone LAN interne contenant des machines hors périmètre.``` Internet Zone — NatNetwork (10.0.2.0/24) │ │ Kali Linux 2025.4 [attacker] — 10.0.2.9 │ pfSense WAN interface — 10.0.2.8 │ ├── pfSense Firewall (boundary device) │ ├── DMZ Zone — DMZnat (10.0.4.0/24) │ ├── HackSudo Thor [TARGET] — 10.0.4.3 │ └── DVWA — 10.0.4.4 (out of scope) │ └── LAN Zone — LANnat (10.0.3.0/24) ├── Metasploitable 2 — 10.0.3.5 (out of scope) └── Windows XP Cyberlab — 10.0.3.4 (out of scope)
*Zones de sécurité de la topologie logique du réseau gérées par pfSense*
L'interface WAN a reçu l'adresse `10.0.2.8/24` via DHCP, l'interface LAN a été configurée en `10.0.3.1/24` et l'interface OPT1 (DMZ) en `10.0.4.1/24`. Pour introduire une erreur de configuration volontaire dans le laboratoire, le port 80 a été intentionnellement laissé exposé sur l'interface WAN de pfSense, simulant une exposition courante de panneau d'administration dans le monde réel qui a servi de point d'entrée principal vers le réseau interne.
---
## Résumé de la chaîne d'attaque```
[Kali Linux — 10.0.2.9]
│
│ CSRF-aware Python brute force → admin / pfsense
▼
[pfSense webConfigurator — 10.0.2.8:80]
│
│ Firewall rules disabled → DMZ and LAN now reachable
▼
[HackSudo Thor — 10.0.4.3]
│
│ Shellshock RCE (CVE-2014-6271)
│ Apache mod_cgi → /cgi-bin/shell.sh
▼
[Meterpreter shell — www-data]
│
│ sudo -u thor /home/thor/hammer.sh
│ Command injection via eval → bash -i payload
▼
[Interactive shell — thor]
│
│ GTFOBins: sudo service ../../bin/bash
▼
[Root shell]
│
├── /root/proof.txt captured ✅
├── /etc/shadow + /etc/passwd exfiltrated
└── SSH RSA backdoor planted
Avant tout contact avec l'environnement cible, des informations ont été collectées exclusivement à partir de sources publiques. Les deux sources principales étaient la page d'entrée officielle de VulnHub pour HackSudo Thor et le profil GitHub public de l'auteur.
La page VulnHub confirmait que la cible était un système basé sur Linux, classé facile à moyen, avec pour objectif la recherche du fichier proof.txt. L'examen du profil GitHub de l'auteur a fourni des informations supplémentaires. Vishal Waghmare conçoit systématiquement des machines Linux de type boot-to-root où l'élévation de privilèges est le défi central de toute la série HackSudo. Cela a façonné le modèle de menace pour les phases actives : les services HTTP et SSH étaient la surface d'attaque la plus probable, et le chemin d'élévation était prévu comme impliquant une mauvaise configuration de sudo, un abus de binaire SUID ou l'exploitation d'un service personnalisé.
Ce type d'analyse des schémas de l'auteur est également important dans un engagement réel. Comprendre comment un système a probablement été conçu et quelles catégories de faiblesse son administrateur est susceptible de répéter donne une direction avant même l'envoi d'un seul paquet.
Cette phase a consisté à prendre un contact actif direct avec l'environnement. L'objectif était d'identifier tous les hôtes actifs, de comprendre la frontière du réseau et de construire une image complète de la surface d'attaque avant de se concentrer sur la cible principale.
Un léger balayage ping Nmap (-sn) a d'abord été exécuté sur le sous-réseau WAN (10.0.2.0/24) pour découvrir les hôtes actifs avec un minimum de bruit. Trois hôtes ont été identifiés : 10.0.2.1 et 10.0.2.2 étaient des adresses standard de l'infrastructure VirtualBox, ce qui laissait 10.0.2.8 comme seul hôte non infrastructurel. Cette machine est devenue l'objet d'attention immédiat.
Un balayage SYN furtif complet contre 10.0.2.8 n'a retourné aucun résultat. Ce comportement était attendu et non une erreur. Les pare-feu d'entreprise sont conçus pour être insensibles au balayage de ports, en supprimant silencieusement les paquets plutôt qu'en répondant. L'absence de résultats était elle-même une confirmation qu'il s'agissait d'un périphérique frontal filtrant activement le trafic.
Pour confirmer quels services étaient réellement en cours d'exécution sans recourir au balayage de paquets, une requête HTTP directe a été émise avec curl. Cette approche a été adoptée car une requête web standard a beaucoup moins de chances d'être filtrée qu'un outil de balayage. La réponse est revenue sous la forme HTTP/1.1 200 OK avec Server: nginx et un titre de page pfSense, confirmant que le webConfigurator était directement accessible sur le port 80 depuis l'interface WAN.
Avec la page de connexion confirmée, l'étape suivante consistait à tenter de récupérer les identifiants. Hydra a d'abord été choisi comme outil de brute force, mais cette tentative a échoué pour deux raisons. La première était pratique : rockyou.txt contient plus de 14 millions d'entrées, ce qui le rendait impraticable dans le temps imparti à cette évaluation. La seconde était technique et plus significative : pfSense 2.7.2 implémente une protection par jeton CSRF, générant un jeton cryptographique unique à chaque chargement de page, qui doit être soumis avec les identifiants. Le module HTTP POST d'Hydra soumet un corps de requête statique et n'a aucun mécanisme pour récupérer dynamiquement un nouveau jeton à chaque tentative, donc chaque soumission était rejetée avant même que le mot de passe ne soit vérifié.
Pour contourner cela, un script Python personnalisé a été écrit pour reproduire le processus de connexion complet du navigateur. Pour chaque tentative de mot de passe, le script ouvre une nouvelle session, charge la page de connexion, extrait le jeton CSRF actuel du formulaire HTML, puis soumet les identifiants accompagnés de ce jeton exactement comme le ferait un navigateur. Une liste de mots personnalisée a été construite avec CeWL en explorant la page de connexion de pfSense et en extrayant les termes pertinents, puis complétée avec fasttrack.txt pour couvrir les identifiants par défaut connus.
Le script a récupéré les identifiants : admin / pfsense, les identifiants par défaut inchangés.
Script Python personnalisé récupérant les identifiants pfSense
Avec l'accès au tableau de bord établi, la configuration des interfaces pfSense a été examinée pour comprendre la topologie interne complète. Cela a révélé deux sous-réseaux qui étaient invisibles depuis le WAN : un LAN en 10.0.3.0/24 et un DMZ en 10.0.4.0/24. Les règles du pare-feu WAN ont ensuite été désactivées via l'interface web, et deux règles de passage ont été ajoutées pour autoriser le trafic depuis l'IP de l'attaquant vers les deux sous-réseaux.
Des balayages ping Nmap sur les deux sous-réseaux ont identifié six hôtes actifs. Quatre d'entre eux ont été énumérés plus en détail, à l'exception de 10.0.4.1 et 10.0.3.1, qui appartenaient aux interfaces de passerelle pfSense. Un balayage combiné d'énumération de services avec détection de version, scripts NSE par défaut et empreinte OS a été exécuté simultanément sur les quatre. En croisant les résultats avec la reconnaissance passive, chaque machine de la topologie a été identifiée :
La cible a été confirmée comme étant 10.0.4.3. Toute activité ultérieure a été exclusivement concentrée sur cette machine.
Une fois la cible identifiée, une analyse plus approfondie de ses services a été effectuée pour cartographier la surface d'attaque et déterminer les voies d'exploitation viables. Le Metasploit Framework a été utilisé comme plateforme principale pour cette phase, notamment parce que son backend PostgreSQL persiste tous les résultats de balayage entre les sessions : hôtes, services et vulnérabilités sont tous stockés dans la base de données et peuvent être consultés lors des phases ultérieures sans avoir à rescanner.
Avant de commencer, Metasploit a été initialisé avec msfdb init, la connexion à la base de données a été vérifiée avec db_status, et tout le travail suivant a été effectué depuis msfconsole.
La commande db_nmap a été utilisée pour exécuter un balayage complet contre 10.0.4.3 : balayage SYN furtif, détection de version de service, scripts NSE par défaut, empreinte OS, et tous les 65 535 ports TCP. Les résultats ont été stockés automatiquement dans la base de données et récupérés avec hosts et services. Trois services ont été confirmés ouverts : FTP sur le port 21 tournant Pure-FTPd, SSH sur le port 22 tournant OpenSSH 7.9p1, et HTTP sur le port 80 tournant Apache 2.4.38.
Chaque service a ensuite été énuméré plus en détail à l'aide de modules auxiliaires ciblés de Metasploit. Le service HTTP a reçu le plus d'attention. Les modules dir_scanner et http_crawler ont été utilisés pour cartographier tous les chemins et points d'accès accessibles sur le serveur web. La découverte la plus significative a été le répertoire /cgi-bin/ et un script nommé shell.sh. Par ailleurs, un examen manuel du code source HTML de news.php a révélé un commentaire caché de l'auteur faisant référence au répertoire /cgi-bin/, un indice délibéré pointant vers une vulnérabilité basée sur CGI. Le service FTP a été vérifié pour un accès anonyme (désactivé), et la chaîne de version a été notée pour recoupement avec des CVE. La bannière SSH a été récupérée dans le même but.
Une fois la surface d'attaque entièrement cartographiée, une évaluation structurée des vulnérabilités a été réalisée en utilisant deux approches : un scan Nessus automatisé et un raisonnement manuel de l'attaquant appliqué à chaque service.
Une politique Nessus personnalisée a été créée avec le balayage CGI et les tests d'applications web explicitement activés, ciblant les ports 21, 22 et 80. Ces paramètres ne sont pas activés par défaut et étaient critiques ici ; sans eux, le point d'accès CGI n'aurait pas été testé. Le scan a duré environ 11 minutes et a retourné 41 résultats au total. Les résultats exploitables étaient :
Les deux résultats Shellshock sur /cgi-bin/shell.sh étaient immédiatement prioritaires. CVE-2014-6271 porte un score CVSS de 9,8 et permet une exécution de code à distance non authentifiée, le résultat à plus fort impact du scan. CVE-2014-6278 représente un correctif incomplet de la même vulnérabilité, ce qui signifie que même les systèmes partiellement corrigés restent exploitables. La faiblesse SSH Terrapin a été évaluée comme non exploitable sans une position d'homme du milieu. Les résultats restants n'avaient pas de valeur d'exploitation significative dans cet engagement.
Avant de passer à l'exploitation, le résultat Shellshock a été vérifié indépendamment à l'aide du script NSE http-shellshock de Nmap ciblant directement /cgi-bin/shell.sh. La vérification indépendante avant l'exploitation est une étape importante de la méthodologie, car elle confirme que la vulnérabilité est réelle et non un faux positif du scanner, et elle évite de perdre du temps à tenter une exploitation qui échouerait. Le script NSE a confirmé que le point d'accès était vulnérable, et CVE-2014-6271 a été sélectionné comme vecteur d'attaque principal.
Avec Shellshock confirmé, la phase d'exploitation a commencé. La vulnérabilité existe parce qu'Apache mod_cgi transmet les en-têtes de requête HTTP comme variables d'environnement à Bash lorsqu'un script CGI est invoqué. Dans une version non corrigée de Bash, une définition de fonction spécialement conçue dans une variable d'environnement provoque l'exécution immédiate de toutes les commandes ajoutées après la définition. En injectant cette charge utile dans l'en-tête User-Agent d'une requête vers /cgi-bin/shell.sh, des commandes arbitraires pouvaient être exécutées sur le serveur sans aucune authentification.
Le module Metasploit exploit/multi/http/apache_mod_cgi_bash_env_exec automatise entièrement cela. Le module a été configuré avec RHOSTS défini sur 10.0.4.3, TARGETURI défini sur /cgi-bin/shell.sh, la charge utile définie sur linux/x86/meterpreter/reverse_tcp, et l'écouteur pointé vers la machine Kali sur le port 4444. L'exécution du module a envoyé la requête malveillante, le serveur a exécuté la charge utile, et Metasploit a reçu la connexion entrante, établissant une session Meterpreter en tant que www-data.
Exploit Shellshock exécuté et shell inverse Meterpreter établi en tant que www-data
En partant de www-data, l'étendue de l'accès au système était initialement inconnue. La priorité immédiate était de comprendre la position actuelle : qui était l'utilisateur actif, quels autres comptes existaient, et quels chemins étaient disponibles vers des privilèges plus élevés.
La session Meterpreter a été basculée vers un shell système brut, et un pseudo-terminal a été créé en utilisant le module pty de Python pour obtenir un terminal interactif correct. La lecture de /etc/passwd et le listage de /home/ ont confirmé la présence d'un utilisateur nommé thor sur le système. Un premier ls -la /home/thor/ a retourné une erreur d'autorisation, donc le système de fichiers a été exploré pour trouver tous les fichiers appartenant à thor, indépendamment des autorisations des répertoires, en utilisant find / -user thor 2>/dev/null. Cela a localisé un binaire anormal à /usr/local/sbin/ls, un fichier nommé ls qui n'était pas le binaire système standard. Son contenu a révélé qu'il s'agissait d'un script personnalisé appartenant à Thor, ce qui a été noté pour une enquête ultérieure.
L'étape standard post-exploitation de vérification des permissions sudo de l'utilisateur actuel a été effectuée avec sudo -l. Cela a révélé que www-data était autorisé à exécuter /home/thor/hammer.sh en tant qu'utilisateur thor sans mot de passe requis, une règle NOPASSWD sans justification opérationnelle légitime.
sudo -l confirmant que www-data peut exécuter hammer.sh en tant que thor sans mot de passe
L'accès direct pour lire hammer.sh a été bloqué par les permissions du répertoire, donc il a d'abord été exécuté avec sudo -u thor /home/thor/./hammer.sh pour observer son comportement. Le script présentait deux invites interactives : une « Secret Key » et un « Secret Message ». La première invite renvoyait l'entrée comme un message de bienvenue. La seconde traitait l'entrée puis quittait. La distinction entre ces deux comportements était significative : si les deux invites se contentaient de renvoyer l'entrée, aucune ne serait intéressante. Le fait que la seconde invite traitait l'entrée avant de répondre suggérait qu'elle transmettait la valeur à une commande shell, un modèle cohérent avec une instruction eval, qui est une surface d'attaque bien documentée pour l'injection de commandes.
Lors d'une deuxième exécution, une entrée vide a été fournie à la première invite. La charge utile d'injection bash -i a été fournie à la seconde. Cela a généré un shell interactif en tant que thor.
Charge utile bash -i injectée dans hammer.sh
sudo -l a été exécuté à nouveau en tant que thor. Cela a révélé un accès NOPASSWD sans restriction à la fois à /usr/bin/cat et à service en tant que root. La règle service était la plus significative. La technique sudo service de GTFOBins permet de passer une chaîne de traversée de chemin comme argument du nom de service. En fournissant ../../bin/bash, le binaire service résout la traversée et invoque /bin/bash avec les privilèges root.```bash
sudo service ../../bin/bash
Cela a produit un shell root complet.
*Shell root obtenu, escalation de privilège via GTFOBins sudo service path traversal confirmée*
## Phase 7 : Post-exploitation
Une fois l'identité root confirmée, la phase de post-exploitation s'est concentrée sur trois domaines : comprendre l'environnement système, extraire les données sensibles et établir un accès persistant.
### Informations système et flag
Un recensement système de base a d'abord été effectué pour confirmer l'identité de la cible et construire le contexte des recommandations de correction, notamment la version du noyau, la version du système d'exploitation et la configuration réseau. Le système a été identifié comme Debian GNU/Linux 10 (Buster) exécutant le noyau 4.19.0-17-686-pae sur `10.0.4.3`.
Le répertoire personnel de root a été listé, révélant `proof.txt` et `root.txt`. Le fichier `proof.txt` a été lu pour capturer le flag principal, l'objectif déclaré de cet engagement.
*Contenu de proof.txt – flag principal capturé*
### Extraction de mots de passe et craquage
Les fichiers `/etc/shadow` et `/etc/passwd` ont été copiés dans `/tmp` et téléchargés sur la machine attaquante via Meterpreter. Ces deux fichiers fournissent ensemble les comptes utilisateur système et les hashs de mots de passe nécessaires au craquage hors ligne.
Plusieurs approches de craquage ont été tentées. John the Ripper a identifié les deux hashs comme étant SHA-512crypt avec un facteur de coût de 5 000 itérations. Une première tentative utilisant `rockyou.txt` a été abandonnée après des heures d'exécution sans résultat. Le coût de calcul du SHA-512crypt rend les attaques par dictionnaire exhaustives très lentes sans accélération GPU. Une seconde tentative avec une wordlist personnalisée ciblée, construite à partir des renseignements collectés lors de la reconnaissance, s'est terminée rapidement mais n'a donné aucun résultat.
CrackStation a ensuite été essayé comme service de tables arc-en-ciel en ligne, mais il a renvoyé un format de hash non reconnu pour les deux entrées. C'était attendu : SHA-512crypt ajoute un sel aléatoire unique à chaque hash avant le hachage, ce qui signifie que le même mot de passe produit un hash différent pour chaque compte. Les tables arc-en-ciel fonctionnent en précalculant les hashs de mots de passe connus, mais une table séparée serait nécessaire pour chaque valeur de sel possible, rendant l'approche totalement impraticable contre les hashs salés.
Hashcat a été utilisé pour les dernières tentatives, avec trois wordlists successives : `fasttrack.txt` (épuisée en 4 secondes), une liste ciblée personnalisée (épuisée sans correspondance) et les 100 000 premières entrées de `rockyou.txt` (échec après 3 minutes). Toutes les tentatives de craquage de mots de passe ont échoué. L'utilisation de SHA-512crypt salé avec un nombre d'itérations élevé en est la raison : l'algorithme est conçu pour être coûteux en calcul, précisément pour résister à ce type d'attaque hors ligne.
### Recherche de clés SSH
Une recherche dans le système de fichiers a également été menée pour les fichiers de clé privée RSA et les certificats PEM à l'aide de `find`. Toute clé privée trouvée aurait pu donner accès à d'autres systèmes qui font confiance à la clé publique correspondante, une opportunité précieuse de mouvement latéral. Aucune clé privée appartenant à d'autres systèmes n'a été trouvée.
### Déploiement de backdoor
Un accès persistant a été mis en place en injectant une clé publique RSA dans le fichier `authorized_keys` du compte root. L'authentification par clé SSH a été choisie car elle ne repose pas sur des mots de passe et est difficile à détecter à moins que le fichier `authorized_keys` ne soit spécifiquement audité. Une paire de clés RSA de 4096 bits a été générée sur la machine Kali, et la clé publique a été ajoutée à `/root/.ssh/authorized_keys` sur la cible avec les permissions correctes pour le répertoire et le fichier. Une connexion de retour à la cible en utilisant la clé privée a été établie pour vérifier que la backdoor fonctionnait.
*Accès root persistant confirmé via authentification par clé privée*
### Automatisation
Un script Python personnalisé pour l'API RPC de Metasploit (`thor_full_chain.py`) a également été développé pour automatiser l'intégralité de la chaîne de post-exploitation. Le script se connecte à une session RPC Metasploit active et gère la séquence complète : stabilisation du shell `www-data`, injection de `hammer.sh` pour passer à thor, escalation GTFOBins vers root, capture du flag, extraction des identifiants et déploiement de la backdoor, avec journalisation horodatée sauvegardée dans un fichier local. Il s'agissait d'un livrable supplémentaire démontrant la capacité d'automatisation de la chaîne d'attaque à l'aide de l'API RPC de Metasploit. Voir `scripts/thor_full_chain.py` pour l'implémentation complète.
## Phase 8 : Dissimulation des traces
La phase finale consistait à supprimer les preuves de l'intrusion à la fois sur le système cible et sur la machine attaquante Kali. Sur la cible, le journal d'accès Apache était le fichier le plus critique à effacer, car il contenait la requête HTTP Shellshock brute qui a déclenché l'exploit initial. Le journal d'authentification a été effacé, car il stockait chaque commande sudo utilisée pendant la phase d'escalade. Le syslog, les enregistrements binaires de connexion (`wtmp`, `btmp`, `lastlog`) et l'historique bash de `root` et `www-data` ont tous été écrasés et vérifiés vides.
Sur Kali, l'espace de travail Metasploit a été supprimé avec `workspace -d default`, les fichiers d'identifiants téléchargés ont été supprimés, la paire de clés SSH a été effacée et l'historique bash a été nettoyé. Chaque étape a été vérifiée avant de passer à la suivante.
Une exception délibérée a été faite pour la backdoor SSH, et ses fichiers de clés associés ont été conservés sur la cible et non supprimés à ce stade, car ils étaient nécessaires à des fins de démonstration lors de la présentation de l'évaluation.
## Vulnérabilités exploitées
| Vulnérabilité | CVE | CVSS | Composant | Méthode |
|--------------|-----|------|-----------|--------|
| Shellshock RCE | CVE-2014-6271 | 9.8 | Apache mod\_cgi + Bash non patché | Metasploit avec en-tête User-Agent malveillant |
| Identifiants par défaut | — | — | pfSense webConfigurator | `admin / pfsense` inchangés après installation |
| Mauvaise configuration sudo (www-data) | — | — | `/etc/sudoers` | NOPASSWD `hammer.sh` exécutable en tant que thor |
| Injection de commande dans hammer.sh | — | — | Script bash personnalisé | Injection `eval` via payload `bash -i` |
| Mauvaise configuration sudo (thor) | — | — | `/etc/sudoers` | NOPASSWD `service` sans restriction en tant que root |
---
## Outils utilisés
| Outil | Objectif |
|------|---------|
| Nmap | Découverte d'hôtes, scan de ports, empreinte OS, vérification Shellshock via NSE |
| Metasploit Framework | Énumération basée sur base de données, exploitation, Meterpreter, post-exploitation |
| Nessus Essentials | Évaluation structurée des vulnérabilités avec scan CGI et applications web |
| Hydra | Première tentative de brute force pfSense infructueuse en raison de la protection CSRF |
| CeWL | Génération de wordlist personnalisée en explorant la page de connexion pfSense |
| Python 3 + BeautifulSoup | Script de brute force pfSense conscient du CSRF |
| pymetasploit3 | Client API RPC Metasploit pour l'automatisation complète de la chaîne d'attaque |
| John the Ripper | Craquage hors ligne de hash SHA-512crypt |
| Hashcat | Tentatives de craquage SHA-512crypt accélérées par GPU |
| CrackStation | Consultation de tables arc-en-ciel en ligne |
| GTFOBins | Référence pour la technique d'escalade de privilèges via sudo service |
| curl | Vérification de service HTTP sur l'interface WAN pfSense |
---
## Recommandations
**Corriger Bash immédiatement.** La vulnérabilité Shellshock existe car Bash n'a jamais été mis à jour sur ce système Debian 10. L'exécution de `apt-get update && apt-get upgrade bash` supprime la vulnérabilité. Au-delà du correctif, si les scripts CGI ne sont pas nécessaires sur le plan opérationnel, le répertoire `/cgi-bin/` doit être entièrement désactivé dans la configuration Apache, supprimant ainsi la surface d'attaque quelle que soit la version de Bash.
**Auditer et durcir les règles sudo.** Deux règles sudo NOPASSWD ont constitué l'intégralité de la chaîne d'escalade de privilèges. Aucune de ces règles n'a de justification légitime. Le fichier `/etc/sudoers` doit être examiné et les deux entrées supprimées. Le principe du moindre privilège doit régir toute future configuration sudo ; les comptes ne doivent avoir que l'accès spécifique dont ils ont réellement besoin, rien de plus.
**Supprimer eval des scripts shell.** Le script `hammer.sh` transmettait l'entrée utilisateur directement dans une instruction `eval` sans aucune validation ni assainissement. C'est ce qui a rendu l'injection de commande possible. L'utilisation de `eval` doit être évitée dans les scripts shell qui acceptent des entrées utilisateur, car cela représente presque toujours une surface d'attaque. Les entrées doivent être validées par rapport à une liste blanche stricte avant tout traitement.
**Modifier les identifiants par défaut de pfSense et restreindre l'accès.** Le webConfigurateur était exposé sur l'interface WAN avec les identifiants par défaut inchangés `admin / pfsense`. Les identifiants par défaut doivent être modifiés immédiatement après l'installation. Le webConfigurateur ne doit jamais être accessible depuis le WAN ; l'accès doit être limité au LAN ou à une interface de gestion dédiée uniquement.
**Mettre en place une journalisation centralisée.** Lors de la phase 8, tous les journaux locaux ont été effacés en quelques minutes, ne laissant aucune trace de l'intrusion sur le système cible. Cela a démontré que la cible ne disposait d'aucune gestion centralisée des journaux. Dans un environnement de production, les journaux doivent être transférés en temps réel vers un SIEM distant. Cela garantit que même si un attaquant efface les journaux localement, les preuves ont déjà été préservées hors système et ne peuvent pas être falsifiées.```
hacksudo-thor-pentest/
│
├── README.md
├── report.pdf ← Full penetration testing report
│
├── scripts/
│ ├── pfsense_brute.py ← CSRF-aware pfSense brute force script
│ └── thor_full_chain.py ← Metasploit RPC attack chain automation
│
└── screenshots/
├── network.PNG
│
├── Discovery/
│ └── pfsenselogin.png
│
└── exploit/
├── sheellockexploit.PNG
├── sudol.PNG
├── hammer.bash-i.PNG
├── privilage escaltiontoroot.PNG
├── proof.PNG
└── backdoor.PNG
Ce test de pénétration a été réalisé exclusivement dans un environnement de laboratoire virtuel autonome et isolé construit sur Oracle VirtualBox. HackSudo Thor est une machine CTF intentionnellement vulnérable publiée sur VulnHub dans le but explicite de formation et de pratique en sécurité.
| Champ | Détail |
|---|
| Cible | HackSudo Thor |
| Auteur | Vishal Waghmare (@hacksudo) |
| Date de sortie | 3 août 2021 |
| Difficulté | Facile à Moyen |
| OS | Linux (Debian) |
| Format | VirtualBox OVA |
| DHCP | Activé |
| Surface d'attaque prévue | HTTP, SSH, mauvaise config de sudo probable |
| Adresse IP | Services clés | OS | Identifié comme |
|---|
| 10.0.4.3 | SSH 7.9p1, Apache 2.4.38, FTP | Linux (Debian) | HackSudo Thor |
| 10.0.4.4 | Apache 2.4.29, DVWA v1.10 | Linux (Ubuntu) | DVWA |
| 10.0.3.4 | Microsoft IIS 5.1 | Windows XP/2003 | WinXP Cyberlab |
| 10.0.3.5 | vsftpd 2.3.4, SSH, Apache 2.2.8 | Linux (Ubuntu) | Metasploitable 2 |
| Sévérité | Résultat | CVE | CVSS v3 |
|---|
| CRITIQUE | Shellshock RCE | CVE-2014-6271 | 9.8 |
| CRITIQUE | Correction incomplète de Shellshock | CVE-2014-6278 | 8.8 |
| MOYEN | Faiblesse SSH Terrapin | CVE-2023-48795 | 5.9 |
| MOYEN | Répertoires web navigables | — | 5.3 |
| MOYEN | Clickjacking / Pas d'en-tête X-Frame-Options | CWE-693 | 4.3 |
| FAIBLE | Divulgation d'horodatage ICMP | CVE-1999-0524 | 2.1 |