Zgodba o raziskavah in razvoju v 3 delih. 1. del je raziskovalni.
Veliko je bukev – še več koristi.
Izjava o težavah
Med pentestami in kampanjami RedTeam ni vedno mogoče uporabiti strankinih standardnih orodij, kot so VPN, RDP, Citrix itd. kot sidro za vstop v interno omrežje. Ponekod standardni VPN deluje z uporabo MFA, strojni žeton pa se uporablja kot drugi faktor, drugje je brutalno nadzorovan in naša prijava VPN takoj postane vidna, kot pravijo, z vsem, kar vključuje, drugje pa je preprosto ni takih sredstev.
V takšnih primerih moramo nenehno vzpostavljati tako imenovane "povratne tunele" - povezave iz notranjega omrežja na zunanji vir ali strežnik, ki ga nadzorujemo. Znotraj takega tunela že lahko delamo z notranjimi viri strank.
Obstaja več različic teh povratnih tunelov. Najbolj znan med njimi je seveda Meterpreter. Med množicami hekerjev je veliko povpraševanje tudi po tunelih SSH z povratnim posredovanjem vrat. Obstaja precej sredstev za izvajanje povratnega tuneliranja in mnogi od njih so dobro preučeni in opisani.
Seveda pa razvijalci varnostnih rešitev ne stojijo ob strani in aktivno zaznavajo takšna dejanja.
Na primer, seje MSF uspešno zazna sodoben IPS podjetja Cisco ali Positive Tech, povratni tunel SSH pa lahko zazna skoraj vsak običajni požarni zid.
Zato moramo, da bi ostali neopaženi v dobri kampanji RedTeam, zgraditi povratni tunel z nestandardnimi sredstvi in se čim bolj prilagoditi dejanskemu načinu delovanja omrežja.
Poskusimo najti ali izumiti nekaj podobnega.
Preden karkoli izumimo, moramo razumeti, kakšen rezultat želimo doseči, katere funkcije naj bi opravljal naš razvoj. Kakšne bodo zahteve za predor, da bomo lahko delali v maksimalno prikritem načinu?
Jasno je, da se lahko za vsak primer takšne zahteve zelo razlikujejo, vendar je na podlagi delovnih izkušenj mogoče identificirati glavne:
- delo na operacijskem sistemu Windows-7-10. Ker večina omrežij podjetij uporablja Windows;
- odjemalec se poveže s strežnikom prek SSL, da se izogne neumnemu poslušanju z uporabo ips;
- Pri povezovanju mora odjemalec podpirati delo prek proxy strežnika z avtorizacijo, ker V mnogih podjetjih dostop do interneta poteka prek proxyja. Pravzaprav odjemalski stroj morda sploh ne ve ničesar o tem, proxy pa se uporablja v preglednem načinu. Toda takšno funkcionalnost moramo zagotoviti;
- odjemalski del naj bo jedrnat in prenosljiv;
Jasno je, da lahko za delo v strankinem omrežju namestite OpenVPN na odjemalski stroj in ustvarite popoln predor do svojega strežnika (na srečo lahko odjemalci openvpn delujejo prek proxyja). Ampak, prvič, to ne bo vedno delovalo, saj tam morda nismo lokalni skrbniki, in drugič, povzročilo bo toliko hrupa, da nas bo spodoben SIEM ali HIPS takoj "nacukal". V idealnem primeru bi moral biti naš odjemalec tako imenovani inline ukaz, kot je na primer implementiranih veliko lupin bash, in se zažene prek ukazne vrstice, na primer pri izvajanju ukazov iz besednega makra. - naš tunel mora biti večniten in podpirati veliko povezav hkrati;
- povezava odjemalec-strežnik mora imeti nekakšno avtorizacijo, da je tunel vzpostavljen samo za našega odjemalca in ne za vse, ki pridejo na naš strežnik na določen naslov in vrata. V idealnem primeru bi se morala ciljna stran z mačkami ali strokovnimi temami, povezanimi z izvirno domeno, odpreti za »uporabnike tretjih oseb«.
Na primer, če je stranka zdravstvena organizacija, potem za skrbnika za informacijsko varnost, ki se odloči preveriti vir, do katerega je dostopal uslužbenec klinike, stran s farmacevtskimi izdelki, Wikipedia z opisom diagnoze ali blog dr. Komarovskega itd. . bi se moral odpreti.
Analiza obstoječih orodij
Preden na novo izumite svoje kolo, morate opraviti analizo obstoječih koles in ugotoviti, ali ga res potrebujemo in verjetno nismo edini, ki smo pomislili na potrebo po tako funkcionalnem kolesu.
Guglanje po internetu (zdi se, da googlamo normalno), pa tudi iskanje po Githubu s ključnimi besedami “reverse socks” ni dalo veliko rezultatov. V bistvu se vse spušča v gradnjo tunelov ssh z povratnim posredovanjem vrat in vsem, kar je s tem povezano. Poleg tunelov SSH obstaja več rešitev:
Dolgoletna izvedba povratnega tunela fantov iz Kaspersky Laba. Iz imena je jasno, čemu je ta skript namenjen. Implementiran v Python 2.7, predor deluje v načinu čistega besedila (kot je zdaj moderno reči - pozdravljen RKN)
Še ena izvedba v Pythonu, tudi v čistem besedilu, vendar z več možnostmi. Napisan je kot modul in ima API za integracijo rešitve v vaše projekte.
Prva povezava je izvirna različica izvedbe obratnega soxa v Golangu (razvijalec je ne podpira).
Druga povezava je naša revizija z dodatnimi funkcijami, tudi v Golangu. V naši različici smo implementirali SSL, delo prek proxyja z avtorizacijo NTLM, avtorizacijo na odjemalcu, ciljno stran v primeru napačnega gesla (oz. preusmeritev na ciljno stran), večnitni način (tj. več ljudi). lahko hkrati dela s predorom), sistem pinganja odjemalca, da se ugotovi, ali je živ ali ne.
Implementacija reverse sox naših "kitajskih prijateljev" v Pythonu. Tam je za lene in »nesmrtne« že pripravljena binarna datoteka (exe), ki so jo sestavili Kitajci in je pripravljena za uporabo. Tukaj samo kitajski bog ve, kaj še lahko vsebuje ta binarna datoteka poleg glavne funkcionalnosti, zato uporabljajte na lastno nevarnost in tveganje.
Precej zanimiv projekt v C++ za implementacijo obratnega soxa in več. Poleg povratnega tunela lahko izvaja posredovanje vrat, ustvari ukazno lupino itd.
MSF meterpreter
Tukaj, kot pravijo, brez pripomb. Vsi tudi bolj ali manj poučeni hekerji to zadevo dobro poznajo in razumejo, kako zlahka jo zaznajo varnostna orodja.
Vsa zgoraj opisana orodja delujejo po podobni tehnologiji: vnaprej pripravljen izvršljiv binarni modul se zažene na stroju znotraj omrežja, ki vzpostavi povezavo z zunanjim strežnikom. Strežnik poganja strežnik SOCKS4/5, ki sprejema povezave in jih posreduje odjemalcu.
Pomanjkljivost vseh zgornjih orodij je, da je treba na odjemalski stroj namestiti Python ali Golang (ste pogosto videli Python nameščen na računalnikih npr. direktorja podjetja ali pisarniškega delavca?) ali vnaprej sestavljen binary (pravzaprav python) je treba povleči na ta stroj in skript v eni steklenici) in zagnati to binary že tam. In prenos exe in nato zagon je tudi podpis za lokalni antivirus ali HIPS.
Na splošno se sklep nakazuje sam - potrebujemo rešitev PowerShell. Zdaj bodo paradižniki leteli na nas - pravijo, da je PowerShell že ves izrabljen, nadzorovan, blokiran itd. in tako naprej. Pravzaprav ne povsod. Izjavljamo odgovorno. Mimogrede, obstaja veliko načinov za izogibanje blokiranju (tukaj je spet modna fraza o zdravo RKN 🙂), začenši z neumnim preimenovanjem powershell.exe -> cmdd.exe in konča s powerdll itd.
Začnimo izumljati
Jasno je, da bomo najprej pogledali na Google in ... ne bomo našli ničesar na to temo (če je kdo našel, naj objavi povezave v komentarjih). Obstaja samo Socks5 na powershell, vendar je to navaden "direkten" sox, ki ima številne svoje pomanjkljivosti (o njih bomo govorili kasneje). Seveda ga lahko z rahlim gibom roke obrnete v obratno, vendar bo to samo enonavojni sox, ki pa ni ravno tisto, kar potrebujemo.
Torej nismo našli ničesar že pripravljenega, tako da bomo morali še vedno znova odkriti kolo. Za osnovo našega kolesa bomo vzeli reverse sox v Golangu, odjemalca zanj pa implementiramo v powershell.
RSocksTun
Kako torej deluje rsockstun?
Delovanje RsocksTun (v nadaljevanju rs) temelji na dveh programskih komponentah - strežniku Yamux in Socks5. Strežnik Socks5 je običajen lokalni socks5, deluje na odjemalcu. In multipleksiranje povezav z njim (se spomnite večnitnosti?) je zagotovljeno z uporabo yamux (). Ta shema vam omogoča, da zaženete več odjemalskih strežnikov socks5 in jim razdelite zunanje povezave, jih posredujete prek ene same povezave TCP (skoraj kot v meterpreterju) od odjemalca do strežnika, s čimer implementirate večnitni način, brez katerega preprosto ne bomo lahko v celoti deluje v notranjih omrežjih.
Bistvo delovanja yamuxa je, da uvede dodatno omrežno plast tokov, ki jo izvaja v obliki 12-bajtne glave za vsak paket. (Tu namerno uporabljamo besedo "tok" namesto nit, da ne bi zamenjali bralca s programskim tokom "nit" - ta koncept bomo uporabili tudi v tem članku). Glava yamux vsebuje številko toka, zastavice za namestitev/prekinitev toka, število prenesenih bajtov in velikost okna za prenos.
Poleg namestitve/prekinitve toka yamux izvaja mehanizem za ohranjanje delovanja, ki vam omogoča spremljanje delovanja vzpostavljenega komunikacijskega kanala. Delovanje mehanizma za sporočila Keeplive je konfigurirano pri ustvarjanju seje Yamux. Pravzaprav sta od nastavitev samo dva parametra: omogoči/onemogoči in pogostost pošiljanja paketov v sekundah. Sporočila Keepalive lahko pošlje strežnik yamux ali odjemalec yamux. Ko prejme sporočilo Keepalive, se mora oddaljeni udeleženec nanj odzvati s pošiljanjem popolnoma enakega identifikatorja sporočila (pravzaprav številke), kot ga je prejel. Na splošno je keepalive isti ping, le za yamux.
Celotna tehnika delovanja multiplekserja: tipi paketov, nastavitev povezave in zaključne zastavice ter mehanizem prenosa podatkov so podrobno opisani v na yamux.
Zaključek prvega dela
Tako smo se v prvem delu članka seznanili z nekaterimi orodji za organizacijo povratnih predorov, pogledali njihove prednosti in slabosti, preučili mehanizem delovanja multiplekserja Yamux in opisali osnovne zahteve za novo ustvarjeni modul powershell. V naslednjem delu bomo razvili sam modul, praktično iz nič. Se nadaljuje. Ne menjaj :)
Vir: www.habr.com