Saga um rannsóknir og þróun í 3 hlutum. Hluti 1 er rannsakandi.
Það eru mörg beykitré - jafnvel fleiri kostir.
Samsetning vandans
Í pentests og RedTeam herferðum er ekki alltaf hægt að nota staðlað verkfæri viðskiptavinarins, svo sem VPN, RDP, Citrix o.s.frv. sem akkeri til að komast inn í innra netið. Sums staðar virkar staðlað VPN með MFA og vélbúnaðarlykill er notaður sem annar þáttur, á öðrum er hrottalega fylgst með því og VPN innskráningin okkar verður strax sýnileg, eins og sagt er, með öllu sem því fylgir, en í öðrum eru einfaldlega engin slík leið.
Í slíkum tilfellum þurfum við stöðugt að gera svokölluð „öfug göng“ - tengingar frá innra neti við ytri auðlind eða netþjón sem við stjórnum. Inni í slíkum göngum getum við nú þegar unnið með innri auðlindir viðskiptavina.
Það eru nokkrar tegundir af þessum afturgöngum. Frægastur þeirra er auðvitað Meterpreter. SSH göng með öfugframsendingu hafnar eru einnig eftirsótt meðal tölvuþrjóta. Það eru talsvert margar leiðir til að innleiða öfuga jarðgangagerð og margar þeirra eru vel rannsakaðar og lýst.
Auðvitað, fyrir sitt leyti, standa verktaki öryggislausna ekki til hliðar og greina slíkar aðgerðir virkan.
Til dæmis, MSF fundir eru greind með góðum árangri með nútíma IPS frá Cisco eða Positive Tech, og öfug SSH göng er hægt að greina með næstum öllum venjulegum eldvegg.
Þess vegna, til þess að vera óséður í góðri RedTeam herferð, þurfum við að byggja öfug göng með óstöðluðum aðferðum og laga okkur eins vel og hægt er að raunverulegum rekstrarham netsins.
Við skulum reyna að finna eða finna upp eitthvað svipað.
Áður en eitthvað er fundið upp þurfum við að skilja hvaða árangri við viljum ná, hvaða hlutverkum þróun okkar ætti að framkvæma. Hverjar verða kröfurnar fyrir göngin svo við getum unnið í hámarks laumuham?
Ljóst er að í hverju tilviki geta slíkar kröfur verið mjög mismunandi, en miðað við starfsreynslu má greina þær helstu:
- vinna á Windows-7-10 OS. Þar sem flest fyrirtækjanet nota Windows;
- viðskiptavinurinn tengist þjóninum í gegnum SSL til að forðast heimskulega hlustun með því að nota ips;
- Við tengingu verður viðskiptavinurinn að styðja við vinnu í gegnum proxy-miðlara með heimild vegna þess Í mörgum fyrirtækjum er aðgangur að internetinu í gegnum umboð. Reyndar gæti biðlaravélin ekki einu sinni vitað neitt um það og umboðið er notað í gagnsæjum ham. En við verðum að veita slíka virkni;
- viðskiptavinahlutinn ætti að vera hnitmiðaður og flytjanlegur;
Það er ljóst að til að vinna innan netkerfis viðskiptavinarins geturðu sett upp OpenVPN á biðlaravélinni og búið til fullgild göng á netþjóninn þinn (sem betur fer geta openvpn viðskiptavinir unnið í gegnum proxy). En í fyrsta lagi mun þetta ekki alltaf virka, þar sem við erum kannski ekki staðbundnir stjórnendur þar, og í öðru lagi mun það gera svo mikinn hávaða að almennilegt SIEM eða HIPS mun strax „sníkja“ á okkur. Helst ætti viðskiptavinur okkar að vera svokölluð inline skipun, þar sem til dæmis margar bash skeljar eru útfærðar, og ræst í gegnum skipanalínuna, til dæmis þegar skipanir eru keyrðar úr orðafjölvi. - göngin okkar verða að vera fjölþráð og styðja við margar tengingar samtímis;
- tenging biðlara og netþjóns verður að hafa einhvers konar heimild þannig að göngin séu eingöngu stofnuð fyrir viðskiptavini okkar, en ekki fyrir alla sem koma á netþjóninn okkar á tilgreindu heimilisfangi og höfn. Helst ætti áfangasíða með köttum eða faglegum efnum sem tengjast upprunalega léninu að opna fyrir „þriðju aðila notendur“.
Til dæmis, ef viðskiptavinurinn er sjúkrastofnun, þá fyrir upplýsingaöryggisstjóra sem ákveður að athuga auðlindina sem starfsmaður heilsugæslustöðvar fór á, síðu með lyfjavörum, Wikipedia með lýsingu á greiningunni eða bloggi Dr. Komarovsky o.s.frv. ætti að opna.
Greining á núverandi verkfærum
Áður en þú finnur upp þitt eigið reiðhjól, þarftu að gera greiningu á núverandi reiðhjólum og skilja hvort við þurfum virkilega á því að halda og líklega erum við ekki þeir einu sem höfum hugsað um þörfina fyrir svona hagnýtt reiðhjól.
Að googla á netinu (við virðumst gúgla venjulega), auk þess að leita á Github með því að nota leitarorðin „reverse socks“ gaf ekki margar niðurstöður. Í grundvallaratriðum snýst þetta allt um að byggja ssh göng með öfugframsendingu hafnar og allt sem tengist því. Til viðbótar við SSH göng eru nokkrar lausnir:
Langvarandi útfærsla á öfugum göngum frá strákunum í Kaspersky Lab. Nafnið gefur skýrt til hvers þetta handrit er ætlað. Göngin eru útfærð í Python 2.7 og starfa í skýrum textaham (eins og það er í tísku að segja núna - halló RKN)
Önnur útfærsla í Python, einnig í skýrum texta, en með fleiri möguleikum. Það er skrifað sem eining og hefur API til að samþætta lausnina í verkefnum þínum.
Fyrsti hlekkurinn er upprunalega útgáfan af öfugri sox útfærslunni í Golang (ekki studd af þróunaraðilanum).
Seinni hlekkurinn er endurskoðun okkar með viðbótareiginleikum, einnig í Golang. Í útgáfunni okkar innleiddum við SSL, vinnum í gegnum umboð með NTLM heimild, heimild á viðskiptavininum, áfangasíðu ef um rangt lykilorð er að ræða (eða öllu heldur, tilvísun á áfangasíðuna), fjölþráða stillingu (þ.e.a.s. nokkrir einstaklingar getur unnið með göngin á sama tíma), kerfi til að pinga viðskiptavininn til að ákvarða hvort hann sé á lífi eða ekki.
Útfærsla á öfugri sox frá „kínverskum vinum okkar“ í Python. Þar, fyrir lata og „ódauðlega“, er tilbúið tvískipt (exe), sett saman af Kínverjum og tilbúið til notkunar. Hér veit aðeins kínverski guðinn hvað annað þessi tvöfaldur getur innihaldið fyrir utan aðalvirknina, svo notaðu á eigin hættu og áhættu.
Alveg áhugavert verkefni í C++ til að útfæra reverse sox og fleira. Til viðbótar við bakgöngin getur það framsent höfn, búið til skipanaskel osfrv.
MSF mæliþrýstimaður
Hér, eins og þeir segja, engar athugasemdir. Allir jafnvel meira og minna menntaðir tölvuþrjótar kannast vel við þennan hlut og skilja hversu auðvelt er að greina það með öryggisverkfærum.
Öll verkfærin sem lýst er hér að ofan virka með svipaðri tækni: fyrirfram tilbúin keyranleg tvíundareining er sett á vél innan netsins, sem kemur á tengingu við ytri netþjón. Miðlarinn rekur SOCKS4/5 netþjón sem tekur við tengingum og miðlar þeim til viðskiptavinarins.
Ókosturinn við öll ofangreind verkfæri er að annaðhvort Python eða Golang verður að vera uppsett á biðlaravélinni (hefurðu oft séð Python uppsett á vélum t.d. fyrirtækisstjóra eða skrifstofustarfsmanna?), eða forsamsettan binary (reyndar python) verður að draga inn á þessa vél og skriftu í einni flösku) og keyra þetta binary þegar þar. Og að hala niður exe og síðan ræsa það er líka undirskrift fyrir staðbundið vírusvarnarefni eða HIPS.
Almennt segir niðurstaðan sig sjálf - við þurfum powershell lausn. Nú munu tómatar fljúga til okkar - þeir segja að powershell sé nú þegar allt í hakk, það sé fylgst með, læst osfrv. og svo framvegis. Reyndar ekki alls staðar. Við lýsum yfir ábyrgan. Við the vegur, það eru margar leiðir til að komast framhjá blokkun (hér er aftur smart setning um halló RKN 🙂), frá heimskulegu endurnefna powershell.exe -> cmdd.exe og endar á powerdll o.s.frv.
Við skulum byrja að finna upp
Það er ljóst að fyrst munum við líta á Google og... við finnum ekkert um þetta efni (ef einhver hefur fundið það, settu tengla í athugasemdirnar). Það er aðeins Socks5 á powershell, en þetta er venjulegur „beinn“ sox, sem hefur ýmsa sína ókosti (við tölum um þá síðar). Þú getur auðvitað, með örlítilli hreyfingu, breytt henni í hina öfugu, en þetta verður bara einþráður sox, sem er ekki alveg það sem við þurfum fyrir okkur.
Svo við höfum ekki fundið neitt tilbúið, svo við verðum samt að finna upp hjólið okkar. Við munum taka sem grunn fyrir hjólið okkar reverse sox í Golang, og við innleiðum viðskiptavin fyrir það í powershell.
RSocksTun
Svo hvernig virkar rsockstun?
Rekstur RsocksTun (hér eftir nefnt rs) er byggður á tveimur hugbúnaðarhlutum - Yamux og Socks5 netþjóni. Socks5 þjónn er venjulegur staðbundinn socks5, hann keyrir á biðlaranum. Og margföldun tenginga við það (munið þið eftir fjölþráðum?) er veitt með yamux (). Þetta kerfi gerir þér kleift að ræsa nokkra biðlara socks5 netþjóna og dreifa utanaðkomandi tengingum til þeirra, senda þær í gegnum eina eina TCP tengingu (næstum eins og í metraforriti) frá biðlara til netþjóns, og útfæra þar með fjölþráða ham, án þess verðum við einfaldlega ekki fær um að vinna að fullu í innri netum.
Kjarninn í því hvernig yamux virkar er að hann kynnir til viðbótar netlag af straumum og útfærir það í formi 12 bæta haus fyrir hvern pakka. (Hér notum við vísvitandi orðið „straumur“ frekar en þráður, til að rugla ekki lesandann saman við „þráð“ forritstraums - við munum líka nota þetta hugtak í þessari grein). Yamux hausinn inniheldur straumnúmerið, fána til að setja upp/loka straumnum, fjölda bæta sem flutt eru og stærð flutningsgluggans.
Auk þess að setja upp/loka straumi, innleiðir yamux keepalive kerfi sem gerir þér kleift að fylgjast með frammistöðu hinnar staðfestu samskiptarásar. Rekstur keeplive skilaboðakerfisins er stilltur þegar Yamux fundur er búinn til. Reyndar eru af stillingunum aðeins tvær breytur: virkja/slökkva og tíðni pakkasendinga á sekúndum. Keepalive skilaboð geta verið send af yamux netþjóni eða yamux biðlara. Þegar hann tekur á móti keepalive skilaboðum verður ytri aðilinn að svara þeim með því að senda nákvæmlega sama skilaboðaauðkenni (reyndar númer) og hann fékk. Almennt séð er keepalive sama pingið, aðeins fyrir yamux.
Öllum rekstrartækni margfaldans: pakkategundum, uppsetningu tenginga og lúkningarfánum og gagnaflutningsbúnaðinum er lýst í smáatriðum í til yamux.
Niðurstaða að fyrri hluta
Svo, í fyrsta hluta greinarinnar, kynntumst við nokkrum verkfærum til að skipuleggja öfug göng, skoðuðum kosti þeirra og galla, rannsökuðum gangverk Yamux multiplexer og lýstum grunnkröfum fyrir nýstofnaða powershell eininguna. Í næsta hluta munum við þróa eininguna sjálfa, nánast frá grunni. Framhald. Ekki skipta :)
Heimild: www.habr.com