'n Verhaal oor navorsing en ontwikkeling in 3 dele. Deel 1 is verkennend.
Daar is baie beukebome – selfs meer voordele.
Probleemstelling
Tydens pentests en RedTeam-veldtogte is dit nie altyd moontlik om die kliënt se standaardgereedskap, soos VPN, RDP, Citrix, ens. as 'n anker om die interne netwerk binne te gaan. Op sommige plekke werk 'n standaard VPN met MFA en word 'n hardeware-token as 'n tweede faktor gebruik, in ander word dit wreed gemonitor en word ons VPN-aanmelding onmiddellik sigbaar, soos hulle sê, met alles wat dit impliseer, maar in ander is daar eenvoudig nie so 'n middel nie.
In sulke gevalle moet ons voortdurend sogenaamde “omgekeerde tonnels” maak - verbindings van die interne netwerk na 'n eksterne hulpbron of 'n bediener wat ons beheer. Binne so 'n tonnel kan ons reeds met die Kliënte se interne hulpbronne werk.
Daar is verskeie variëteite van hierdie terugkeertonnels. Die bekendste van hulle is natuurlik Meterpreter. SSH-tonnels met omgekeerde hawe-aanstuur is ook in groot aanvraag onder die hacker-massas. Daar is nogal baie maniere om omgekeerde tonnel te implementeer en baie van hulle is goed bestudeer en beskryf.
Natuurlik staan ontwikkelaars van sekuriteitsoplossings nie opsy nie en bespeur hulle aktief sulke aksies.
MSF-sessies word byvoorbeeld suksesvol opgespoor deur moderne IPS van Cisco of Positive Tech, en 'n omgekeerde SSH-tonnel kan deur byna enige normale firewall opgespoor word.
Daarom, om ongemerk te bly in 'n goeie RedTeam-veldtog, moet ons 'n omgekeerde tonnel bou deur nie-standaard middele te gebruik en so na as moontlik aan te pas by die werklike bedryfsmodus van die netwerk.
Kom ons probeer iets soortgelyks vind of uitvind.
Voordat ons iets uitvind, moet ons verstaan watter resultaat ons wil bereik, watter funksies ons ontwikkeling moet verrig. Wat sal die vereistes vir die tonnel wees sodat ons in maksimum stealth-modus kan werk?
Dit is duidelik dat sulke vereistes vir elke geval baie kan verskil, maar op grond van werkservaring kan die belangrikstes geïdentifiseer word:
- werk op Windows-7-10 OS. Aangesien die meeste korporatiewe netwerke Windows gebruik;
- die kliënt koppel aan die bediener via SSL om dom luister met ips te vermy;
- By koppeling moet die kliënt werk deur 'n instaanbediener met magtiging ondersteun, want In baie maatskappye vind toegang tot die internet plaas deur middel van 'n instaanbediener. Trouens, die kliëntmasjien weet dalk nie eers iets daarvan nie, en die instaanbediener word in 'n deursigtige modus gebruik. Maar ons moet sulke funksionaliteit verskaf;
- die kliëntgedeelte moet bondig en draagbaar wees;
Dit is duidelik dat om binne die kliënt se netwerk te werk, u OpenVPN op die kliëntmasjien kan installeer en 'n volwaardige tonnel na u bediener kan skep (gelukkig kan openvpn-kliënte deur 'n instaanbediener werk). Maar, eerstens, dit sal nie altyd werk nie, aangesien ons dalk nie plaaslike administrateurs daar is nie, en tweedens sal dit soveel geraas maak dat 'n ordentlike SIEM of HIPS ons dadelik sal "snuffel". Ideaal gesproke moet ons kliënt 'n sogenaamde inlyn-opdrag wees, aangesien byvoorbeeld baie bash-skulpe geïmplementeer word, en via die opdragreël geloods word, byvoorbeeld wanneer opdragte vanaf 'n woordmakro uitgevoer word. - ons tonnel moet multi-draad wees en baie verbindings gelyktydig ondersteun;
- die kliënt-bediener-verbinding moet 'n soort magtiging hê sodat die tonnel slegs vir ons kliënt gevestig word, en nie vir almal wat na ons bediener kom by die gespesifiseerde adres en poort nie. Ideaal gesproke moet 'n bestemmingsbladsy met katte of professionele onderwerpe wat verband hou met die oorspronklike domein oopmaak vir "derdeparty-gebruikers."
Byvoorbeeld, as die kliënt 'n mediese organisasie is, dan vir 'n inligtingsekuriteitsadministrateur wat besluit om die hulpbron waartoe 'n kliniekwerknemer toegang verkry het, 'n bladsy met farmaseutiese produkte, Wikipedia met 'n beskrywing van die diagnose, of Dr. Komarovsky se blog, ens. moet oopmaak.
Ontleding van bestaande gereedskap
Voordat jy jou eie fiets herontdek, moet jy 'n ontleding van bestaande fietse doen en verstaan of ons dit regtig nodig het en, waarskynlik, ons is nie die enigstes wat gedink het oor die behoefte aan so 'n funksionele fiets nie.
Om op die internet te google (dit lyk of ons normaalweg google), sowel as om op Github te soek deur die sleutelwoorde “omgekeerde sokkies” te gebruik, het nie baie resultate opgelewer nie. Basies kom dit alles neer op die bou van ssh-tonnels met omgekeerde hawe-aanstuur en alles wat daarmee verband hou. Benewens SSH-tonnels, is daar verskeie oplossings:
'n Langdurige implementering van 'n omgekeerde tonnel van die ouens by Kaspersky Lab. Die naam maak dit duidelik waarvoor hierdie draaiboek bedoel is. Die tonnel, wat in Python 2.7 geïmplementeer is, werk in duidelike teksmodus (soos dit nou modieus is om te sê - hallo RKN)
Nog 'n implementering in Python, ook in duidelike teks, maar met meer moontlikhede. Dit is as 'n module geskryf en het 'n API om die oplossing in jou projekte te integreer.
Die eerste skakel is die oorspronklike weergawe van die omgekeerde sox-implementering in Golang (nie deur die ontwikkelaar ondersteun nie).
Die tweede skakel is ons hersiening met bykomende kenmerke, ook in Golang. In ons weergawe het ons SSL geïmplementeer, werk deur 'n instaanbediener met NTLM-magtiging, magtiging op die kliënt, 'n bestemmingsbladsy in die geval van 'n verkeerde wagwoord (of eerder 'n herleiding na die bestemmingsbladsy), multi-draadmodus (d.w.s. verskeie mense kan terselfdertyd met die tonnel werk), 'n stelsel om die kliënt te ping om te bepaal of hy lewe of nie.
Implementering van omgekeerde sox van ons "Chinese vriende" in Python. Daar, vir die lui en "onsterflike", is daar 'n klaargemaakte binêre (exe), saamgestel deur die Chinese en gereed vir gebruik. Hier weet net die Chinese God wat anders hierdie binêre kan bevat behalwe die hooffunksie, so gebruik dit op eie risiko en risiko.
Nogal 'n interessante projek in C++ vir die implementering van reverse sox en meer. Benewens die omgekeerde tonnel, kan dit poortaanstuur doen, 'n opdragdop skep, ens.
MSF meterpreter
Hier, soos hulle sê, geen kommentaar nie. Alle selfs meer of minder opgevoede hackers is baie bekend met hierdie ding en verstaan hoe maklik dit deur sekuriteitsnutsmiddels opgespoor kan word.
Al die gereedskap wat hierbo beskryf word, werk met 'n soortgelyke tegnologie: 'n vooraf voorbereide uitvoerbare binêre module word op 'n masjien binne die netwerk geloods, wat 'n verbinding met 'n eksterne bediener tot stand bring. Die bediener bestuur 'n SOCKS4/5-bediener wat verbindings aanvaar en aan die kliënt herlei.
Die nadeel van al die bogenoemde gereedskap is dat Python of Golang op die kliëntmasjien geïnstalleer moet word (het jy al dikwels gesien hoe Python geïnstalleer is op die masjiene van byvoorbeeld 'n maatskappydirekteur of kantoorwerkers?), Of 'n vooraf saamgestelde binêr (eintlik python) moet na hierdie masjien gesleep word en script in een bottel) en laat hierdie binêre reeds daar hardloop. En om 'n exe af te laai en dan te begin, is ook 'n handtekening vir 'n plaaslike antivirus of HIPS.
Oor die algemeen suggereer die gevolgtrekking homself - ons het 'n powershell-oplossing nodig. Nou sal tamaties op ons afvlieg - hulle sê powershell is alreeds alles afgesaag, dit word gemonitor, geblokkeer, ens. en so aan. Trouens, nie oral nie. Ons verklaar verantwoordelik. Terloops, daar is baie maniere om blokkering te omseil (hier is daar weer 'n modieuse frase oor hallo RKN 🙂), vanaf die dom hernoeming van powershell.exe -> cmdd.exe en eindig met powerdll, ens.
Kom ons begin uitvind
Dit is duidelik dat ons eers op Google sal kyk en ... ons sal niks oor hierdie onderwerp vind nie (as iemand dit gevind het, plaas skakels in die kommentaar). Daar is net Socks5 op powershell, maar dit is 'n gewone "direkte" sox, wat 'n aantal van sy eie nadele het (ons sal later daaroor praat). Jy kan natuurlik, met 'n effense beweging van jou hand, dit in die omgekeerde een verander, maar dit sal net enkel-draad sox wees, wat nie heeltemal is wat ons vir ons nodig het nie.
So, ons het niks klaargemaak gevind nie, so ons sal steeds ons wiel moet herontdek. Ons sal as basis vir ons fiets neem reverse sox in Golang, en ons implementeer 'n kliënt daarvoor in powershell.
RSocksTun
So, hoe werk rsockstun?
Die werking van RsocksTun (hierna na verwys as rs) is gebaseer op twee sagteware komponente - Yamux en Socks5 bediener. Socks5-bediener is 'n gewone plaaslike socks5, dit loop op die kliënt. En vermenigvuldiging van verbindings daaraan (onthou jy van multithreading?) word verskaf met behulp van yamux (). Hierdie skema laat jou toe om verskeie kliënt socks5-bedieners te begin en eksterne verbindings na hulle te versprei, hulle deur een enkele TCP-verbinding (amper soos in meterpreter) van kliënt na bediener aan te stuur, en sodoende 'n multi-draadmodus te implementeer, waarsonder ons eenvoudig nie sal wees nie ten volle in die interne netwerke kan werk.
Die kern van hoe yamux werk, is dat dit 'n bykomende netwerklaag van strome bekendstel, wat dit implementeer in die vorm van 'n 12-grepe kopskrif vir elke pakkie. (Hier gebruik ons doelbewus die woord "stroom" eerder as draad, om nie die leser te verwar met 'n programstroom "draad" nie - ons sal ook hierdie konsep in hierdie artikel gebruik). Die yamux-opskrif bevat die stroomnommer, vlae vir die installering/beëindiging van die stroom, die aantal grepe wat oorgedra is, en die grootte van die oordragvenster.
Benewens die installering/beëindiging van 'n stroom, implementeer yamux 'n Keepalive-meganisme wat jou toelaat om die prestasie van die gevestigde kommunikasiekanaal te monitor. Die werking van die keeplive-boodskapmeganisme word gekonfigureer wanneer 'n Yamux-sessie geskep word. Eintlik, van die instellings is daar net twee parameters: aktiveer/deaktiveer en die frekwensie van die stuur van pakkies in sekondes. Keepalive-boodskappe kan deur 'n yamux-bediener of 'n yamux-kliënt gestuur word. Wanneer 'n lewende boodskap ontvang word, moet die afgeleë party daarop reageer deur presies dieselfde boodskapidentifiseerder (eintlik 'n nommer) te stuur as wat dit ontvang het. Oor die algemeen is keepalive dieselfde ping, net vir yamux.
Die hele bedryfstegniek van die multiplekser: pakkietipes, verbindingsopstelling en beëindigingsvlae, en die data-oordragmeganisme word in detail beskryf in aan yamux.
Gevolgtrekking tot die eerste deel
Dus, in die eerste deel van die artikel het ons kennis gemaak met 'n paar gereedskap om omgekeerde tonnels te organiseer, na hul voor- en nadele gekyk, die werkingsmeganisme van die Yamux-multiplekser bestudeer en die basiese vereistes vir die nuutgeskepte powershell-module beskryf. In die volgende deel gaan ons die module self ontwikkel, prakties van nuuts af. Vervolg. Moenie oorskakel nie :)
Bron: will.com