Port forwarding, proxy a protokolové mosty jako exploitační primitivum
Úvod a kontext
Port forwarding, proxychains, socat nebo různé reverzní tunely se často popisují jen jako pomocné utility. Něco, co se „hodí navíc“, když už má útočník foothold. V praxi ale bývají mnohem důležitější. Často nejde o komfortní doplněk, ale o samotný bridge krok, bez kterého se útok dál nepohne.
Právě to je smysl tohoto článku. Nejde o seznam nástrojů ani o cheat sheet syntaxe. Jde o rozhodovací logiku: kdy má větší smysl postavit si most k interní službě než dál hledat veřejně dostupnou zranitelnost.
Co z těchto technik dělá skutečný primitiv
Společné mají tři vlastnosti:
- překonávají síťovou nebo transportní hranici,
- mění lokálně dostupnou nebo interní službu na dosažitelný cíl,
- dovolí útočníkovi použít běžné nástroje tam, kde by jinak nefungovaly.
To je důležitý rozdíl proti „obyčejnému tunelu“. Útok se přes ně neposouvá jen technicky. Posouvá se bezpečnostně, protože najednou zpřístupní:
- localhost-only API,
- interní SMTP,
- SSH na neveřejném portu,
- IPv6 službu z IPv4 prostředí,
- nebo administrační službu, která byla schválně schovaná za jinou vrstvu.
Příklad z praxe: ServMon a localhost-only NSClient++
ServMon je nejčistší ukázka toho, proč port forwarding není vedlejší detail. První část řetězce vede přes NVMS-1000 a končí SSH účtem Nadine. To je důležité, ale ještě neřeší root.
Skutečný posun přichází až ve chvíli, kdy je potřeba sáhnout na NSClient++ na portu 8443. Tato služba sice na hostu běží, ale je určená k lokální správě. Bez tunelu by šlo o slepou stopu.
Právě proto byl rozhodující příkaz:
ssh Nadine@$IP -L 8443:127.0.0.1:8443
Najednou se z interního API stane lokálně dosažitelná služba, proti které lze použít běžný curl. Až díky tomu šlo:
- nahrát vlastní skript,
- spustit ho jako check,
- a získat privilegovaný shell.
ServMon ukazuje, že forwarding tady nebyl „pohodlnější přístup“. Byl to samotný exploit bridge mezi běžným uživatelským kontextem a admin API.
Příklad z praxe: Tentacle a proxychains jako cesta k internímu SMTP
Na Tentacle byla situace jiná. Šlo o interní host dostupný jen přes veřejný Squid. Bez mostu přes proxy by OpenSMTPD na druhém segmentu nešlo ani osahat, natož exploitovat.
Tady se bridge stavěl přes:
- veřejný Squid,
proxychains,- a následně exploit spuštěný proti interní adrese.
To je důležité rozlišit. proxychains tady neřeší anonymizaci ani „lepší recon“. Řeší samotnou dosažitelnost cíle. Ve chvíli, kdy nástroj začne brát interní SMTP jako normální síťový endpoint, může útok pokračovat úplně běžným způsobem.
Příklad z praxe: Zetta a most mezi IPv4 a IPv6
Zetta ukazuje třetí variantu: problém není jen v tom, že služba je interní, ale i v tom, že běží na jiné adresní rodině. Po odhalení interní IPv6 adresy a rsync portu bylo potřeba vytvořit most, který dovolí používat standardní rsync klienty z lokální IPv4 strany:
socat TCP4-LISTEN:8730,fork TCP6:[dead:beef::250:56ff:feb9:f660]:8730
To je přesně okamžik, kdy se bridge mění v primitiv. Bez něj by bylo potřeba řešit jiný toolchain, jiné adresování a složitější práci s klientem. Díky mostu se interní IPv6 rsync tváří jako lokální IPv4 služba a další práce probíhá už standardně.
Nejde tedy jen o „tunel pro pohodlí“. Jde o překlad mezi dvěma síťovými realitami.
Příklad z praxe: BigHead a tunel k internímu SSH
BigHead ukazuje ještě jiný typ mostu. Po prvním shellu bylo potřeba dostat se k internímu SSH na portu 2020, které nebylo součástí původního veřejného povrchu. Teprve po tunelování a přihlášení jako nginx bylo možné pohodlně pracovat s lokálními aplikacemi a následně zneužít linkto.php.
To je důležitý vzor:
- první foothold ještě neznamená stabilní pracovní kontext,
- interní služba existuje, ale není přímo dosažitelná,
- tunel z ní udělá normální správní kanál,
- a útok se tím přesune z jednorázového shellem omezeného prostředí do opakovatelného workflow.
Kdy má smysl stavět most místo hledání dalšího exploitu
Prakticky se vyplatí zastavit a přemýšlet o mostu ve chvíli, kdy platí alespoň jedno z toho:
1. Znáš interní službu, ale nevidíš ji zvenku
Typicky:
- localhost-only admin API,
- interní SMTP,
- management port navázaný na jiný interface,
- interní SSH nebo debug endpoint.
2. Máš foothold, ale špatný pracovní kontext
Jednorázová command injection nebo křehký webshell často stačí jen k tomu, aby sis otevřel lepší přístupovou cestu:
- SSH,
- WinRM,
- admin web API,
- interní protokol.
3. Cíl běží v jiné síťové vrstvě nebo na jiném transportu
IPv6, proxy-only cesta, SOCKS most, localhost-only listener nebo jiný síťový segment jsou typické důvody, proč přestat řešit payloady a místo toho řešit dopravu.
Na co se při návrhu mostu zaměřit
Kde přesně je hranice
127.0.0.1,- interní interface,
- IPv6-only listener,
- přístup jen přes proxy,
- nebo služba dostupná jen z kompromitovaného hostu.
Jak moc „věrný“ musí most být
Někdy stačí jednoduché ssh -L. Jindy je potřeba:
- SOCKS přes
proxychains, - reverzní tunel,
- překlad IPv4 <-> IPv6,
- nebo kombinace více kroků.
Klíčová není značka nástroje, ale to, jak dobře odpovídá dopravnímu problému.
Co se po mostu otevře
Most sám o sobě není cíl. Důležitá je služba za ním. Proto má smysl stavět ho hlavně tehdy, když za ním čeká:
- silnější admin funkce,
- privilegované API,
- stabilnější shell,
- nebo jiný útokový krok, který jinak nejde provést.
Rozdíl proti blízkým tématům
Není to článek o síťové topologii jako leaku
Tam řešíš, jak se vůbec dozvíš, že interní služba existuje. Tady řešíš, jakmile už to víš, jak si k ní postavit funkční cestu.
Není to článek o localhost službách
Lokálně dostupné služby po footholdu řeší, co na localhostu hledat. Tento text řeší, jak si k nim nebo k jiným interním službám vytvořit dopravní vrstvu, která dovolí normální práci.
Není to toolbox článek
Smyslem není vyjmenovat chisel, socat, plink, ssh -L a proxychains. Smyslem je naučit čtenáře, kdy má most vyšší hodnotu než další enumerace veřejného povrchu.
Obrana a hardening
1. Nezaměňovat localhost za bezpečnostní hranici
ServMon ukazuje, že jakmile útočník získá běžný účet, localhost-only API je jen o jednu vrstvu tunelování dál.
2. Omezit laterální použitelnost interních služeb
Interní admin API, debug endpointy a management porty musí počítat i s kompromitovaným lokálním účtem. Nestačí je jen schovat za jiný interface.
3. Hlídát proxy a mosty jako bezpečnostní událost
Neočekávané lokální forwardy, reverzní tunely nebo bridge procesy typu socat bývají velmi silný indikátor post-exploitation práce.
4. Segmentaci navrhovat i proti kompromitovanému hostu
Pokud interní služba důvěřuje všemu, co přijde z lokálního hostu nebo z interní sítě, tunel z obyčejného footholdu udělá plnohodnotný administrační kanál.
5. Monitoring držet na úrovni dopravního vzoru, ne jen procesu
Jeden útočník použije ssh -L, jiný socat, další agent s reverzním tunelem. Důležitější než konkrétní binárka je to, že host začíná fungovat jako most do jiné zóny.
Shrnutí klíčových poznatků
- Port forwarding, proxy a protokolové mosty nejsou jen pomocné utility. Často tvoří samotný bridge krok, bez kterého útok dál nepokračuje.
- ServMon ukazuje localhost-only admin API, Tentacle proxy-only přístup k internímu SMTP, Zetta překlad mezi IPv4 a IPv6 a BigHead přechod k internímu SSH.
- Rozhodující není značka nástroje, ale to, že most změní jinak nedosažitelnou službu na normálně použitelný cíl.
- Obrana musí počítat s tím, že kompromitovaný host se velmi rychle může změnit v dopravní uzel do dalších zón důvěry.
Co si odnést do praxe
- Když po footholdu narazíš na interní službu, neptej se hned „jak ji exploituju“. Nejdřív se ptej, jak si k ní postavím spolehlivou cestu.
- Most má smysl tehdy, když za ním čeká lepší kontext: admin API, stabilnější shell nebo jiný privilegovaný kanál.
- Pokud obrana spoléhá na to, že služba je „jen na localhostu“ nebo „jen v interní síti“, forwarding a bridge techniky tuto hranici velmi rychle zruší.