Příběh o výzkumu a vývoji ve třech částech. Část 1 — výzkumná.
Písmen je mnoho — užitku ještě více.
Formulace úkolu
Během provádění penetračních testů a RedTeam kampaní se vždy nedaří využít standardní prostředky Zákazníků, jako jsou VPN, RDP, Citrix atd., jakožto zajištění přístupu do interní sítě. Někde standardní VPN pracuje s vícefaktorovou autentizací a jako druhý faktor se používá hardwarový token, jinde je monitorováno velmi přísně a náš vstup přes VPN se okamžitě stává viditelným, jak se říká — se všemi důsledky, a jinde taková média jednoduše nejsou.
V takových případech je stále nutné vytvářet tzv. „zpětné tunely“ — spojení z interní sítě k externímu zdroji nebo serveru, který máme pod kontrolou. V rámci takového tunelu již můžeme pracovat s interními zdroji Zákazníků.
Existuje několik variant takových zpětných tunelů. Nejznámější z nich je samozřejmě Meterpreter. Také velkým zájmem v hackerických kruzích se těší SSH tunely s reverzním port forwardingem. Pro provádění zpětného tunelování existuje mnoho prostředků a mnohé z nich jsou dobře prozkoumány a popsány.
Samozřejmě, vývojáři ochranných řešení nezůstávají pozadu a aktivně detekují podobné akce.
Například, MSF sezení jsou úspěšně detekována moderními IPS od Cisco nebo Positive Tech, a zpětný SSH tunel lze detekovat prakticky jakýmkoli normálním firewallem.
Proto, abychom zůstali nepozorováni v dobré RedTeam kampani — musíme budovat zpětný tunel netradičními prostředky a co nejvíce se přizpůsobit skutečnému provozu sítě.
Zkusme najít nebo vymyslet něco podobného.
Než něco vymyslíme, je třeba pochopit, jakého výsledku chceme dosáhnout, jaké funkce by naše vývoj měla vykonávat. Jaké budou požadavky na tunel, abychom mohli pracovat v režimu maximální diskrétnosti?
Je jasné, že pro každý případ se tyto požadavky mohou výrazně lišit, ale z praxe lze vyčlenit hlavní:
- pracovat na OS Windows 7-10. Protože ve většině firemních sítí se používá právě Windows;
- Klient se připojuje k serveru přes SSL, aby se vyloučilo odposlouchávání pomocí IPS;
- Při připojení by klient měl podporovat práci přes proxy server s autorizací, protože ve mnoha firmách se přístup k internetu realizuje přes proxy. Ve skutečnosti o tom může klientský stroj ani nevědět, zatímco proxy se používá v transparentním režimu. Ale tuto funkčnost musíme naplánovat;
- Klientská část by měla být stručná a přenositelná;
Je jasné, že pro práci uvnitř sítě objednatele lze na klientském zařízení nainstalovat OpenVPN a vybudovat plnohodnotný tunel k vlastnímu serveru (naštěstí klienti openvpn umějí pracovat přes proxy). Ale, za prvé, nemusíme být vždy místními administrátory, a za druhé, to udělá tolik hluku, že slušný SIEM nebo HIPS na nás okamžitě „začne tleskat“. Ideálně by náš klient měl být takzvaným inline nástrojem, jak jsou například realizovány mnohé bash shelly, a měl by být spouštěn přes příkazový řádek, např. při vykonávání příkazů z makra v aplikaci Word. - Náš tunel by měl být vícerozměrný a podporovat mnoho současných připojení;
- Připojení klient-server by mělo mít nějakou autorizaci, aby se tunel vytvářel pouze pro našeho klienta, a ne pro všechny, kdo k nám na server přijdou na zadanou adresu a port. Ideálně by pro „externí uživatele“ měla být otevřena landingová stránka s kočkami nebo profesionálním tématem spojeným se zdrojovou doménou.
Například, pokud objednatelem je zdravotnická organizace, pak by se správci informační bezpečnosti, který se rozhodl zkontrolovat zdroj, na který se obracel zaměstnanec kliniky, měla otevřít stránka s farmaceutickými produkty, Wikipedie s popisem diagnózy nebo blog doktora Komarovského atd.
Analýza existujících nástrojů
Než vynalezneme svůj vlastní bicykl — je třeba provést analýzu existujících bicyklů a pochopit, zda je to opravdu potřebné, a pravděpodobně jsme v této potřebě nebyli sami.
Hledání na internetu (vypadá to, že hledáme normálně) a také vyhledávání na GitHubu podle klíčových slov „reverse socks“ nepřineslo příliš mnoho výsledků. Většinou se všechno točí kolem vytváření ssh tunelů s reverzním port forwardingem a všeho, co s tím souvisí. Kromě SSH tunelů lze vyzdvihnout několik řešení:
Starší implementace reverzního tunelu od kluků z Laboratoře Kaspersky. Z názvu je jasné, k čemu je tento skript určen. Implementováno v Pythonu 2.7, tunel funguje v cleartext režimu (jak je dnes moderní říkat — pozdrav RKN).
Další implementace v Pythonu, také v cleartextu, ale s více funkcemi. Napsáno jako modul a existuje API pro integraci řešení do vlastních projektů.
První odkaz — původní verze implementace reverse socks v golangu (není podporována vývojářem).
Druhý odkaz — naše úprava s dalšími funkcemi, také v golangu. V naší verzi jsme implementovali SSL, práci přes proxy s NTLM autorizací, autorizaci na klientovi, vstupní stránku při nesprávném hesle (spíše — přesměrování na vstupní stránku), vícerozměrný režim (tzn. tunel může používat více lidí najednou), systém pingování klienta, aby se zjistilo, zda je živý nebo ne.
Implementace reverzních socks od našich „čínských přátel“ v Pythonu. Tam je také pro lenochy a „nesmrtelné“ již hotový binární soubor (exe), sestavený Číňany a připravený k použití. Tady ví jen čínský bůh, co všechno může být v tomto bináři, kromě základní funkce, takže používejte na vlastní nebezpečí.
Docela zajímavý projekt v C++ pro implementaci reverzních socks a nejen to. Kromě reverzního tunelu může provádět port forwarding, vytváření příkazového shellu atd.
MSF meterpreter
Tady jak se říká, bez komentářů. Všichni vzdělaní hackeři jsou s touto věcí dobře obeznámeni a chápou, jak snadno ji detekují ochranné prostředky.
Všechny výše zmíněné nástroje fungují na podobné technologii: na stroji uvnitř sítě se spustí předem připravený spustitelný binární modul, který vytvoří spojení s externím serverem. Na serveru se spustí SOCKS4/5 server, který přijímá připojení a přenáší je na klienta.
Nevýhodou všech výše uvedených nástrojů je, že buď je na klientském stroji nutné mít nainstalovaný Python nebo Golang (jak často jste potkali nainstalovaný Python na strojích, například ředitele společnosti nebo kancelářských pracovníků?), nebo je třeba na tuto mašinu přenášet předem sestavený binář (v podstatě python a skript v jednom balení) a tento binář tam spustit. A stahování exe a jeho následné spuštění — to už je pro místní antivir nebo HIPS pěkná signatura.
Obecně vzato, závěr se nabízejí sám — potřebujeme řešení na PowerShell. Teď nás začnou bombardovat rajčaty — že PowerShell je už dávno vyčpělý, je sledován, blokován atd. atd. Ve skutečnosti — rozhodně ne všude. Odpovědně prohlašujeme. Mimochodem, existuje spousta způsobů, jak obejít blokace (tady opět moderní fráze o pozdravech RKN 🙂), počínaje jednoduchým přejmenováním powershell.exe na cmdd.exe a konče powerdll a podobně.
Začínáme vymýšlet
Je pochopitelné, že nejprve se podíváme na Google a… nenajdeme vůbec nic na toto téma (pokud někdo našel — pošlete odkazy do komentářů). Existuje jen Socks5 na PowerShell, ale to je běžný "přímý" socks, který má řadu svých nevýhod (o nich si promluvíme později). Samozřejmě, že ho můžeme jednoduchým pohybem ruky přetvořit na reverzní, ale to bude jen jednovláknový socks, což pro nás není přesně to, co potřebujeme.
Takže jsme nic hotového nenašli, a proto si budeme muset vymyslet vlastní kolo. Základ našeho kola vezmeme reverzní socks na Golangu, a klienta k němu realizujeme na PowerShell.
RSocksTun
Jak vlastně funguje rsockstun?
Základní funkcionalita RsocksTun (dále v textu — rs) spočívá ve dvou softwarových komponentách — Yamux a Socks5 server. Socks5 server je běžný lokální socks5, který běží na klientovi. A multiplexování spojení k němu (pamatujete na vícero vláken?) je zajištěno pomocí yamux (). Tato architektura umožňuje spouštět více klientských socks5 serverů a směrovat externí připojení k nim, procházejícím přes jedno jediněTCP spojení (skoro jako v meterpreteru) od klienta k serveru, čímž implementuje vícetrupý režim, bez kterého bychom prostě nemohli řádně pracovat v interní síti.
Podstata fungování yamuxu spočívá v tom, že zavádí dodatečnou síťovou úroveň streamů, realizovanou ve formě 12-bajtové hlavičky pro každý paket. (Zde záměrně používáme slovo „stream“, nikoli tok, abychom nepletli čtenáře s programovým tokem „thread“ — tuto definici budeme také používat v tomto článku). Uvnitř yamux hlavičky se nacházejí číslo streamu, příznaky pro zahájení/ukončení streamu, počet přenášených bytů a velikost přenosového okna.
Kromě zahájení/ukončení streamu yamux implementuje mechanismus keepalive, který umožňuje sledovat funkčnost zavedeného komunikačního kanálu. Fungování mechanismu keepalive zpráv je nastaveno při vytváření Yamux relace. V podstatě tam jsou pouze dvě nastavení: povolit/zakázat a frekvence odesílání paketů v sekundách. Keepalive zprávy může posílat jak yamux server, tak yamux klient. Po přijetí keepalive zprávy je vzdálená strana povinna na ni odpovědět odesláním zprávy se stejným identifikátorem (v podstatě číslem), který přijala. Obecně platí, že keepalive je to samé co ping, pouze pro yamux.
Podrobně veškerá technika fungování multiplexoru: typy paketů, příznaky zahájení a ukončení připojení, mechanismus přenosu dat je popsána v pro yamux.
Závěr první části
Takže v první části článku jsme se seznámili s některými nástroji pro organizaci zpětných tunelů, podívali jsme se na jejich výhody a nevýhody, prozkoumali mechanismus fungování multiplexoru Yamux a popsali základní požadavky na nově vytvářený powershell modul. V další části se pustíme do vývoje samotného modulu, prakticky od nuly. Pokračování příště. Neodcházejte 🙂
Zdroj: habr.com
