Kirjutame Reverse socks5 proxy Powershellis. Osa 1

Lugu uurimisest ja arendamisest kolmes osas. Osa 1 — uurimistegevus.
Tähte on palju — kasu veelgi enam.

Ülesande seadmine

Pentestide ja RedTeam kampaaniate käigus ei õnnestu alati kasutada Klientide tavalisi vahendeid, nagu VPN, RDP, Citrix jne, sisenemiseks sisemisse võrku. Kusagil töötab tavaline VPN MFA kaudu ja teise faktorina kasutatakse raudset tokenit, kusagil jälgitakse seda rangelt ning meie sisenemine VPN-i on kohe nähtav, nagu öeldakse — kõikide tagajärgedega, ja kusagil ei ole selliseid vahendeid lihtsalt olemas.

Sellistel juhtudel tuleb pidevalt luua nn «tagasiühendusi» — ühendused sisemisest võrgust väliste ressursside või meie kontrollitava serveriga. Sellise tunni sees saame juba töötada Klientide sisemiste ressurssidega.

Selliseid tagasivõrke on mitu tüüpi. Kõige tuntum neist on muidugi Meterpreter. Samuti on suurt nõudlust rahva häkkerite seas SSH-tunnelite järele, millel on tagasivoolu portide suunamine. Tagasivoolu realiseerimiseks on olemas palju vahendeid ja paljusid neist on hästi uuritud ja kirjeldatud.
Muidugi ei jää kaitselahenduste arendajad kõrvale ja tuvastavad aktiivselt selliseid tegevusi.
Näiteks MSF-seansid tuvastatakse edukalt tänapäevaste IPS-ide poolt Cisco või Positive Techilt, samas kui tagasivoolu SSH-tunnelit saab tuvastada praktiliselt ükskõik millise normaalse tulemüüriga.

Seega, et hea RedTeam kampaania käigus märkamatuks jääda — peame ehitama tagasivoolu tunni ebatavaliste vahendite abil ja maksimaalselt kohanduma võrgu reaalse töörežiimiga.

Proovime leida või välja mõelda midagi sellist.

Enne kui midagi välja mõelda, peaksime aru saama, millist tulemust soovime saavutada, milliseid funktsioone peaks meie arendus täitma. Millised on nõuded tunnelile, et saaksime töötada maksimaalse varjatuse režiimis?

On selge, et igal juhul võivad need nõuded oluliselt erineda, kuid kogemuste põhjal võib välja tuua peamised:

• töö Windows 7-10 operatsioonisüsteemiga. Kuna enamikus ettevõttevõrkudes kasutatakse just Windowsi.
• kliendi ühendus serveriga SSL-i kaudu, et vältida salajast kuulamist IPS-i meetoditega;
• ühenduse loomisel peab klient toetama autoriseeritud proksiserveri kaudu töötamist, kuna paljudes ettevõtetes toimub internetiühendus läbi proksi. Tegelikult ei pruugi kliendi masin sellest isegi teadlik olla ja proksi kasutatakse läbipaistvas režiimis. Kuid selline funktsioon peab olema meie poolt ette nähtud;
• kliendi osa peab olema lakooniline ja kantav;
  On selge, et tellija võrgus töötamiseks saab kliendi masinasse paigaldada OpenVPN ja luua täieliku tunneli oma serverisse (õnneks oskavad OpenVPN kliendid töötada läbi proksi). Kuid esiteks ei pruugi see alati õnnestuda, kuna me ei pruugi olla seal kohalikud adminnid, ja teiseks teeb see liiga palju lärmi, et korralik SIEM või HIPS meid kohe "trahviks". Ideaalis peaks meie klient olema nn inline meeskond, nagu on paljudes bash-shellides, ja käivituma käsurealt, näiteks word-makrode käivitamisel.
