En berättelse om forskning och utveckling i 3 delar. Del 1 är utforskande.
Det finns många bokträd - ännu fler fördelar.
Problem uttalande
Under pentest och RedTeam-kampanjer är det inte alltid möjligt att använda kundens standardverktyg, såsom VPN, RDP, Citrix, etc. som ett ankare för att komma in i det interna nätverket. På vissa ställen fungerar en standard VPN med hjälp av MFA och en hårdvarutoken används som en andra faktor, på andra övervakas den brutalt och vår VPN-inloggning blir direkt synlig, som man säger, med allt vad det innebär, men på andra finns det helt enkelt inga sådana medel.
I sådana fall måste vi hela tiden göra så kallade ”omvända tunnlar” – kopplingar från det interna nätverket till en extern resurs eller en server vi kontrollerar. Inne i en sådan tunnel kan vi redan arbeta med Kundernas interna resurser.
Det finns flera varianter av dessa returtunnlar. Den mest kända av dem är förstås Meterpreter. SSH-tunnlar med omvänd portforwarding är också mycket efterfrågade bland hackermassorna. Det finns ganska många sätt att implementera omvänd tunneldrivning och många av dem är väl studerade och beskrivna.
Naturligtvis, för sin del, står inte utvecklare av säkerhetslösningar åt sidan och upptäcker aktivt sådana åtgärder.
Till exempel upptäcks MSF-sessioner framgångsrikt av modern IPS från Cisco eller Positive Tech, och en omvänd SSH-tunnel kan upptäckas av nästan vilken normal brandvägg som helst.
Därför, för att förbli obemärkt i en bra RedTeam-kampanj, måste vi bygga en omvänd tunnel med hjälp av icke-standardiserade medel och anpassa oss så nära som möjligt till nätverkets verkliga driftsläge.
Låt oss försöka hitta eller uppfinna något liknande.
Innan vi uppfinner något måste vi förstå vilket resultat vi vill uppnå, vilka funktioner vår utveckling ska fylla. Vilka blir kraven på tunneln så att vi kan arbeta i maximalt smygläge?
Det är tydligt att för varje fall kan sådana krav skilja sig mycket, men baserat på arbetslivserfarenhet kan de viktigaste identifieras:
- fungerar på Windows-7-10 OS. Eftersom de flesta företagsnätverk använder Windows;
- klienten ansluter till servern via SSL för att undvika dumt lyssnande med ips;
- Vid anslutning måste klienten stödja arbete genom en proxyserver med behörighet, eftersom I många företag sker tillgång till Internet via en proxy. Faktum är att klientdatorn kanske inte ens vet något om det, och proxyn används i ett transparent läge. Men vi måste tillhandahålla sådan funktionalitet;
- klientdelen ska vara kortfattad och bärbar;
Det är tydligt att för att arbeta inom kundens nätverk kan du installera OpenVPN på klientdatorn och skapa en fullfjädrad tunnel till din server (lyckligtvis kan openvpn-klienter fungera via en proxy). Men för det första kommer detta inte alltid att fungera, eftersom vi kanske inte är lokala administratörer där, och för det andra kommer det att göra så mycket ljud att en anständig SIEM eller HIPS omedelbart kommer att "snabba" på oss. Helst ska vår klient vara ett så kallat inline-kommando, eftersom till exempel många bash-skal implementeras, och startas via kommandoraden, till exempel när man kör kommandon från ett ordmakro. - vår tunnel måste vara flertrådig och stödja många anslutningar samtidigt;
- klient-server-anslutningen måste ha någon form av behörighet så att tunneln upprättas endast för vår klient, och inte för alla som kommer till vår server på angiven adress och port. Helst bör en målsida med katter eller professionella ämnen relaterade till den ursprungliga domänen öppnas för "tredjepartsanvändare".
Till exempel, om kunden är en medicinsk organisation, då för en informationssäkerhetsadministratör som bestämmer sig för att kontrollera resursen som en klinikanställd har tillgång till, en sida med farmaceutiska produkter, Wikipedia med en beskrivning av diagnosen eller Dr. Komarovskys blogg, etc. ska öppnas.
Analys av befintliga verktyg
Innan du återuppfinner din egen cykel måste du göra en analys av befintliga cyklar och förstå om vi verkligen behöver den och förmodligen är vi inte de enda som har funderat på behovet av en så funktionell cykel.
Att googla på Internet (vi tycks googla normalt), samt att söka på Github med nyckelorden "omvända strumpor" gav inte många resultat. I grund och botten handlar allt om att bygga ssh-tunnlar med omvänd portvidarebefordran och allt som är kopplat till det. Förutom SSH-tunnlar finns det flera lösningar:
En långvarig implementering av en omvänd tunnel från killarna på Kaspersky Lab. Namnet gör det tydligt vad det här manuset är avsett för. Implementerad i Python 2.7, fungerar tunneln i klartextläge (som det är på modet att säga nu - hej RKN)
Ytterligare en implementering i Python, även den i klartext, men med fler möjligheter. Den är skriven som en modul och har ett API för att integrera lösningen i dina projekt.
Den första länken är den ursprungliga versionen av den omvända sox-implementeringen i Golang (stöds inte av utvecklaren).
Den andra länken är vår revision med ytterligare funktioner, även i Golang. I vår version implementerade vi SSL, arbetade genom en proxy med NTLM-auktorisering, auktorisering på klienten, en målsida i händelse av ett felaktigt lösenord (eller snarare en omdirigering till målsidan), flertrådsläge (dvs flera personer kan arbeta med tunneln samtidigt) , ett system för att pinga klienten för att avgöra om han lever eller inte.
Implementering av omvänd sox från våra "kinesiska vänner" i Python. Där, för de lata och "odödliga", finns en färdig binär (exe), sammansatt av kineserna och redo att användas. Här är det bara den kinesiska guden som vet vad mer denna binära kan innehålla förutom huvudfunktionaliteten, så använd på egen risk och risk.
Ganska intressant projekt i C++ för att implementera omvänd sox och mer. Förutom den omvända tunneln kan den göra portvidarebefordran, skapa ett kommandoskal, etc.
Läkare Utan Gränsers mätare
Här, som de säger, inga kommentarer. Alla till och med mer eller mindre utbildade hackare är mycket bekanta med denna sak och förstår hur lätt det kan upptäckas av säkerhetsverktyg.
Alla verktyg som beskrivs ovan fungerar med en liknande teknik: en förberedd körbar binär modul startas på en maskin inuti nätverket, som upprättar en anslutning till en extern server. Servern kör en SOCKS4/5-server som accepterar anslutningar och vidarebefordrar dem till klienten.
Nackdelen med alla ovanstående verktyg är att antingen Python eller Golang måste installeras på klientdatorn (har du ofta sett Python installerad på maskiner av till exempel en företagsdirektör eller kontorsanställda?), eller en förmonterad binär (egentligen python) måste dras till den här maskinen och skriptet i en flaska) och kör denna binär redan där. Och att ladda ner ett exe och sedan starta det är också en signatur för ett lokalt antivirus eller HIPS.
I allmänhet antyder slutsatsen sig själv - vi behöver en powershell-lösning. Nu kommer tomater att flyga mot oss - de säger att powershell redan är helt hackad, den är övervakad, blockerad, etc. och så vidare. Faktiskt inte överallt. Vi deklarerar ansvarsfullt. Förresten, det finns många sätt att kringgå blockering (här finns det återigen en fashionabel fras om hej RKN 🙂), från det dumma namnbytet på powershell.exe -> cmdd.exe och slutar med powerdll, etc.
Låt oss börja uppfinna
Det är tydligt att vi först tittar på Google och... vi kommer inte att hitta något om detta ämne (om någon har hittat det, lägg upp länkar i kommentarerna). Det finns bara Socks5 på powershell, men det här är en vanlig "direkt" sox, som har ett antal egna nackdelar (vi kommer att prata om dem senare). Du kan naturligtvis, med en lätt rörelse av din hand, förvandla den till den omvända, men detta kommer bara att vara entrådig sox, vilket inte riktigt är vad vi behöver för oss.
Så vi har inte hittat något färdigt, så vi måste fortfarande uppfinna vårt hjul på nytt. Vi kommer att ta som grund för vår cykel reverse sox i Golang, och vi implementerar en klient för det i powershell.
RSocksTun
Så hur fungerar rsockstun?
Driften av RsocksTun (nedan kallad rs) är baserad på två mjukvarukomponenter - Yamux och Socks5 server. Socks5-servern är en vanlig lokal socks5, den körs på klienten. Och multiplexering av anslutningar till den (minns du om multithreading?) tillhandahålls med yamux (). Detta schema låter dig starta flera klient socks5-servrar och distribuera externa anslutningar till dem, vidarebefordra dem genom en enda TCP-anslutning (nästan som i mätare) från klient till server, och därigenom implementera ett flertrådigt läge, utan vilket vi helt enkelt inte kommer att vara kunna arbeta fullt ut i de interna nätverken.
Kärnan i hur yamux fungerar är att den introducerar ett extra nätverkslager av strömmar, implementerar det i form av en 12-byte header för varje paket. (Här använder vi medvetet ordet "ström" snarare än tråd, för att inte förvirra läsaren med en programström "tråd" - vi kommer också att använda detta koncept i den här artikeln). Yamux-huvudet innehåller strömnumret, flaggor för att installera/avsluta strömmen, antalet överförda byte och storleken på överföringsfönstret.
Förutom att installera/avsluta en stream, implementerar yamux en keepalive-mekanism som låter dig övervaka prestandan för den etablerade kommunikationskanalen. Funktionen för keeplive-meddelandemekanismen konfigureras när en Yamux-session skapas. Av inställningarna finns det faktiskt bara två parametrar: aktivera/avaktivera och frekvensen för att skicka paket i sekunder. Keepalive-meddelanden kan skickas av en yamux-server eller en yamux-klient. När man tar emot ett Keepalive-meddelande måste fjärrparten svara på det genom att skicka exakt samma meddelandeidentifierare (faktiskt ett nummer) som den tog emot. I allmänhet är keepalive samma ping, bara för yamux.
Hela drifttekniken för multiplexorn: pakettyper, anslutningsinställningar och avslutningsflaggor och dataöverföringsmekanismen beskrivs i detalj i till yamux.
Avslutning på första delen
Så i den första delen av artikeln bekantade vi oss med några verktyg för att organisera omvända tunnlar, tittade på deras fördelar och nackdelar, studerade funktionsmekanismen för Yamux-multiplexern och beskrev de grundläggande kraven för den nyskapade powershell-modulen. I nästa del kommer vi att utveckla själva modulen, praktiskt taget från grunden. Fortsättning följer. Byt inte :)
Källa: will.com