Príbeh o prieskume a vývoji v 3 častiach. Časť 1 — prieskum.
Mnoho písmen — ešte viac užitočnosti.
Stanovenie úlohy
Počas realizácie penetračných testov a kampaní Red Team nie je vždy možné využiť štandardné prostriedky zákazníkov, ako sú VPN, RDP, Citrix atď., na zabezpečenie prístupu do interných sietí. Niekde štandardný VPN funguje pomocou MFA a ako druhý faktor sa používa hardvérový token, inde je prísne monitorovaný a náš prístup cez VPN sa okamžite sprístupní, ako sa hovorí — so všetkými následkami, a niekde také prostriedky jednoducho neexistujú.
V takýchto prípadoch je nevyhnutné neustále vytvárať tzv. „spätné tunely“ — spojenia z vnútornej siete na externý zdroj alebo na server pod našou kontrolou. V rámci takého tunela už môžeme pracovať s internými prostriedkami zákazníkov.
Existuje niekoľko druhov takýchto spätných tunelov. Najznámejším z nich je samozrejme Meterpreter. Taktiež sú veľmi populárne SSH tunely so spätným presmerovaním portov. Existuje mnoho prostriedkov na realizáciu spätného tunelovania a mnohé z nich sú dobre preštudované a popísané.
Samozrejme, vývojári ochranných riešení neostávajú pozadu a aktívne detegujú takéto činnosti.
Napríklad, MSF relácie sú úspešne detegované modernými IPS od Cisco alebo Positive Tech, zatiaľ čo spätný SSH tunel dokáže detegovať prakticky každý normálny firewall.
Preto, aby sme zostali bez povšimnutia v dobrej Red Team kampani — musíme budovať spätný tunel pomocou netradičných prostriedkov a čo najviac sa prispôsobiť skutočnému režimu práce siete.
Skúsme nájsť alebo vymyslieť niečo podobné.
Predtým, než niečo vymyslíme, musíme pochopiť, akého výsledku chceme dosiahnuť, aké funkcie by mala naša aplikácia vykonávať. Aké budú požiadavky na tunel, aby sme mohli pracovať v režime maximálnej skrytosti?
Je jasné, že pre každý prípad sa môžu takéto požiadavky výrazne líšiť, ale na základe pracovných skúseností môžeme vyzdvihnúť základné:
- práca na OS Windows 7-10. Keďže väčšina korporátnych sietí používa práve Windows;
- klient sa pripojuje na server cez SSL, aby sa predišlo pasívnemu odpočúvaniu prostredníctvom IPS;
- pri pripojení musí klient podporovať prácu cez proxy server s autentifikáciou, pretože vo viacerých spoločnostiach sa prístup na internet vykonáva cez proxy. V skutočnosti klientský počítač o tom ani nemusí vedieť a proxy sa používa v priesvitnom režime. Takúto funkčnosť však musíme zahrnúť;
- klientská časť by mala byť stručná a prenosná;
Je jasné, že na prácu vnútri siete Zákazníka je možné na klientskom počítači nainštalovať OpenVPN a vytvoriť plnohodnotný tunel k svojmu serveru (našťastie klienti openvpn dokážu pracovať cez proxy). Avšak, po prvé, to nie vždy bude možné, keďže nemusíme byť lokálnymi administrátormi, a po druhé, to spôsobí toľko hluku, že poriadny SIEM alebo HIPS nás okamžite nahlási. Ideálne by bolo, aby náš klient fungoval ako takzvaný inline tím, ako je to implementované v mnohých bash shelloch, a spúšťal sa cez príkazový riadok, napríklad pri vykonávaní príkazov z word makra. - náš tunel by mal byť viacvláknový a podporovať viacero pripojení súčasne;
- pripojenie klient-server by malo mať nejakú autentifikáciu, aby tunel bol nastavený iba pre nášho klienta a nie pre všetkých, ktorí sa k nám pripoja na server na zadanú adresu a port. Ideálne by pre 'cudzie používateľov' mala otvoriť vstupná stránka so zvieratkami alebo odbornou témou súvisiacou s pôvodnou doménou.
Napríklad, ak je Zákazníkom zdravotná organizácia, pre administrátora informačnej bezpečnosti, ktorý sa rozhodol skontrolovať zdroj, na ktorý sa pracovník kliniky odvolával, by mala otvoriť stránka s farmaceutickými produktmi, Wikipedia s opisom diagnózy alebo blog doktora Komarovského a pod.
Analýza existujúcich nástrojov
Predtým, ako vynájdeme svoj vlastný bicykel, je potrebné analyzovať existujúce bicykle a zistiť, či to naozaj potrebujeme a pravdepodobne sme nie sme jediní, kto uvažuje o potrebe takého funkčného bicykla.
Hľadanie na internete (zdá sa, že hľadáme normálne), ako aj vyhľadávanie na GitHub podľa kľúčových slov „reverse socks“ neprinieslo veľa výsledkov. V podstate to všetko súvisí s vytváraním SSH tunelov s reverzním port forwardingom a všetkým, čo s tým súvisí. Okrem SSH tunelov môžeme vyzdvihnúť niekoľko riešení:
Dlhodobá implementácia reverzného tunelu od chlapcov z Kaspersky Lab. Z názvu je jasné, na čo je tento skript určený. Implementované v Pythone 2.7, tunel funguje v cleartext režime (ako sa teraz hovorí — pozdravujte RKN)
Ďalšia implementácia v Pythone, taktiež v cleartext, ale s viacerými možnosťami. Napísané vo forme modulu s API na integráciu riešení do vlastných projektov.
Prvý odkaz — pôvodná verzia implementácie reverzného socksa v Golangu (nie je podporovaná vývojárom).
Druhý odkaz — už naša úprava s ďalšími funkciami, taktiež v Golangu. V našej verzii sme implementovali SSL, prácu cez proxy s NTLM autorizáciou, autorizáciu na klientovi, vstupnú stránku pri nesprávnom hesle (skôr — presmerovanie na vstupnú stránku), viaceré vlákna (t.j. s tunelom môžu pracovať viacerí ľudia súčasne), systém pingovania klienta, aby sa zistilo, či je nažive alebo nie.
Implementácia reverzného socksa od našich „čínskych priateľov“ v Pythone. Tam sa nachádza aj hotový binárny súbor (exe), ktorý vytvorili Číňania a je určený na použitie. Tu len čínsky boh vie, čo môže v tomto binári byť okrem hlavnej funkčnosti, takže používajte na vlastné riziko.
Celkom zaujímavý projekt v C++ na implementáciu reverzného socksa a nielen toho. Okrem reverzného tunela môže robiť aj port forwarding, vytvárať príkazové shell a podobne.
MSF meterpreter
Tu, ako sa hovorí, bez komentára. Všetci aspoň trošku vzdelaní hackeri sú s touto vecou dôverne oboznámení a chápu, ako ľahko ju prostriedky ochrany objavia.
Všetky vyššie uvedené nástroje fungujú na podobnej technológii: na počítači v sieti sa spúšťa vopred pripravený spustiteľný binárny modul, ktorý nadväzuje spojenie s vonkajším serverom. Na serveri sa spúšťa SOCKS4/5 server, ktorý prijíma pripojenia a prenáša ich na klienta.
Nevýhodou všetkých vyššie uvedených nástrojov je, že buď je na klientskom počítači potrebný nainštalovaný Python alebo Golang (koľko ste už videli počítačov s nainštalovaným Pythonom, napríklad u riaditeľa firmy alebo kancelárskych pracovníkov?), alebo je potrebné preniesť vopred zostavený binárny súbor (v skutočnosti python a skript v jednom balení) a spustiť tento binárny súbor tam. A sťahovanie exe s následným spustením je pre miestny antivírus alebo HIPS výnimočný podpis.
Celkovo sa ponúka jasný záver — potrebujeme riešenie na powershell. Teraz na nás budú hádzať paradajky — že powershell je už všetko známe, monitoruje sa, blokuje a tak ďalej. V skutočnosti — nie všade. Zodpovedne prehlásime. Mimochodom, existuje množstvo spôsobov, ako obísť blokovania (tu opäť populárna fráza o zdraví RKN 🙂), od jednoduchého premenovania powershell.exe na cmdd.exe až po powerdll a podobne.
Začneme vymýšľať
Je jasné, že najskôr sa pozrieme na Google a... nenájdeme nič konkrétne na túto tému (ak niekto niečo našiel — pošlite odkazy do komentárov). Je tu len Socks5 na powershell, ale to je obyčajný "priamy" socks, ktorý má rad svojich nevýhod (o ktorých si povieme neskôr). Môžeme to samozrejme jedným pohybom ruky premeniť na spätný, ale to bude len jednovláknový socks, čo pre nás nie je úplne to, čo potrebujeme.
Takže, nič pripraveného sme nenašli, preto sa budeme musieť predsa len vymyslieť svoj vlastný bicykel. Základ našich bicyklov vezmeme spätnú socksá na golang, a klienta k nemu realizujeme na powershell.
RSocksTun
Takže, ako funguje rsockstun?
Na praxi RsocksTun (ďalej len — rs) sú založené dva softvérové komponenty — Yamux a Socks5 server. Socks5 server je obyčajný lokálny socks5, spúšťa sa na klientovi. A multiplexovanie spojení k nemu (pamätáte na viacvláknovosť?) zabezpečuje yamux (). Tento systém umožňuje spúšťať niekoľko klientských socks5 serverov a rozdeľovať externé pripojenia k nim, prenášajúc ich cez jedno jediné TCP spojenie (takmer ako v meterprepteri) od klienta k serveru, čím sa implementuje viacvláknový režim, bez ktorého jednoducho nemôžeme plnohodnotne pracovať vo vnútornej sieti.
Základná funkcionalita yamuxu spočíva v tom, že zavádza ďalšiu sieťovú vrstvu streamov, ktorá je realizovaná ako 12-bajtová hlavička pre každý paket. (Tu úmyselne používame slovo „stream“, a nie prúd, aby sme nezamieňali čitateľa so softvérovým prúdom „thread“ — toto pojatie taktiež použijeme v tomto článku). Vnútri hlavičky yamuxu sú číslo streamu, flagy na nastavenie/ukončenie streamu, počet prenášaných bajtov a veľkosť prenosového okna.
Okrem nastavenia/ukončenia streamu yamux realizuje aj mechanizmus keepalive, ktorý umožňuje sledovať funkčnosť zriadeného komunikačného kanála. Fungovanie mechanizmu keepalive správ sa nastavuje pri vytváraní Yamux relácie. V podstate sú tam len dva parametre: povoliť/zakázať a periodicita odosielania paketov v sekundách. Keepalive správy môže odosielať ako yamux server, tak aj yamux klient. Po prijatí keepalive správy je vzdialená strana povinná odpovedať presne tou istou identifikačnou správou (v podstate — číslom), ktorú prijala. V zásade keepalive je to ten istý ping, iba pre yamux.
Podrobne sú všetky techniky fungovania multiplexeru: typy paketov, flagy na nastavenie a ukončenie spojení, mechanizmus prenosu dát popísané v k yamuxu.
Záver prvej časti
Takže v prvej časti článku sme sa oboznámili s niektorými nástrojmi na organizáciu reverzných tunelov, pozreli sme sa na ich výhody a nevýhody, preskúmali sme mechanizmus fungovania Yamux multiplexeru a opísali hlavnú požiadavku na novo vytváraný powershell modul. V ďalšej časti sa zameriame na vývoj samotného modulu prakticky od nuly. Pokračovanie nasleduje. Neprelaďte sa 🙂
Zdroj: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish