Vi skriver Reverse socks5 proxy på powershell.Del 1

En historie om forskning og utvikling i 3 deler. Del 1 er utforskende.
Det er mange bøketrær - enda flere fordeler.

Formulering av problemet

Under pentests og RedTeam-kampanjer er det ikke alltid mulig å bruke kundens standardverktøy, som VPN, RDP, Citrix osv. som et anker for å komme inn i det interne nettverket. Noen steder fungerer en standard VPN ved hjelp av MFA og en maskinvaretoken brukes som en andre faktor, andre steder overvåkes det brutalt og VPN-påloggingen vår blir umiddelbart synlig, som de sier, med alt det innebærer, men i andre er det rett og slett ingen slike midler.

I slike tilfeller må vi hele tiden lage såkalte «omvendte tunneler» - forbindelser fra det interne nettverket til en ekstern ressurs eller en server vi kontrollerer. Inne i en slik tunnel kan vi allerede jobbe med kundenes interne ressurser.

Det finnes flere varianter av disse returtunnelene. Den mest kjente av dem er selvfølgelig Meterpreter. SSH-tunneler med omvendt portvideresending er også etterspurt blant hackermassene. Det er ganske mange midler for å implementere omvendt tunneling, og mange av dem er godt studert og beskrevet.
Selvfølgelig, på sin side, står ikke utviklere av sikkerhetsløsninger til side og oppdager aktivt slike handlinger.
For eksempel oppdages MSF-økter vellykket av moderne IPS fra Cisco eller Positive Tech, og en omvendt SSH-tunnel kan oppdages av nesten hvilken som helst normal brannmur.

Derfor, for å forbli ubemerket i en god RedTeam-kampanje, må vi bygge en omvendt tunnel ved å bruke ikke-standardiserte midler og tilpasse oss så tett som mulig til den virkelige driftsmodusen til nettverket.

La oss prøve å finne eller finne på noe lignende.

Før vi finner opp noe, må vi forstå hvilket resultat vi ønsker å oppnå, hvilke funksjoner utviklingen vår skal utføre. Hva vil være kravene til tunnelen slik at vi kan jobbe i maksimal stealth-modus?

Det er klart at for hvert enkelt tilfelle kan slike krav variere sterkt, men basert på arbeidserfaring kan de viktigste identifiseres:

  • fungerer på Windows-7-10 OS. Siden de fleste bedriftsnettverk bruker Windows;
  • klienten kobler til serveren via SSL for å unngå dum lytting ved å bruke ips;
  • Ved tilkobling må klienten støtte arbeid gjennom en proxy-server med autorisasjon, pga I mange selskaper skjer tilgang til Internett gjennom en proxy. Faktisk kan det hende at klientmaskinen ikke engang vet noe om det, og proxyen brukes i en gjennomsiktig modus. Men vi må sørge for slik funksjonalitet;
  • klientdelen skal være kortfattet og bærbar;
    Det er klart at for å jobbe innenfor kundens nettverk, kan du installere OpenVPN på klientmaskinen og lage en fullverdig tunnel til serveren din (heldigvis kan openvpn-klienter fungere gjennom en proxy). Men for det første vil dette ikke alltid fungere, siden vi kanskje ikke er lokale administratorer der, og for det andre vil det lage så mye støy at en anstendig SIEM eller HIPS umiddelbart vil "snakke" på oss. Ideelt sett bør klienten vår være en såkalt inline-kommando, da for eksempel mange bash-skjell er implementert, og lansert via kommandolinjen, for eksempel når man utfører kommandoer fra en ordmakro.
  • tunnelen vår må være flertrådet og støtte mange forbindelser samtidig;
  • klient-server-forbindelsen må ha en form for autorisasjon slik at tunnelen etableres kun for vår klient, og ikke for alle som kommer til vår server på oppgitt adresse og port. Ideelt sett bør en landingsside med katter eller profesjonelle emner relatert til det opprinnelige domenet åpnes for «tredjepartsbrukere».
    For eksempel, hvis kunden er en medisinsk organisasjon, så for en informasjonssikkerhetsadministrator som bestemmer seg for å sjekke ressursen som en klinikkansatt har tilgang til, en side med farmasøytiske produkter, Wikipedia med en beskrivelse av diagnosen, eller Dr. Komarovskys blogg osv. skal åpne.

