Spectra

Úvod a kontext

Spectra stojí na kombinaci dvou častých provozních chyb: zapomenuté vývojové artefakty ve webrootu a příliš široká práva kolem interních servisních jobů. Webová část je postavená na WordPressu a zásadní zlom přijde ve chvíli, kdy veřejně dostupný záložní soubor prozradí databázové heslo. To dobře zapadá do vzorce popsaného v článku Password reuse a rozpad hranic mezi aplikací, SSH, WinRM a admin nástroji.

Druhá polovina stroje je ještě zajímavější. Root nevzniká ze stejné WordPress chyby, ale z toho, že uživatel katie smí přes sudo ovládat initctl, zatímco definice testovacích jobů jsou zapisovatelné skupinou developers. To je typická kombinace, která sama o sobě nemusí vypadat dramaticky, ale dohromady znamená spuštění vlastního kódu jako root.

Počáteční průzkum

Vyhledání otevřených portů

Nejdřív mapuji dostupné služby a ověřuji, jestli jde o čistě webový stroj, nebo zda má i další vstupní body.

ports=$(nmap -p- --min-rate=1000 -T4 $IP | grep ^[0-9] | cut -d "/" -f 1 | tr "\n" "," | sed s/,$//);echo $ports;nmap -p $ports -A -sC -sV -v $IP

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.1
80/tcp   open  http    nginx 1.17.4
3306/tcp open  mysql   MySQL (unauthorized)

SSH a MySQL jsou užitečné hlavně pro pozdější pivot. Pro první vstup je rozhodující web.

Dvě WordPress instance

Web ukazoval dvě cesty:

• http://spectra.htb/main/
• http://spectra.htb/testing/

Jakmile vedle produkčního webu existuje ještě testing, má smysl obě větve projít zvlášť. Vývojová nebo testovací instance bývá méně udržovaná a často obsahuje záložní soubory.

Analýza zjištění

Veřejný wp-config.php.save

Rozhodující stopou byl záložní konfigurační soubor v testovací instanci:

view-source:http://spectra.htb/testing/wp-config.php.save

define( 'DB_NAME', 'dev' );
define( 'DB_USER', 'devtest' );
define( 'DB_PASSWORD', 'devteam01' );

Takový soubor je nebezpečný hned dvakrát:

• prozrazuje strukturu aplikace a potvrzuje WordPress,
• poskytuje heslo, které bývá v malých prostředích často znovu použité i jinde.

Přihlášení do /main/wp-admin/

V tomto případě se reuse opravdu potvrdil. Heslo devteam01 fungovalo i pro účet administrator v hlavní instanci:

http://spectra.htb/main/wp-admin/
administrator / devteam01

Jakmile je k dispozici administrace WordPressu, nejde už jen o přístup do CMS. Administrátor může měnit pluginy nebo šablony a tím spouštět vlastní PHP kód na serveru.

Získání přístupu

Shell z WordPress administrace

Nejjednodušší cesta vedla přes úpravu pluginu nebo PHP šablony a její následnou aktivaci. Tím vznikl shell v kontextu webového uživatele.

Po footholdu stálo za to projít lokální konfigurace. Zajímavé byly hlavně dva artefakty:

/** MySQL database username */
define( 'DB_USER', 'dev' );

/** MySQL database password */
define( 'DB_PASSWORD', 'development01' );

a také:

cat /etc/autologin/passwd
SummerHereWeCome!!

Právě heslo z autologinu mělo vyšší praktickou hodnotu než databázová hesla, protože otevřelo SSH účet katie:

ssh katie@10.10.10.229

SummerHereWeCome!!

Tím se z webového footholdu stal stabilní shell v běžném uživatelském kontextu. User flag šlo pak potvrdit standardně:

cat user.txt

__CENSORED__

Eskalace oprávnění

initctl a writable test jobs

První důležitý výstup lokální enumerace byl:

sudo -l

User katie may run the following commands on spectra:
    (ALL) SETENV: NOPASSWD: /sbin/initctl

initctl samo o sobě ještě root nedává. Rozhodující bylo až to, že v /etc/init/ existovaly testovací joby, které spouštěly Node.js skript /srv/nodetest.js, a soubory kolem tohoto workflow byly zapisovatelné skupinou developers, jejímž členem katie byla. Právě to je typický příklad pro článek Zápis do prostoru, který se pak vykoná nebo použije pro autentizaci.

To vytváří jasný privesc řetězec:

• upravit obsah jobu nebo skriptu, který se má spustit,
• použít sudo /sbin/initctl start ...,
• nechat roota spustit vlastní payload.

Jedna z nejjednodušších variant je upravit job tak, aby nastavil SUID bit na /bin/bash:

script
    chmod +s /bin/bash
end script

Pak už stačí službu spustit:

sudo /sbin/initctl start test
/bin/bash -p

Tím vznikne root shell a následně i přístup k root.txt.

Shrnutí klíčových poznatků

• Testovací WordPress instance byla cennější než produkční web, protože v ní zůstal veřejně dostupný záložní wp-config.php.save.
• Přihlašovací údaje z vývojové části se znovu použily v administraci produkční instance a následně i v dalších lokálních mechanismech.
• Root část nevznikla z nové CVE, ale z kombinace sudo práva na initctl a zapisovatelného servisního jobu, který běžel jako root.

Co si odnést do praxe

• Záložní soubory typu .save, .bak nebo staré exporty konfigurace musí být z webrootu odstraněné stejně důsledně jako samotná zranitelná aplikace. Často prozradí víc než celý scan.
• Produkční a testovací instance nesmí sdílet stejné účty a hesla. Jinak se chyba v méně důležitém prostředí automaticky mění v kompromitaci produkce.
• sudo právo ovládat init nebo service manager je vysoce citlivé. Pokud útočník zároveň dokáže upravit definici jobu nebo skript, je to v praxi přímý root.

Další související články

HTB Stroje

• Traceback
• Time
• TheNotebook

Techniky

• PATH, PYTHONPATH a wrapper hijack
• Document workflow jako RCE nebo file-read primitivum
• `sudo` nad package, backup a container nástroji

Nástroje

• linpeas