• meie tunnel peab olema mitmeoksaline ja toetama mitut samal ajal ühendust;
• kliendi-serveri ühendusel peab olema mingi autoriseerimine, et tunneli asutamine toimuks ainult meie kliendi jaoks, mitte kõigi jaoks, kes meie serverisse kinnitatud aadressi ja pordi kaudu pääsevad. Ideaalis peaks "kolmandate kasutajate" jaoks avanema maandumisleht kasside või professionaalse teemaga, mis on seotud algse domeeniga.
  Näiteks, kui tellija on meditsiiniasutus, peaks infojulgeoleku administraator, kes otsustab kontrollida ressurssi, mille poole kliiniku töötaja pöördus, nägema lehte farmaatsiatoodete, diagnooside kirjelduste või arst Komarovski blogiga jne.

O existente náituse analüüs

Enne kui leiutame oma jalgratta — on vaja analüüsida olemasolevaid jalgrattaid ja mõista, kas meil on seda tõeliselt vaja ning tõenäoliselt ei mõtle me selle funktsionaalsuse vajadusele üksi.

Internetis otsimine (me googeldame vist normaalselt) ning samuti Githubis avasõnadega „reverse socks“ ei andnud eriti palju tulemusi. Peamiselt seisneb kõik SSH-tunnelite loomises tagasiheidetavate portide jaoks ja kõigega, mis sellega seotud on. SSH-tunnelitest kõrval on välja toodud veel mõned lahendused:

github.com/klsecservices/rpivot
Pikalt arendatud tagasitunneli lahendus Kaspersky laborist. Nimi juba räägib, milleks see skript mõeldud on. Tehtud Python 2.7-s, tunnel töötab selgelt (justkui oleks moodne öelda - tere RKN)

github.com/tonyseek/rsocks
Veel üks rakendus Pythoni keeles, samuti selges tekstis, kuid rohkem võimalusi. Kirjutatud moodulina, millel on API lahenduse integreerimiseks oma projektidesse.

github.com/llkat/rsockstun
github.com/mis-team/rsockstun
Esimene link - algne versioon tagasivoolu sokist Golan keeles (arendaja ei toeta enam).
Teine link - see on juba meie täiustatud versioon koos täiendavate funktsioonidega, samuti Golan keeles. Meie versioonis oleme rakendanud SSL-i, töö läbi proxy NTLM-autentimisega, klientimise autentimise, vale parooli korral suunamise maandumislehele (täpsemalt - suunamise maandumislehele), mitme lõime režiimi (s.t. tunneliga võivad töötada korraga mitmed inimesed), kliendi pingimise süsteemi selleks, et teada saada - kas ta on elus või mitte.

github.com/jun7th/tsocks
Tagasirendise sokk meie „hiina sõpradelt“ Pythonis. Seal on ka laiskadele ja „surematutele“ valmis binaarfail (exe), mille on kokku pannud hiinlased ja mis on kasutamiseks valmis. Siin teab ainult üks hiina jumal, mis sellel binaaril veel olla võib, välja arvatud põhifunktsionaalsus, seega kasutage oma riski ja ohtu.

github.com/securesocketfunneling/ssf
Üsna huvitav projekt C++ keeles tagasivoolu sokkide ja mitte ainult. Lisaks tagasihea tunneli loomisele suudab see teha sadamate edastamist, käskude shelli loomist jne.

MSF meterpreter
Siin, nagu öeldakse, pole kommentaare. Kõik enam-vähem haritud häkkerid tunnevad seda asja hästi ja mõistavad, kui kergelt seda kaitsevahendid avastavad.

Kõik eespool kirjeldatud tööriistad toimivad sarnase tehnoloogia alusel: seadmes sees võrgus käivitatakse eelnevalt valmistatud käivitatav binaarmoodul, mis loob ühenduse välise serveriga. Serveris käivitatakse SOCKS4/5 server, mis võtab ühendusi vastu ja edastab need kliendile.

Kasutamisel on kõikidel nimetatud tööriistadel puudus, et kas kliendiseadmes peab olema installitud Python või Golang (kui sageli olete kohanud Python-i installatsiooni näiteks ettevõtte juhi või kontoritöötaja seadmes?), või tuleb sinna masinasse tuua eelnevalt kokku pandud binaarfail (praktiactually python ja skript ühes paketis) ja käivitada see seal. Exe-faili allalaadimine ja käivitamine on kohalikule viirusetõrjele või HIPS-ile juba piisav signatuur.