Analyse av eksisterende verktøy

Før du finner opp din egen sykkel på nytt, må du gjøre en analyse av eksisterende sykler og forstå om vi virkelig trenger den, og sannsynligvis er vi ikke de eneste som har tenkt på behovet for en så funksjonell sykkel.

Googling på Internett (vi ser ut til å google normalt), samt søk på Github ved å bruke søkeordene "reverse socks" ga ikke mange resultater. I utgangspunktet handler det om å bygge ssh-tunneler med omvendt portvideresending og alt som er forbundet med det. I tillegg til SSH-tunneler finnes det flere løsninger:

github.com/klsecservices/rpivot
En langvarig implementering av en omvendt tunnel fra gutta ved Kaspersky Lab. Navnet gjør det klart hva dette manuset er ment for. Implementert i Python 2.7, fungerer tunnelen i klartekstmodus (som det er mote å si nå - hei RKN)

github.com/tonyseek/rsocks
Nok en implementering i Python, også i klartekst, men med flere muligheter. Den er skrevet som en modul og har en API for å integrere løsningen i prosjektene dine.

github.com/llkat/rsockstun
github.com/mis-team/rsockstun
Den første lenken er den originale versjonen av den omvendte sox-implementeringen i Golang (støttes ikke av utvikleren).
Den andre lenken er vår revisjon med tilleggsfunksjoner, også i Golang. I vår versjon implementerte vi SSL, jobber gjennom en proxy med NTLM-autorisasjon, autorisasjon på klienten, en landingsside i tilfelle feil passord (eller rettere sagt, en omdirigering til landingssiden), flertrådsmodus (dvs. flere personer kan jobbe med tunnelen samtidig) , et system for å pinge klienten for å finne ut om han er i live eller ikke.

github.com/jun7th/tsocks
Implementering av omvendt sox fra våre "kinesiske venner" i Python. Der, for de late og "udødelige", er det en ferdig binær (exe), satt sammen av kineserne og klar til bruk. Her er det bare den kinesiske guden som vet hva annet denne binærfilen kan inneholde i tillegg til hovedfunksjonaliteten, så bruk på egen risiko og risiko.

github.com/securesocketfunneling/ssf
Ganske interessant prosjekt i C++ for implementering av reverse sox og mer. I tillegg til omvendt tunnel, kan den gjøre portvideresending, lage et kommandoskall osv.

Leger Uten Grenser målertolk
Her, som de sier, ingen kommentarer. Alle enda mer eller mindre utdannede hackere er godt kjent med denne tingen og forstår hvor lett det kan oppdages av sikkerhetsverktøy.

Alle verktøyene beskrevet ovenfor fungerer ved hjelp av en lignende teknologi: en forhåndsforberedt kjørbar binær modul lanseres på en maskin inne i nettverket, som etablerer en forbindelse med en ekstern server. Serveren kjører en SOCKS4/5-server som aksepterer tilkoblinger og videresender dem til klienten.

Ulempen med alle de ovennevnte verktøyene er at enten Python eller Golang må installeres på klientmaskinen (har du ofte sett Python installert på maskinene til for eksempel en bedriftsdirektør eller kontorarbeidere?), eller en forhåndsmontert binær (egentlig python) må dras inn på denne maskinen og skriptet i én flaske) og kjøre denne binærfilen allerede der. Og å laste ned en exe og deretter starte den er også en signatur for et lokalt antivirus eller HIPS.

