Három részből álló kutatás és fejlesztés története. 1. rész - kutatási.
Sok betű van - még több haszon.
Lépjünk át a kitűzött feladatra: írjunk egy XDP mechanizmust SYN cookie-kkal.
Pentestek és RedTeam kampányok során nem mindig sikerül hagyományos eszközöket, például VPN-t, RDP-t, Citrixet stb. használni, hogy bejussunk a belső hálózatba. Egyes helyeken a szokásos VPN MFA-val működik, és második faktorként hardveres tokent használ, másutt szigorúan figyelik, és a VPN-on való bejutásunk azonnal látható, ahogy mondani szokták - minden következménnyel együtt, míg máshol egyszerűen nincsenek ilyen eszközök.
Ilyen esetekben folyamatosan úgynevezett "visszafelé irányuló alagutakat" kell létrehoznunk - kapcsolatok a belső hálózattól egy külső forráshoz vagy általunk ellenőrzött szerverhez. Az ilyen alagúton belül már dolgozhatunk a megrendelők belső erőforrásaival.
Többféle ilyen visszafelé irányuló alagút létezik. A legismertebb természetesen a Meterpreter. Az SSH-alagút visszafelé irányuló porttovábbítással is nagy népszerűségnek örvend a hackerek körében. Sok módszer létezik a visszafordított alagút létrehozására, és sok közülük jól van tanulmányozva és leírva.
Természetesen a védelmi megoldások fejlesztői sem állnak távol, és aktívan észlelik az ilyen tevékenységeket.
Például, a MSF sessionök sikeresen érzékelhetők a modern Cisco vagy Positive Tech IPS-ek által, míg a visszafordított SSH-alagút gyakorlatilag bármely normális tűzfal által észlelhető.
Következésképpen, ahhoz, hogy észrevétlenek maradjunk egy jó RedTeam kampány során - olyan visszafelé irányuló alagút építésére van szükség, amely nem hagyományos eszközökkel működik, és maximálisan alkalmazkodik a hálózat tényleges munkamódjához.
Próbáljunk meg találni vagy kitalálni valami hasonlót.
Mielőtt valami újat kitalálnánk, meg kell értenünk, hogy milyen eredményt szeretnénk elérni, milyen funkciókat kell teljesítenie a fejlesztésünknek. Mik lesznek az alagút követelményei, hogy maximális rejtőzködés mellett tudjunk dolgozni?
Nyilvánvaló, hogy minden esetben ezek a követelmények jelentősen eltérhetnek, de a munkatapasztalat alapján kiemelhető néhány alapvető:
- Windows-7-10 operációs rendszeren való működés. Mivel a legtöbb vállalati hálózatban ez a Windows használatos.
- A kliens SSL-en keresztül csatlakozik a szerverhez, hogy elkerülje az IPS eszközökkel való passzív lehallgatást;
- A csatlakozás során a kliensnek támogatnia kell a proxy-szerveren keresztüli működést, mivel sok vállalatnál az internethez való kijutás proxy-n keresztül történik. Valójában a kliensgép erről akár tudomást sem vehet, a proxy pedig átlátszó üzemmódban működik. De ilyen funkciót el kell érnünk;
- A kliens oldala legyen tömör és hordozható;
Nyilvánvaló, hogy a Megrendelő hálózatán belül a kliensgépére OpenVPN telepíthető, és teljes alagút létrehozható a saját szerveréhez (mivel az OpenVPN kliensek tudnak proxy-n keresztül működni). De egyrészt nem mindig fog sikerülni, mivel nem biztos, hogy helyi adminisztrátorok vagyunk, másrészt pedig annyi zajt csap, hogy a rendes SIEM vagy HIPS azonnal jelezni fog nekünk. Ideálisan a kliensünknek inline parancsokként kellene működnie, mint sok bash shell, és a parancssorból kellene futnia, például Word makrókból végrehajtott parancsok esetén. - Alagútunknak többszálúnak kell lennie, és egyszerre több kapcsolódást kell támogatnia;
- A kliens-szerver kapcsolatnak kell valamilyen azonosítással rendelkeznie, hogy az alagút csak a mi kliensünk számára jöjjön létre, nem pedig mindenki számára, aki elér minket a megadott címün és portunkon. Ideálisan a "külső felhasználók" számára egy landing page-nek kell megnyílni, amely macskákkal vagy a forrásdomainhez kapcsolódó szakmai témákkal foglalkozik.
Például, ha a Megrendelő egy egészségügyi intézmény, akkor az informatikai biztonsági adminisztrátor számára, aki ellenőrizni akarja azt a forrást, amelyhez a klinika munkatársa fordult, egy gyógyszeripari termékekkel foglalkozó oldalnak kell megnyílnia, egy Wikipedia oldalnak a diagnózis leírásával vagy Dr. Komarovszkij blogjának, stb.
A meglévő eszközök elemzése
Mielőtt feltalálnánk a saját kerékpárunkat — szükséges elemezni a meglévő kerékpárokat, és megérteni, hogy valóban szükségünk van-e rá, és valószínűleg nem csak mi gondoltunk arra, hogy szükség lenne egy ilyen funkcionális kerékpárra.
Az internetes keresés (úgy tűnik, hogy elég jól guglizzuk), valamint a GitHubon a "reverse socks" kulcsszavakkal való keresés nem adott sok eredményt. Főleg minden SSH-alagút építésére vonatkozik visszatérő porttovábbítással és mindennel, ami ezzel jár. Az SSH-alagutak mellett néhány megoldást kiemelhetünk:
A Kaspersky Laboratórium srácai által régen elkészített visszafelé irányuló alagút. A névből egyértelmű, hogy mire szolgál ez a script. Python 2.7-ben készült, az alagút tiszta szöveges módban működik (ahogy most divatos mondani – üdv RKN-nek)
Még egy megvalósítás Pythonban, szintén tiszta szövegben, de több lehetőséggel. Modul formájában íródott és van API a megoldás integrálásához a saját projekteidbe.
Az első link az eredeti visszafelé irányuló Sokszor Golangban készült verziója (a fejlesztő nem támogatja).
A második link a mi továbbfejlesztésünk további funkciókkal, szintén golangban. A mi verziónkban megvalósítottuk az SSL-t, működést proxy-n keresztül NTLM hitelesítéssel, kliens-oldali hitelesítést, hibás jelszó esetén egy indítóoldalt (pontosabban – átirányítást az indítóoldalra), többszálas működést (azaz az alagútban egyszerre több ember is dolgozhat), valamint a kliens pingsorozatát arra vonatkozóan, hogy él-e még vagy sem.
A "kínai barátaink" által Pythonban kidolgozott visszafelé irányuló sokszorozáshoz készült megoldás. Itt lazák és "halhatatlanok" számára már egy kész bináris (exe) is megtalálható, amit a kínaiak készítettek és használatra készen áll. Csak Isten tudja, mi lehet még ebben a binárisban az alapfunkcionalitáson kívül, ezért saját felelősségére használja.
Egy kifejezetten érdekes C++ projekt a visszafelé irányuló sokszorozás és nem csak az megvalósítására. A visszafelé irányuló alagúton kívül porttovábbítást, parancssori shell létrehozását stb. is tudja.
MSF meterpreter
Itt, ahogy mondani szokás, nincs mit kommentálni. Minden valamennyire képzett hacker tökéletesen ismeri ezt a dolgot és tudja, mennyire könnyen észlelhetők a védelmi eszközök.
Az összes fent említett eszköz hasonló technológián működik: a hálózaton belüli gépen egy előre elkészített végrehajtható bináris modul fut, amely kapcsolatot létesít a külső szerverrel. A szerveren SOCKS4/5 kiszolgáló fut, amely fogadja a kapcsolatokat és továbbítja azokat az ügyfélhez.
Az összes felsorolt eszköz hátránya, hogy vagy a kliens gépén szükséges a Python vagy Golang telepítése (gondoltál már arra, mennyire gyakori a Python telepítése például a cégvezetők vagy az irodai dolgozók gépein?), vagy ezt a gépet előre összeállított binárissal kell megterhelni (tulajdonképpen a python és a script egy csomagban) és ott elindítani ezt a binárist. Az exe letöltése és futtatása pedig nem éppen a legkevésbé érzékeny aláírás a helyi víruskereső vagy HIPS számára.
Összességében nyilvánvaló, hogy szükségünk van egy powershell alapú megoldásra. Most érkezni fognak a tojások — mondván, hogy a powershell elavult, monitorozzák, blokkolják stb. stb. Valójában azonban korántsem mindenhol. Felelősen állítjuk. Egyébként rengeteg módszer létezik a blokkok kikerülésére (itt újra felmerül a hatékony kifejezés, hogy üdv a RKN-nek 🙂 ), kezdve a powershell.exe átnevezésével cmdd.exe-ra, egészen a powerdll-ig stb.
Kezdünk feltalálni
Természetesen először a Google-ben nézünk körül, és… nem találunk semmit a témában (ha valaki találkozott valami hasznossal — küldjétek el a linkeket a megjegyzésekben). Csak Socks5 powershell-ra létezik, de ez egy sima "közvetlen" socks, amelynek számos hátránya van (erről később beszélünk). Persze, könnyedén átalakítható visszafordítottá, de ez csak egy szálon működő socks lesz, ami számunkra nem éppen ideális.
Tehát nem találtunk kész megoldást, ezért nekünk kell feltalálni a saját kerékpárunkat. Alapul vesszük visszafordított socksra golangon, és a kliensét powershell-en valósítjuk meg.
RSocksTun
Tehát hogyan működik az rsockstun?
Az RsocksTun működésének alapját két szoftverkomponens alkotja — a Yamux és a Socks5 szerver. A Socks5 szerver egy hagyományos helyi socks5, amely a kliensen fut. Az ehhez való kapcsolatok multiplexelését (emlékszel a több szálra?) a yamux biztosítja (). Ez a séma lehetővé teszi több kliens socks5 szerver indítását, és a külső kapcsolatok elosztását közöttük, egyetlen TCP-kapcsolaton keresztül (majdnem mint a meterpreter esetében) a kliens és a szerver között, ezáltal megvalósítva a több szálú módot, amely nélkül egyszerűen nem tudunk teljes körűen működni a belső hálózaton.
A yamux működésének lényege, hogy egy további hálózati szintet vezet be az áramlások számára, amelyet minden csomaghoz 12 bájtos fejléc formájában valósít meg. (Itt szándékosan használjuk a „stream” kifejezést, nem pedig a „folyamot”, hogy ne zavarjuk meg az olvasót a programfolyammal kapcsolatos „thread” kifejezéssel — ezt a fogalmat szintén használni fogjuk a cikkben). A yamux fejlécén belül található a stream száma, a stream indításához/befejezéséhez szükséges flag-ek, az átvitt bájtok száma, valamint az ablakméret.
A yamux-ban a stream indításán/befejezésén kívül lehetőség van keepalive mechanizmusok bevezetésére is, amelyek lehetővé teszik a kapcsolat működőképességének ellenőrzését. A keepalive üzenetek működését a Yamux-session létrehozásakor lehet beállítani. Valójában a beállításokban csak két paraméter található: engedélyezés/letiltás és a másodpercenkénti csomagküldési frekvencia. A keepalive üzeneteket a yamux szerver és a yamux kliens is küldheti. Az eltávolított félnek a keepalive üzenet megérkezésekor pontosan ugyanazzal az üzenet-azonosítóval (tulajdonképpen számmal) kell válaszolnia, amelyet fogadott. Összességében a keepalive ugyanaz, mint a ping, csak yamux esetén.
A multiplexer működésének minden technikai részlete: csomagtípusok, az összeköttetések létrehozásához és befejezéséhez használt flag-ek, az adatok átviteli mechanizmusa részletezve van a yamux-nál.
Az első rész következtetése
Tehát az írás első részében megismertettük a visszafordított alagút létrehozásához szükséges eszközöket, megvizsgáltuk azok előnyeit és hátrányait, áttekintettük a Yamux multiplexer működési mechanizmusát, és leírtuk az újonnan létrehozandó PowerShell modul alapvető követelményeit. A következő részben magának a modulnak a fejlesztésével foglalkozunk, gyakorlatilag a nulláról. Folytatás következik. Ne kapcsolódjon el 🙂
Forrás: habr.com
