Egy történet a kutatásról és fejlesztésről 3 részben. Az 1. rész feltáró jellegű.
Sok bükkfa van – még több előny.
Probléma nyilatkozat
A pentesztek és RedTeam kampányok során nem mindig lehetséges az Ügyfél szabványos eszközeinek használata, mint a VPN, RDP, Citrix stb. horgonyként a belső hálózatba való belépéshez. Egyes helyeken a szabványos VPN MFA-val működik, és a hardveres token a második tényező, máshol brutálisan figyelik, és azonnal láthatóvá válik a VPN-bejelentkezésünk, ahogy mondani szokás, mindazzal, ami vele jár, de máshol vannak ilyenek. egyszerűen nincs ilyen eszköz.
Ilyenkor állandóan úgynevezett „fordított alagutak”-t kell kialakítanunk – a belső hálózatról egy külső erőforrásra vagy egy általunk irányított szerverre kapcsolódunk. Egy ilyen alagútban már dolgozhatunk az Ügyfél belső erőforrásaival.
Ezeknek a visszatérő alagutaknak többféle változata létezik. A leghíresebb közülük természetesen a Meterpreter. A fordított porttovábbítással rendelkező SSH-alagutak szintén nagy keresletet mutatnak a hackerek körében. Elég sok eszköz létezik a fordított alagút megvalósítására, és sok közülük alaposan tanulmányozott és leírt.
Természetesen a biztonsági megoldások fejlesztői a maguk részéről nem állnak félre, és aktívan észlelik az ilyen tevékenységeket.
Például az MSF-munkameneteket a Cisco vagy a Positive Tech modern IPS-je sikeresen észleli, a fordított SSH-alagutat pedig szinte bármilyen normál tűzfal észlelheti.
Ezért ahhoz, hogy észrevétlenek maradjunk egy jó RedTeam kampányban, egy fordított alagutat kell építenünk nem szabványos eszközökkel, és a lehető legjobban alkalmazkodnunk kell a hálózat valós működési módjához.
Próbáljunk meg valami hasonlót találni vagy kitalálni.
Mielőtt bármit is kitalálnánk, meg kell értenünk, milyen eredményt szeretnénk elérni, milyen funkciókat kell betöltenie a fejlesztésünknek. Milyen követelmények lesznek az alagúttal szemben, hogy maximálisan lopakodó üzemmódban tudjunk dolgozni?
Nyilvánvaló, hogy az ilyen követelmények minden esetben nagyon eltérőek lehetnek, de a munkatapasztalat alapján a főbbek azonosíthatók:
- Windows-7-10 operációs rendszeren működik. Mivel a legtöbb vállalati hálózat Windowst használ;
- a kliens SSL-en keresztül csatlakozik a szerverhez, hogy elkerülje az ips használatával való hülye hallgatást;
- Csatlakozáskor a kliensnek támogatnia kell a proxyszerveren keresztüli munkát jogosultsággal, mert Sok vállalatnál az internethez való hozzáférés proxyn keresztül történik. Valójában a kliens gép nem is tud róla semmit, és a proxyt transzparens módban használják. De biztosítanunk kell ezt a funkciót;
- a kliens rész legyen tömör és hordozható;
Nyilvánvaló, hogy az Ügyfél hálózatán belüli munkához telepítheti az OpenVPN-t a kliens gépére, és létrehozhat egy teljes értékű alagutat a szerveréhez (szerencsére az openvpn kliensek proxyn keresztül is működhetnek). De egyrészt ez nem mindig fog működni, hiszen ott nem biztos, hogy helyi adminok vagyunk, másrészt akkora zajt fog csapni, hogy egy tisztességes SIEM vagy HIPS azonnal „rácsap” ránk. Ideális esetben a kliensünk egy úgynevezett inline parancs legyen, mivel például sok bash shell implementálva van, és a parancssoron keresztül indul el, például egy szómakró parancsainak végrehajtásakor. - alagútunknak többszálasnak kell lennie, és egyszerre több kapcsolatot is támogatnia kell;
- a kliens-szerver kapcsolatnak rendelkeznie kell valamilyen jogosultsággal, hogy az alagút csak a kliensünk számára jöjjön létre, és ne mindenki számára, aki a megadott címen és porton érkezik a szerverünkre. Ideális esetben az eredeti domainhez kapcsolódó macskákat vagy szakmai témákat tartalmazó nyitóoldal megnyílik a „harmadik fél felhasználók számára”.
Például, ha az Ügyfél egészségügyi szervezet, akkor egy információbiztonsági adminisztrátornak, aki úgy dönt, hogy ellenőrzi az erőforrást, amelyhez a klinika alkalmazottja hozzáfért, egy gyógyszerészeti termékeket tartalmazó oldalt, a Wikipédiát a diagnózis leírásával, vagy Dr. Komarovsky blogját stb. ki kell nyílnia.
Meglévő eszközök elemzése
Mielőtt újra feltalálná saját kerékpárját, elemeznie kell a meglévő kerékpárokat, és meg kell értenie, hogy valóban szükségünk van-e rá, és valószínűleg nem mi vagyunk az egyetlenek, akik elgondolkodtak egy ilyen funkcionális kerékpár szükségességén.
Az internetes guglizás (úgy tűnik, hogy normálisan guglizunk), valamint a Githubon a „fordított zokni” kulcsszavakkal való keresés nem hozott sok eredményt. Alapvetően minden az ssh alagutak építésén múlik, fordított porttovábbítással és minden, ami ehhez kapcsolódik. Az SSH alagutakon kívül számos megoldás létezik:
A fordított alagút hosszú távú megvalósítása a Kaspersky Lab srácaitól. A névből világosan kiderül, mire való ez a szkript. A Python 2.7-ben megvalósított alagút tiszta szöveges módban működik (ahogy most divatos mondani - hello RKN)
Egy másik megvalósítás Pythonban, szintén tiszta szövegben, de több lehetőséggel. Modulként íródott, és rendelkezik egy API-val a megoldás projektekbe való integrálásához.
Az első hivatkozás a reverse sox implementáció eredeti verziója a Golang nyelven (a fejlesztő nem támogatja).
A második link a mi változatunk további funkciókkal, szintén Golang nyelven. Változatunkban az SSL-t implementáltuk, proxy-n keresztül dolgozunk NTLM jogosultsággal, engedélyezés a kliensen, céloldal hibás jelszó esetén (vagy inkább átirányítás a céloldalra), többszálas mód (vagyis több ember) egyidejűleg dolgozhat az alagúttal) , egy rendszer, amely pingeli az ügyfelet annak megállapítására, hogy életben van-e vagy sem.
A fordított sox megvalósítása „kínai barátainktól” Pythonban. Ott a lusták és „halhatatlanok” számára van egy kész bináris (exe), amelyet a kínaiak szereltek össze és használatra kész. Itt csak a kínai Isten tudja, hogy a fő funkcionalitáson kívül mit tartalmazhat még ez a bináris, ezért használja saját veszélyére és kockázatára.
Elég érdekes projekt C++ nyelven a reverse sox és egyebek megvalósításához. A fordított alagúton kívül képes port továbbításra, parancshéj létrehozására stb.
MSF mérőmérő
Itt, ahogy mondják, nincs hozzászólás. Minden, még jobban vagy kevésbé képzett hacker nagyon jól ismeri ezt a dolgot, és megérti, milyen könnyen észlelhetők a biztonsági eszközök.
A fent leírt eszközök mindegyike hasonló technológiával működik: a hálózaton belüli gépen elindul egy előre elkészített futtatható bináris modul, amely kapcsolatot létesít egy külső szerverrel. A kiszolgáló egy SOCKS4/5 kiszolgálót futtat, amely fogadja a kapcsolatokat és továbbítja azokat a kliensnek.
A fenti eszközök mindegyikének az a hátránya, hogy vagy a Pythont vagy a Golangot kell telepíteni a kliens gépre (gyakran láttál már Python-t pl. egy cégigazgató vagy irodai dolgozók gépére telepíteni?), vagy egy előre összeszerelt binárist (valójában a pythont) erre a gépre kell ráhúzni, és egy palackban szkriptet kell készíteni), és már ott kell futtatni ezt a binárist. És egy exe letöltése, majd elindítása is egy helyi vírusirtó vagy HIPS aláírása.
Általában a következtetés önmagát sugallja – szükségünk van egy powershell megoldásra. Most a paradicsom repül majd ránk – azt mondják, hogy a powershell már teljesen fel van hakni, figyelik, blokkolják stb. stb. Valójában nem mindenhol. Felelősséggel nyilatkozunk. Amúgy a blokkolás megkerülésére nagyon sok mód van (itt megint egy divatos mondat a hello RKN-ről 🙂), kezdve a powershell.exe -> cmdd.exe hülye átnevezésével és a powerdll-lel bezárólag, stb.
Kezdjük a feltalálást
Egyértelmű, hogy először a Google-n nézünk, és… nem találunk semmit ebben a témában (ha valaki megtalálta, tegye meg a linkeket a megjegyzésekben). Csak van Socks5 a powershell-en, de ez egy közönséges „direkt” sox, amelynek számos saját hátránya van (ezekről később beszélünk). Természetesen egy enyhe kézmozdulattal fordítva is lehet fordítani, de ez csak egyszálú sox lesz, ami nekünk nem egészen kell.
Tehát nem találtunk semmit készen, így még mindig fel kell találnunk a kerekünket. A kerékpárunk alapját vesszük reverse sox Golangban, és egy klienst implementálunk hozzá powershellben.
RSocksTun
Tehát hogyan működik az rsockstun?
Az RsocksTun (a továbbiakban: rs) működése két szoftverkomponensen – a Yamuxon és a Socks5 szerveren – alapul. A Socks5 szerver egy szokásos helyi socks5, amely a kliensen fut. És a kapcsolatok multiplexelése hozzá (emlékszel a többszálasra?) a yamux (). Ez a séma lehetővé teszi több kliens socks5 szerver elindítását és külső kapcsolatok szétosztását, egyetlen TCP kapcsolaton keresztül (majdnem úgy, mint a meterpreterben) a kliensről a szerverre továbbítva őket, ezáltal többszálas módot valósít meg, amely nélkül egyszerűen nem leszünk elérhetőek. képes teljes mértékben működni a belső hálózatokban.
A yamux működésének lényege, hogy bevezeti a streamek egy további hálózati rétegét, amelyet minden csomaghoz egy 12 bájtos fejléc formájában valósít meg. (Itt szándékosan a „folyam” szót használjuk a szál helyett, hogy ne keverjük össze az olvasót a programfolyam „szálával” – ebben a cikkben is ezt a fogalmat fogjuk használni). A yamux fejléc tartalmazza a folyam számát, a stream telepítésére/lezárására szolgáló jelzőket, az átvitt bájtok számát és az átviteli ablak méretét.
Az adatfolyam telepítése/lezárása mellett a yamux egy megőrzési mechanizmust is megvalósít, amely lehetővé teszi a létrehozott kommunikációs csatorna teljesítményének figyelését. A Keeplive üzenet mechanizmus működése Yamux munkamenet létrehozásakor van konfigurálva. Valójában a beállítások közül csak két paraméter van: engedélyezés/letiltás és a csomagküldés gyakorisága másodpercekben. A Keepalive üzeneteket yamux szerver vagy yamux kliens küldheti. Amikor egy őrző üzenetet kap, a távoli félnek pontosan ugyanazt az üzenetazonosítót (valójában egy számot) kell válaszolnia rá, mint amit kapott. Általában a keepalive ugyanaz a ping, csak a yamuxhoz.
A multiplexer teljes működési technikáját: a csomagtípusokat, a kapcsolat beállítási és befejező jelzőbiteket, valamint az adatátviteli mechanizmust részletesen ismertetjük a. a yamuxnak.
Következtetés az első részhez
Tehát a cikk első részében megismerkedtünk a fordított alagutak szervezésének néhány eszközével, megvizsgáltuk azok előnyeit és hátrányait, tanulmányoztuk a Yamux multiplexer működési mechanizmusát és ismertettük az újonnan létrehozott powershell modul alapvető követelményeit. A következő részben magát a modult fejlesztjük, gyakorlatilag a semmiből. Folytatjuk. Ne válts :)
Forrás: will.com