Generelt tyder konklusjonen seg selv – vi trenger en powershell-løsning. Nå vil tomater fly mot oss - de sier at powershell allerede er ødelagt, det er overvåket, blokkert osv. og så videre. Faktisk ikke overalt. Vi erklærer ansvarlig. Forresten, det er mange måter å omgå blokkering på (her er det igjen en fasjonabel setning om hei RKN 🙂), fra det dumme omdøpet til powershell.exe -> cmdd.exe og slutter med powerdll, etc.

La oss begynne å finne opp

Det er klart at først skal vi se på Google og ... vi vil ikke finne noe om dette emnet (hvis noen har funnet det, legg ut linker i kommentarene). Det er kun realisering av Socks5 på powershell, men dette er en vanlig "direkte" sox, som har en rekke av sine egne ulemper (vi skal snakke om dem senere). Du kan selvfølgelig, med en liten bevegelse av hånden, gjøre den om til den omvendte, men dette vil bare være entrådet sox, som ikke er helt det vi trenger for oss.

Så vi har ikke funnet noe ferdig, så vi må fortsatt finne opp hjulet vårt på nytt. Vi vil ta utgangspunkt i sykkelen vår utviklingen vår reverse sox i Golang, og vi implementerer en klient for det i powershell.

RSocksTun
Så hvordan fungerer rsockstun?

Driften av RsocksTun (heretter referert til som rs) er basert på to programvarekomponenter - Yamux og Socks5 server. Socks5-serveren er en vanlig lokal socks5, den kjører på klienten. Og multipleksing av tilkoblinger til den (husker du om multithreading?) er gitt ved hjelp av yamux (enda en multiplekser). Dette opplegget lar deg starte flere klientsocks5-servere og distribuere eksterne tilkoblinger til dem, videresende dem gjennom én enkelt TCP-tilkobling (nesten som i meterpreter) fra klient til server, og dermed implementere en flertrådsmodus, uten hvilken vi rett og slett ikke vil være i stand til å jobbe fullt ut i de interne nettverkene.

Essensen av hvordan yamux fungerer er at den introduserer et ekstra nettverkslag med strømmer, og implementerer det i form av en 12-byte header for hver pakke. (Her bruker vi bevisst ordet "strøm" i stedet for tråd, for ikke å forvirre leseren med en programstrøm "tråd" - vi vil også bruke dette konseptet i denne artikkelen). Yamux-headeren inneholder strømnummeret, flagg for installasjon/avslutning av strømmen, antall byte som er overført og størrelsen på overføringsvinduet.

Vi skriver Reverse socks5 proxy på powershell.Del 1

I tillegg til å installere/avslutte en strøm, implementerer yamux en keepalive-mekanisme som lar deg overvåke ytelsen til den etablerte kommunikasjonskanalen. Driften av keeplive-meldingsmekanismen konfigureres når du oppretter en Yamux-sesjon. Av innstillingene er det faktisk bare to parametere: aktiver/deaktiver og frekvensen for sending av pakker i sekunder. Keepalive-meldinger kan sendes av en yamux-server eller en yamux-klient. Når den mottar en Keepalive-melding, må den eksterne parten svare på den ved å sende nøyaktig samme meldingsidentifikator (faktisk et nummer) som den mottok. Generelt er keepalive den samme ping, bare for yamux.

Hele driftsteknikken til multiplekseren: pakketyper, tilkoblingsoppsett og termineringsflagg, og dataoverføringsmekanismen er beskrevet i detalj i spesifikasjoner til yamux.

Konklusjon til første del

Så i den første delen av artikkelen ble vi kjent med noen verktøy for å organisere omvendte tunneler, så på fordelene og ulempene deres, studerte operasjonsmekanismen til Yamux-multiplekseren og beskrev de grunnleggende kravene til den nyopprettede powershell-modulen. I neste del skal vi utvikle selve modulen, praktisk talt fra bunnen av. Fortsettelse følger. Ikke bytt :)

Kilde: www.habr.com

Legg til en kommentar