En historie om forskning og udvikling i 3 dele. Del 1 er undersøgende.
Der er mange bøgetræer – endnu flere fordele.
Formulering af problemet
Under pentests og RedTeam-kampagner er det ikke altid muligt at bruge Kundens standardværktøjer, såsom VPN, RDP, Citrix osv. som et anker for at komme ind i det interne netværk. Nogle steder fungerer en standard VPN ved hjælp af MFA og en hardware token bruges som en anden faktor, andre steder bliver det brutalt overvåget og vores VPN login bliver umiddelbart synligt, som man siger, med alt hvad det indebærer, men i andre er der simpelthen ingen sådan midler.
I sådanne tilfælde skal vi hele tiden lave såkaldte "omvendte tunneler" - forbindelser fra det interne netværk til en ekstern ressource eller en server, vi kontrollerer. Inde i sådan en tunnel kan vi allerede arbejde med Kundernes interne ressourcer.
Der er flere varianter af disse returtunneler. Den mest kendte af dem er naturligvis Meterpreter. SSH-tunneler med reverse port forwarding er også efterspurgt blandt hackermasserne. Der er en hel del midler til at implementere omvendt tunneling, og mange af dem er godt undersøgt og beskrevet.
Selvfølgelig står udviklere af sikkerhedsløsninger på deres side ikke til side og registrerer aktivt sådanne handlinger.
For eksempel er MSF-sessioner med succes opdaget af moderne IPS fra Cisco eller Positive Tech, og en omvendt SSH-tunnel kan detekteres af næsten enhver normal firewall.
Derfor, for at forblive ubemærket i en god RedTeam-kampagne, skal vi bygge en omvendt tunnel ved hjælp af ikke-standardiserede midler og tilpasse os så tæt som muligt til netværkets reelle driftstilstand.
Lad os prøve at finde eller opfinde noget lignende.
Før vi opfinder noget, skal vi forstå, hvilket resultat vi ønsker at opnå, hvilke funktioner vores udvikling skal udføre. Hvad bliver kravene til tunnelen, så vi kan arbejde i maksimal stealth mode?
Det er klart, at sådanne krav i hvert enkelt tilfælde kan variere meget, men baseret på erhvervserfaring kan de vigtigste identificeres:
- arbejde på Windows-7-10 OS. Da de fleste virksomhedsnetværk bruger Windows;
- klienten opretter forbindelse til serveren via SSL for at undgå dum lytning ved hjælp af ips;
- Ved tilslutning skal klienten understøtte arbejde gennem en proxyserver med autorisation, pga I mange virksomheder sker adgangen til internettet via en proxy. Faktisk ved klientmaskinen måske ikke engang noget om det, og proxyen bruges i en gennemsigtig tilstand. Men vi skal levere en sådan funktionalitet;
- klientdelen skal være kortfattet og bærbar;
Det er klart, at for at arbejde inden for kundens netværk kan du installere OpenVPN på klientmaskinen og oprette en fuldgyldig tunnel til din server (heldigvis kan openvpn-klienter arbejde gennem en proxy). Men for det første vil dette ikke altid fungere, da vi måske ikke er lokale administratorer der, og for det andet vil det larme så meget, at en anstændig SIEM eller HIPS straks vil "snakke" på os. Ideelt set bør vores klient være en såkaldt inline-kommando, da for eksempel mange bash-skaller er implementeret, og lanceret via kommandolinjen, for eksempel ved udførelse af kommandoer fra en ordmakro. - vores tunnel skal være flertrådet og understøtte mange forbindelser samtidigt;
- klient-server-forbindelsen skal have en form for autorisation, så tunnelen kun etableres for vores klient, og ikke for alle, der kommer til vores server på den angivne adresse og port. Ideelt set bør en landingsside med katte eller professionelle emner relateret til det originale domæne åbne for "tredjepartsbrugere".
For eksempel, hvis kunden er en medicinsk organisation, så for en informationssikkerhedsadministrator, der beslutter sig for at kontrollere den ressource, som en klinikmedarbejder fik adgang til, en side med farmaceutiske produkter, Wikipedia med en beskrivelse af diagnosen eller Dr. Komarovskys blog osv. skal åbne.
Analyse af eksisterende værktøjer
Før du genopfinder din egen cykel, skal du lave en analyse af eksisterende cykler og forstå, om vi virkelig har brug for den, og vi er sandsynligvis ikke de eneste, der har tænkt over behovet for en sådan funktionel cykel.
At google på internettet (vi ser ud til at google normalt), samt at søge på Github ved hjælp af søgeordene "reverse socks" gav ikke mange resultater. Grundlæggende handler det hele om at bygge ssh-tunneler med omvendt port forwarding og alt, der er forbundet med det. Ud over SSH-tunneler er der flere løsninger:
En langvarig implementering af en omvendt tunnel fra fyrene på Kaspersky Lab. Navnet gør det klart, hvad dette script er beregnet til. Implementeret i Python 2.7, fungerer tunnelen i klarteksttilstand (som det er moderne at sige nu - hej RKN)
Endnu en implementering i Python, også i klartekst, men med flere muligheder. Det er skrevet som et modul og har en API til at integrere løsningen i dine projekter.
Det første link er den originale version af den omvendte sox-implementering i Golang (ikke understøttet af udvikleren).
Det andet link er vores revision med yderligere funktioner, også i Golang. I vores version implementerede vi SSL, arbejdede gennem en proxy med NTLM-autorisation, autorisation på klienten, en landingsside i tilfælde af en forkert adgangskode (eller rettere, en omdirigering til landingssiden), multi-threaded mode (dvs. flere personer kan arbejde med tunnelen på samme tid), et system til at pinge klienten for at afgøre, om han er i live eller ej.
Implementering af reverse sox fra vores "kinesiske venner" i Python. Der, for de dovne og "udødelige", er der en færdiglavet binær (exe), samlet af kineserne og klar til brug. Her er det kun den kinesiske gud, der ved, hvad denne binære fil ellers kan indeholde udover hovedfunktionaliteten, så brug på egen risiko.
Et ganske interessant projekt i C++ til implementering af reverse sox og mere. Ud over den omvendte tunnel kan den lave port forwarding, oprette en kommandoskal osv.
Læger uden Grænser målertolk
Her, som de siger, ingen kommentarer. Alle selv mere eller mindre uddannede hackere er meget fortrolige med denne ting og forstår, hvor let det kan opdages af sikkerhedsværktøjer.
Alle de værktøjer, der er beskrevet ovenfor, fungerer ved hjælp af en lignende teknologi: et forudforberedt eksekverbart binært modul lanceres på en maskine inde i netværket, som etablerer en forbindelse med en ekstern server. Serveren kører en SOCKS4/5-server, der accepterer forbindelser og videresender dem til klienten.
Ulempen ved alle ovenstående værktøjer er, at enten Python eller Golang skal installeres på klientmaskinen (har du ofte set Python installeret på f.eks. en virksomhedsdirektørs eller kontormedarbejders maskiner?), eller en færdigmonteret binær (faktisk python) skal trækkes ind på denne maskine og script i én flaske) og køre denne binære allerede der. Og at downloade en exe og derefter starte den er også en signatur for et lokalt antivirus eller HIPS.
Generelt tyder konklusionen sig selv - vi har brug for en powershell-løsning. Nu vil tomater flyve mod os - de siger, at powershell allerede er helt afhugget, det er overvåget, blokeret osv. og så videre. Faktisk ikke alle steder. Vi erklærer ansvarligt. Forresten er der mange måder at omgå blokering på (her er der igen en moderigtig sætning om hej RKN 🙂), startende fra den dumme omdøbning af powershell.exe -> cmdd.exe og slutter med powerdll osv.
Lad os begynde at opfinde
Det er klart, at vi først kigger på Google, og... vi finder ikke noget om dette emne (hvis nogen har fundet det, så send links i kommentarerne). Der er kun Socks5 på powershell, men dette er en almindelig "direkte" sox, som har en række af sine egne ulemper (vi taler om dem senere). Du kan selvfølgelig, med en lille bevægelse af hånden, vende den til den omvendte, men dette vil kun være entrådet sox, hvilket ikke helt er, hvad vi har brug for til os.
Så vi har ikke fundet noget færdiglavet, så vi bliver stadig nødt til at genopfinde vores hjul. Vi vil tage udgangspunkt i vores cykel reverse sox i Golang, og vi implementerer en klient til det i powershell.
RSocksTun
Så hvordan virker rsockstun?
Driften af RsocksTun (herefter benævnt rs) er baseret på to softwarekomponenter - Yamux og Socks5 server. Socks5-serveren er en almindelig lokal socks5, den kører på klienten. Og multipleksing af forbindelser til det (husker du om multithreading?) leveres ved hjælp af yamux (). Denne ordning giver dig mulighed for at starte flere klient socks5-servere og distribuere eksterne forbindelser til dem, videresende dem gennem en enkelt TCP-forbindelse (næsten som i meterpreter) fra klient til server, og derved implementere en multi-threaded mode, uden hvilken vi simpelthen ikke vil være i stand til fuldt ud at arbejde i de interne netværk.
Essensen af, hvordan yamux fungerer, er, at den introducerer et ekstra netværkslag af streams, der implementerer det i form af en 12-byte header for hver pakke. (Her bruger vi bevidst ordet "stream" frem for tråd, for ikke at forveksle læseren med en programstrøm "tråd" - vi vil også bruge dette koncept i denne artikel). Yamux-headeren indeholder streamnummeret, flag for installation/afslutning af streamen, antallet af overførte bytes og størrelsen af transfervinduet.
Udover at installere/afslutte en stream, implementerer yamux en keepalive-mekanisme, der giver dig mulighed for at overvåge ydeevnen af den etablerede kommunikationskanal. Betjeningen af keeplive-meddelelsesmekanismen konfigureres, når der oprettes en Yamux-session. Faktisk er der kun to parametre af indstillingerne: aktiver/deaktiver og hyppigheden af afsendelse af pakker i sekunder. Keepalive-meddelelser kan sendes af en yamux-server eller en yamux-klient. Når den eksterne part modtager en keepalive-besked, skal den svare på den ved at sende nøjagtig den samme besked-id (faktisk et nummer), som den modtog. Generelt er keepalive det samme ping, kun for yamux.
Hele multiplexerens driftsteknik: pakketyper, forbindelsesopsætning og afslutningsflag og dataoverførselsmekanismen er beskrevet detaljeret i til yamux.
Konklusion på første del
Så i den første del af artiklen stiftede vi bekendtskab med nogle værktøjer til at organisere omvendte tunneler, så på deres fordele og ulemper, studerede Yamux-multiplexerens funktionsmekanisme og beskrev de grundlæggende krav til det nyoprettede powershell-modul. I næste del vil vi udvikle selve modulet, praktisk talt fra bunden. Fortsættes. Skift ikke :)
Kilde: www.habr.com