Zgodba o raziskovanju in razvoju v 3 delih. Del 1 — raziskovalni.
Bikov je veliko — koristi pa še več.
Definisanje zadatka
Med izvajanjem pen-testov in RedTeam kampanj ni vedno mogoče uporabiti standardnih sredstev strank, kot so VPN, RDP, Citrix itd., za vstop v notranjo mrežo. Kje pa se standardni VPN uporablja s MFA in kot drugi dejavnik se uporablja fizični žeton, nekje pa se strogo spremlja in naš vstop preko VPN je takoj viden, torej — z vsemi posledicami, nekje pa takih sredstev preprosto ni.
V takšnih primerih je nenehno potrebno ustvarjati t.i. 'obratne tunele' — povezave iz notranje mreže na zunanji vir ali strežnik, ki ga nadzorujemo. Znotraj takšnega tunela lahko že delamo z notranjimi viri strank.
Obstajajo različne vrste takšnih obratnih tunelov. Najbolj znan je zagotovo Meterpreter. Tudi SSH-tuneli z obratnim preusmerjanjem portov imajo veliko povpraševanje med hekerskimi množicami. Obstaja veliko sredstev za izvajanje obratnega tuneliranja, mnoge od njih pa so dobro raziskane in opisane.
Seveda pa razvijalci zaščitnih rešitev ne stojijo ob strani in aktivno zaznavajo takšne dejavnosti.
Na primer, MSF seje uspešno zaznavajo sodobni IPS-i od Cisco ali Positive Tech, medtem ko se obratni SSH-tunel lahko zazna praktično z vsakim normalnim požarnim zidom.
Zato, da ostanemo neopaženi v dobri RedTeam kampanji — potrebujemo graditi obratni tunel z nestandardnimi sredstvi in se čim bolj približati resničnemu načinu delovanja mreže.
Poskusimo najti ali izumiti nekaj podobnega.
Preden kaj izumimo, moramo razumeti, katerega rezultata želimo doseči, katere funkcije naj opravlja naš izdelek. Kakšne bodo zahteve za tunel, da bomo lahko delali v načinu največje skrivnosti?
Očitno je, da so takšne zahteve lahko močno različne v vsakem primeru, toda po izkušnjah dela lahko izpostavimo glavne:
- delovanje na OS Windows-7-10, saj se v večini korporativnih mrež uporablja prav Windows.
- Klient se povezuje s poslužiteljem putem SSL-a kako bi isključio pasivno presretanje putem IPS-a;
- Prilikom povezivanja, klijent mora podržavati rad preko proxy poslužitelja s autorizacijom, jer je u mnogim tvrtkama izlaz na internet preko proxyja. U stvarnosti, klijentska mašina možda o tome neće ništa znati, a proxy se koristi u transparentnom režimu. No, takvu funkcionalnost moramo ugraditi;
- Klijentska komponenta mora biti sažeta i prenosiva;
Jasno je da za rad unutar mreže naručitelja klijentska mašina može instalirati OpenVPN i uspostaviti punu tunelu do svog poslužitelja (s obzirom da klijenti OpenVPN mogu raditi preko proxyja). No, prvo, to neće uvijek biti moguće, jer možda nećemo biti lokalni administratori, a drugo, to će generirati toliko buke da će pristojni SIEM ili HIPS odmah obavijestiti odgovarajuće organe. Idealno bi bilo da naš klijent funkcionira kao takozvani inline tim, slično kao što su implementirani mnogi bash shellovi, pokreće se putem naredbenog retka, na primjer, prilikom izvršavanja naredbi iz Word makronaredbi. - Naš tunel mora biti višedretven i podržavati više povezanosti istovremeno;
- Povezivanje klijenta i poslužitelja mora imati neku vrstu autorizacije, tako da se tunel uspostavlja samo za našeg klijenta, a ne za sve koji dođu na naš poslužitelj na navedenoj adresi i portu. Idealno, za "spoljne korisnike" trebala bi se otvoriti odredišna stranica s mačkama ili profesionalnom tematikom povezanom s izvorom domene.
Na primjer, ako je naručitelj zdravstvena organizacija, tada bi se administratoru informacijske sigurnosti, koji je odlučio provjeriti resurs koji je koristio zaposlenik klinike, trebala otvoriti stranica s farmaceutskim proizvodima, Wikipedia s opisom dijagnoze ili blog doktora Komarovskog itd.
Analiza postojećih alata
Prije nego što izumimo svoj bicikl — potrebno je provesti analizu postojećih bicikala i shvatiti je li nam to doista potrebno i, vjerojatno, nismo jedini koji su razmislili o potrebi za takvim funkcionalnim biciklom.
Iskanje na internetu (se zdi, da iščemo normalno), prav tako pa iskanje na GitHubu po ključnih besedah „reverse socks“ ni prineslo posebej veliko rezultatov. V glavnem vse vodi k postavljanju SSH tunelov z obratnim preslikavanjem vrat in vsega, kar je s tem povezano. Poleg SSH tunelov lahko izpostavimo še nekaj rešitev:
Davno izvedbo obratnega tunela od fantov iz Kaspersky Lab. Iz imena je jasno, za kaj je namenjen ta skript. Implementiran je v Python 2.7, tunel deluje v cleartext načinu (kot pravijo zdaj — pozdrav RKN).
Še ena izvedba v Pythonu, prav tako v cleartext, vendar z več možnostmi. Napisano je kot modul in ima API za integracijo rešitve v lastne projekte.
Prva povezava — izvorna različica izvedbe reverse socks v Golangu (ni več podprta s strani razvijalca).
Druga povezava — že naša nadgradnja z dodatnimi funkcionalnostmi, prav tako v Golangu. V naši različici smo implementirali SSL, delovanje preko proxyja z NTLM avtentikacijo, avtentikacijo na odjemalcu, pristajalno stran pri napačni prijavi (natančneje — preusmeritev na pristajalno stran), večnatančno delovanje (t.j. več oseb lahko hkrati uporablja tunel), sistem pingov odjemalca za obvestilo — ali je še vedno aktiven ali ne.
Izvedba obratnega socksa od naših 'kitajskih prijateljev' v Pythonu. Tam se za lene in 'nesmrtne' nahaja že pripravljen binarni program (exe), sestavljen s strani Kitajcev in pripravljen za uporabo. Tu lahko le kitajski bog ve, kaj vse je v tem binarcu, poleg osnovne funkcionalnosti, tako da ga uporabljajte na lastno odgovornost.
Zelo zanimiv projekt v C++ za izvedbo obratnega socksa in ne samo tega. Poleg obratnega tunela, lahko izvaja tudi preslikovanje vrat, ustvarjanje ukazne lupine itd.
MSF meterpreter
Tukaj, kot se reče, brez komentarjev. Vse malo-malo izobražene hekerje odlično poznajo to zadevo in razumejo, kako enostavno jo odkrijejo zaščitna sredstva.
Vsi zgoraj opisani pripomočki delujejo po podobni tehnologiji: na napravi znotraj omrežja se zažene vnaprej pripravljen izvršljiv binarni modul, ki vzpostavi povezavo z zunanjim strežnikom. Na strežniku se zažene strežnik SOCKS4/5, ki sprejema povezave in jih preusmeri na odjemalca.
Pomanjkljivost vseh zgoraj naštetih orodij je, da je na odjemalski napravi potrebna nameščena različica Python ali Golang (kolikokrat ste srečali nameščen Python na napravah, na primer, direktorja podjetja ali zaposlenih v pisarni?), ali pa je treba na to napravo prenesti vnaprej zgrajen binarni program (v bistvu python in skript v enotni embalaži) in zagnati ta binarni program že tam. Nalaganje exe in njegovo zagnanje je še posebna tarča za lokalni antivirus ali HIPS.
Na splošno se vsiljuje sklep — potrebujemo rešitev na powershellu. Zdaj nas bodo zmetali s paradižnikom — da je powershell vse že prežvečeno, natančno se spremlja, blokira itd. Dejansko to ni povsod res. Odgovorno trdimo. Mimogrede, obstaja kopica načinov, kako zaobiti blokade (tukaj spet znana fraza o pozdravu RKN 🙂), od preproste preimenovanja powershell.exe v cmdd.exe do powerdll itd.
Začnemo izumljati
Seveda bomo najprej pogledali v Google in… ne bomo našli ničesar o tej temi (če je kdo našel — pošljite povezave v komentarje). Edina stvar je Socks5 na powershellu, vendar je to običajen 'nenavaden' sok, ki ima vrsto svojih pomanjkljivosti (o katerih bomo govorili kasneje). Seveda ga je mogoče zlahka spremeniti v obratnega, vendar bo to samo enozakonit sok, kar ni ravno tisto, kar potrebujemo.
Torej, nismo našli nič pripravljene, zato bomo kljub temu morali izumiti svoj kolo. Za osnovo našega kolesa bomo vzeli obratnega soksa na golangu, odjemalca pa bomo realizirali na powershellu.
RSocksTun
Torej, kako deluje rsockstun?
Osnova delovanja RsocksTun (v nadaljevanju — rs) sta dva programska komponenta — Yamux in Socks5 strežnik. Socks5 strežnik je običajen lokalni socks5, ki se zažene na odjemalcu. Multiplikacija povezav do njega (se spomnite na večnalžnost?) je omogočena s pomočjo yamux (). Takšna shema omogoča zagon več odjemalskih socks5 strežnikov in razporejanje zunanjih povezav nanje, preusmerjajoč jih skozi eno samo TCP povezavo (skoraj kot v meterpreter) od odjemalca do strežnika, kar omogoča večnitno delovanje, brez katerega preprosto ne moremo polno delovati v notranjem omrežju.
Bistvo delovanja yamuxa je v tem, da uvaja dodatno omrežno raven tokov, kar implementira v obliki 12-bajtne glave za vsak paket. (Tu namerno uporabljamo besedo „tok“, ne pa „stream“, da ne zmedemo bralca z programskim tokom „thread“ — to pojmovanje bomo prav tako uporabili v tem članku). Znotraj glave yamux so vsebovani številka toka, zastavice za vzpostavitev / zaključitev toka, količina prenesenih bajtov, velikost okna prenosa.
Poleg vzpostavljanja / zaključitve toka je v yamuxu implementiran mehanizem keepalive, ki omogoča spremljanje delovanja vzpostavljene komunikacijske povezave. Delovanje mehanizma keepalive sporočil se nastavi ob ustvarjanju Yamux seje. Praktično so v nastavitvah samo — dva parametra: omogoči / onemogoči in pogostost pošiljanja paketov v sekundah. Keepalive sporočila lahko pošilja tako yamux strežnik kot yamux odjemalec. Ob prejemu keepalive sporočila je oddaljena stran dolžna odgovoriti na to s pošiljanjem točno istega identifikatorja sporočila (dejansko — števila), ki ga je prejela. Na splošno je keepalive to isti ping, le da za yamux.
Podrobno je vsa tehnika delovanja multiplexerja: tipi paketov, zastavice za vzpostavitev in zaključitev povezav, mehanizem prenosa podatkov opisan v k yamuxu.
Zaključek prvega dela
Torej, v prvem delu članka smo se seznanili z nekaterimi orodji za organizacijo povratnih predorov, si ogledali njihove prednosti in slabosti, preučili mehanizem delovanja Yamux multiplexerja in opisali glavne zahteve za novo ustvarjeni powershell modul. V naslednjem delu se bomo ukvarjali z razvojem samega modula, praktično, od začetka. Nadaljevanje sledi. Ne odklapljajte se 🙂
Izvor: habr.com