Seega, järeldus on selge — vajame lahendust powershelli pealt. Praegu lendavad meile tomatid — et powershell on juba kõikidest nurkadest läbi käidud, seda jälgitakse, blokeeritakse jne. Tegelikult ei ole see kaugeltki igal pool nii. Vastutustundlikult ütleme. Muide, blokeeringutest möödumise viise on palju (siin jälle see trendikas fraas tere RKN 🙂), alates lihtsalt powershell.exe ümbernimetamisest cmdd.exe-ks ja lõpetades powerdll-i jpt.

Alustame oma leiutamist

Ilmselgelt vaatame kõigepealt Google'i ja... ei leia selle teema kohta peaaegu midagi (kui keegi leidis, siis visake lingid kommentaaridesse). On olemas ainult rakendus Socks5 powershellil, kuid see on tavaline "otse" socks, millel on oma puudused (millest räägime hiljem). Loomulikult saab seda lihtsa liigutusega muuta tagurpidi, kuid see oleks ainult ühesuunaline socks, mis pole meie jaoks just see, mida vajame.

Nii et, me ei leidnud midagi valmiskujul, seega peame ikkagi oma jalgratta leiutama. Meie jalgratta aluseks on meie arendus tagasipööratud socks golangil ja kliendi selle jaoks teeme powershellis.

RSocksTun
Nii et, kuidas rsockstun töötab?

RsocksTun'i (edaspidi — rs) töö aluseks on kaks tarkvarakomponenti — Yamux ja Socks5 server. Socks5 server on tavaline kohalik socks5, see käivitatakse kliendil. Ja ühenduste multiplexerimise funktsiooni (kas mäletate mitme protsessi töötlust?) täidab yamux (veel üks multiplexer). See skeem võimaldab käivitada mitmeid kliente socks5 servereid ja suunata välised ühendused nende kaudu, edastades need üheainsa TCP-ühenduse kaudu (peaaegu nagu meterpreter) kliendi ja serveri vahel, luues seeläbi mitme lõime režiimi, ilma milleta me ei saaks sisemise võrgus korralikult töötada.

Yamux'i tööpõhimõte seisneb selles, et see lisab täiendava võrgu taseme voogudele, tehes selle iga paketi jaoks 12-baidise päise kujul. (Siin kasutame me meelevaldselt sõna „voog“ ja mitte „stream“, et mitte segadusse ajada lugejat programmivooga „thread“ – seda mõistet kasutame me samuti käesolevas artiklis). Yamux’i päises sisaldub voolu number, lipud voolu avamiseks/katkestamiseks, edastatud baitide arv ja edastusakna suurus.

Lisaks voolu avamise/katkestamise võimalusele on yamuxis rakendatud ka keepalive mehhanism, mis võimaldab jälgida loodud sidekanali töökindlust. Keepalive sõnumite töö mehhanism seadistatakse Yamux seansi loomisel. Tegelikult on seal seadeteks ainult kaks parameetrit: lubamine/keeldumine ja pakettide saatmise sagedus sekundites. Keepalive sõnumeid saab saata nii yamux-server kui yamux-klient. Saades keepalive sõnumi, peab eemalolev pool sellele vastama täpselt sama sõnumi identifikaatoriga (tõeliselt – numbriga), mille ta on saanud. Üldiselt on keepalive sama mis ping, lihtsalt yamuxi jaoks.

Käesolevas artiklis on üksikasjalikult välja toodud mitmepleksori töö tehnika: paketidüübid, ühenduse avamise ja katkestamise lipud, andmete edastamise mehhanism. spetsiifikatsioon yamux'ile.

Esimese osa kokkuvõte

Seega tutvusime artikli esimeses osas teatud tööriistadega tagasitunneli korraldamiseks, vaatasime nende eeliseid ja puudusi, uurisime Yamuxi mitmepleksori töömehhanismi ning kirjeldasime uusi nõudeid loodavale powershell-moodulile. Järgmises osas käsitleme mooduli arendamist praktiliselt nullist. Jätkub. Ära lülitu välja 🙂

Allikas: habr.com