Wall
Úvod a kontext
Wall začíná poměrně obyčejně: admin rozhraní Centreon na slabém hesle. Zajímavost ale spočívá v tom, že první shell jako www-data ještě nestačí ani na user flag. Skutečný uživatelský účet se otevírá až díky skrytému Python bytecode souboru, který v sobě nese heslo pro shelby. Tím se tenhle stroj dobře potkává s články Monitoring, observability a admin platformy jako útoková plocha a Klientské, desktopové a ne-textové artefakty po footholdu.
Root část je pak starší, ale velmi poučná. Na hostu je SUID screen-4.5.0, tedy verze známá z privesců přes ld.so.preload. Stroj tak hezky ukazuje dvě různé disciplíny: nejdřív čtení lokálních artefaktů a reuse hesel, potom audit neobvyklých SUID binárek, tedy přesně téma SUID/GTFOBins a netypické binárky.
Počáteční průzkum
Vyhledání otevřených portů
Nejdřív mapuji veřejné služby:
nmap -p 1-65535 -T4 -A -sC -v $IP
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
Webová enumerace odhalila dvě relevantní cesty:
/monitoring
/centreon/
/monitoring vracel basic auth a /centreon/ odpovídal monitorovacímu rozhraní Centreon.
Analýza zjištění
Slabé heslo do Centreon
Místo slepého brute force proti formuláři dával větší smysl Centreon API endpoint pro autentizaci. Přes hydra nebo jednoduchou smyčku se podařilo najít heslo; praktickou logiku tohohle typu ověření rozebírám i v článku Hydra:
hydra -v -l admin -P /usr/share/wordlists/metasploit/unix_passwords.txt 10.10.10.157 http-post-form "/centreon/api/index.php?action=authenticate:username=^USER^&password=^PASS^:S=authToken"
admin / password1
To je důležitý mezikrok. Nejde o webovou zranitelnost v užším smyslu, ale o slabou správu identit v nástroji, který má sám vysoká oprávnění a umí spouštět příkazy.
RCE přes Centreon
S přístupem do Centreon už šlo využít známý authenticated RCE exploit. Ten vytvoří nebo upraví check tak, aby na serveru spustil útočníkův příkaz.
Výsledkem byl reverzní shell jako www-data.
Získání přístupu
Z www-data na shelby
Po shellu jako www-data bylo vidět, že user.txt leží v /home/shelby, ale tento účet ještě nebyl kompromitovaný. Rozhodující lokální stopa byla skrytá složka:
/opt/.shelby
Uvnitř byl bytecode soubor backup, který šel dekompilovat pomocí uncompyle6. Dekompilovaný kód obsahoval heslo skládané znak po znaku:
password += chr(ord('S'))
password += chr(ord('h'))
...
password += chr(ord('!'))
Po složení vyšlo:
ShelbyPassw@rdIsStrong!
To otevřelo SSH přístup:
ssh shelby@10.10.10.157
A následně i user flag:
cat user.txt
__CENSORED__
Eskalace oprávnění
SUID screen-4.5.0
Lokální enumerace jako shelby ukázala neobvyklý SUID binární soubor:
/bin/screen-4.5.0
To je zásadní, protože starší screen verze jsou známé privescy přes manipulaci s ld.so.preload. Smysl této části není vymýšlet nový exploit, ale rozpoznat starý a stále použitelný lokální vektor.
Prakticky stačilo použít veřejně známý screenroot postup, který:
- připraví škodlivou knihovnu,
- donutí
screenvytvořit/etc/ld.so.preload, - a následně spustí root shell nebo SUID helper.
Po spuštění exploitu vznikl root shell a bylo možné přečíst root.txt.
Shrnutí klíčových poznatků
- První foothold zde nezačínal sofistikovanou webovou chybou, ale slabým heslem do Centreon administrace.
- Shell jako
www-dataještě neznamenal uživatelský přístup. Ten otevřel až lokální artefaktbackups obfuskovaným heslem proshelby. - Root část stála na staré SUID verzi
screen, nikoli na další chybě v Centreon nebo Apache.
Co si odnést do praxe
- Monitorovací platformy jako Centreon musí mít tvrdě spravované přístupy. Slabé heslo zde neotevírá jen dashboard, ale často i možnost vzdáleně spouštět příkazy.
- Kompilovaný nebo bytecode artefakt v systému je potřeba po footholdu brát stejně vážně jako plaintext konfigurační soubor. Obfuskované heslo není bezpečnostní kontrola.
- Při lokální enumeraci je potřeba věnovat mimořádnou pozornost netypickým SUID binárkám. Staré verze
screen,exim,pkexeca podobných nástrojů často znamenají rychlejší root než hledání kernel bugu.
Další související články
HTB Stroje
Techniky
- Container boundary mistakes: bind mounty, `docker exec`, `runc`, `privileged`
- Údržbové skripty a provozní automaty jako zdroj přístupů
- SUID/GTFOBins a netypické binárky