Istoria cercetării și dezvoltării în 3 părți. Partea 1 - cercetare.
Sunt multe cărți - dar și mai multe beneficii.
Formularea problemei
În timpul desfășurării testelor de penetrare și campaniilor RedTeam, nu întotdeauna reușim să folosim instrumentele standard ale clienților, cum ar fi VPN, RDP, Citrix etc., ca legătură pentru accesul la rețeaua internă. În unele cazuri, VPN-ul standard funcționează pe baza MFA și ca al doilea factor este utilizat un token hardware, în altele este monitorizat agresiv și accesul nostru prin VPN este imediat vizibil, cum s-ar spune - cu toate consecințele, iar în unele locuri pur și simplu nu există astfel de instrumente.
În astfel de cazuri, suntem nevoiți să realizăm constant așa-numitele „tuneluri inverse” - conexiuni din rețeaua internă către o resursă externă sau un server pe care îl controlăm. În interiorul acestui tunel putem deja lucra cu resursele interne ale clienților.
Există mai multe tipuri de astfel de tuneluri inverse. Cel mai cunoscut dintre ele, bineînțeles, este Meterpreter. De asemenea, tunelurile SSH cu redirecționare inversă a porturilor se bucură de o mare popularitate în rândul hackerilor. Există suficiente metode de realizare a tunelării inverse, iar multe dintre ele sunt bine studiate și descrise.
Desigur, din partea lor, dezvoltatorii soluțiilor de securitate nici nu stau deoparte și detectează activ astfel de acțiuni.
De exemplu, sesiunile MSF sunt detectate cu succes de IPS-urile moderne de la Cisco sau Positive Tech, iar un tunel SSH invers poate fi detectat practic de orice firewall normal.
Prin urmare, pentru a rămâne neobservat într-o campanie bună RedTeam - trebuie să construim un tunel invers prin metode neobișnuite și să ne ajustăm cât mai aproape de modul real de lucru al rețelei.
Hai să încercăm să găsim sau să inventăm ceva de genul acesta.
Înainte de a inventa ceva, trebuie să înțelegem ce rezultate dorim să obținem, ce funcții ar trebui să îndeplinească dezvoltarea noastră. Care vor fi cerințele pentru tunel, astfel încât să putem lucra în mod maxim ascuns?
Este evident că aceste cerințe pot varia semnificativ în fiecare caz, dar, din experiența de lucru, putem evidenția principalele:
- funcționare pe sistemul de operare Windows 7-10. Deoarece în majoritatea rețelelor corporative se utilizează în mod special Windows;
- clientul se conectează la server prin SSL pentru a evita ascultarea pasivă prin intermediul ips;
- la conectare, clientul trebuie să suporte funcționarea prin intermediul unui server proxy cu autentificare, deoarece în multe companii accesul la internet se face prin proxy. De fapt, mașina clientului poate să nu fie conștientă de acest lucru și proxy-ul este utilizat în mod transparent. Dar această funcționalitate trebuie să fie inclusă;
- partea clientului trebuie să fie concisă și portabilă;
Este clar că pentru a funcționa în rețeaua Clientului, pe mașina clientului se poate instala OpenVPN și se poate ridica un tunel complet către propriul server (bineînțeles, clienții openvpn pot funcționa prin proxy). Dar, pe de o parte, nu întotdeauna aceasta va fi posibil, deoarece s-ar putea să nu fim administratori locali acolo, iar pe de altă parte, acest lucru ar putea genera atât de mult zgomot încât un SIEM sau HIPS decent ar acționa imediat. Ideal ar fi ca clientul nostru să fie așa-numita echipă inline, cum ar fi multe shell-uri bash, și să fie executat prin linia de comandă, de exemplu, la execuția comenzilor dintr-un macro Word. - tunelul nostru trebuie să fie multi-threaded și să suporte numeroase conexiuni simultan;
- conexiunea client-server trebuie să aibă o anumită autentificare pentru a se stabili tunelul doar pentru clientul nostru, nu pentru toți cei care vin la serverul nostru pe adresa și portul menționat. Ideal, pentru „utilizatori externi”, ar trebui să se deschidă o pagină de destinație cu pisici sau o temă profesională legată de domeniul de origine.
De exemplu, dacă Clientul este o organizație medicală, atunci pentru administratorul de securitate informațională care decide să verifice resursa accesată de un angajat al clinicii, ar trebui să se deschidă o pagină cu produse farmaceutice, Wikipedia cu descrierea diagnosticului sau blogul doctorului Komarovski etc.
Analiza instrumentelor existente
Înainte de a inventa bicicleta proprie - este necesar să se facă o analiză a bicicletelor existente și să se înțeleagă dacă este realmente necesară și, probabil, nu doar noi ne-am gândit la necesitatea unei astfel de biciclete funcționale.
Căutarea pe internet (parcă căutăm destul de bine), precum și căutarea pe GitHub după cuvintele cheie „reverse socks” nu a adus multe rezultate. În principal, totul se reduce la construirea tunelurilor SSH cu redirecționare inversă a porturilor și tot ce este legat de aceasta. Pe lângă tunelurile SSH, putem evidenția câteva soluții:
O implementare veche a tunelului invers de la echipa de la Laboratorul Kaspersky. Din nume este clar pentru ce este destinat acest script. Este implementat pe Python 2.7, tunelul funcționează în modul cleartext (așa cum este la modă să spunem acum – salut, RKN)
O altă implementare pe Python, tot în cleartext, dar cu mai multe funcționalități. Este scris sub formă de modul și are API pentru integrarea soluției în proiectele proprii.
Primul link este versiunea inițială a implementării reverse socks pe Golang (nu este susținută de dezvoltator).
Al doilea link este deja versiunea noastră îmbunătățită cu funcționalități suplimentare, tot pe Golang. În versiunea noastră am implementat SSL, funcționare prin proxy cu autorizare NTLM, autorizare pe client, pagină de destinație în cazul parolei incorecte (mai bine zis – redirecționare către pagina de destinație), modul multi-thread (deci, cu tunelul pot lucra mai multe persoane simultan), sistem de ping-uri pentru a verifica dacă clientul este activ sau nu.
O implementare a reverse socks de la „prietenii noștri chinezi” pe Python. Acolo se găsește și pentru cei leneși și „nemuritori” un binar gata (exe), compilat de chinezi și gata de utilizare. Aici un singur zeu chinez știe ce altceva poate fi în acest binar, pe lângă funcționalitatea principală, așa că folosiți-l pe riscul vostru.
Un proiect destul de interesant pe C++ pentru implementarea reverse socks și nu numai. Pe lângă tunelul invers, acesta poate face redirecționări de porturi, creare de shell-uri pentru comenzi etc.
MSF meterpreter
Aici, cum se spune, fără comentarii. Toți hackerii ceva mai educați sunt bine familiarizați cu această unealtă și înțeleg cât de ușor este detectată de către soluțiile de protecție.
Toate instrumentele descrise mai sus funcționează pe o tehnologie similară: pe mașina din rețea se lansează un modul binar executabil, pregătit dinainte, care stabilește o conexiune cu un server extern. Pe server, se lansează un server SOCKS4/5 care acceptă conexiuni și le transmite clientului.
Dezavantajul tuturor acestor instrumente este că fie pe mașina client este necesar să fie instalat Python sau Golang (cât de des ați întâlnit Python instalat pe mașinile, de exemplu, ale directorilor sau angajaților de birou?), fie pe această mașină trebuie să transferați un binar pregătit anterior (de fapt, python și scriptul într-un singur pachet) și să porniți acel binar acolo. Iar descărcarea unui exe și apoi rularea acestuia este o semnătură destul de suspectă pentru antivirusul local sau HIPS.
În general, concluzia se impune de la sine – avem nevoie de o soluție pe PowerShell. Acum vom avea parte de critici – cum că PowerShell este deja o tehnologie uzată, monitorizată, blocată etc. și toate celelalte. De fapt, nu este adevărat peste tot. Declaram acest lucru cu responsabilitate. Apropo, există o mulțime de modalități de a ocoli blocajele (aici iarăși e o frază la modă referitoare la salutul RKN 🙂), de la simpla redenumire a powershell.exe în cmdd.exe până la utilizarea powerdll și altele.
Începem să dezvoltăm
Evident, vom căuta pe Google și... nu vom găsi nimic pe această temă (dacă cineva a găsit, lăsați link-uri în comentarii). Există doar Socks5 pe PowerShell, dar acesta este un socks 'direct' obișnuit, care are o serie de dezavantaje (despre acestea vom discuta mai târziu). Desigur, putem transforma ușor în unul invers, dar va fi doar un socks pe un singur fir, ceea ce pentru noi nu este ceea ce avem nevoie.
Deci, nu am găsit nimic gata făcut, așa că va trebui să ne inventăm bicicleta. Ca bază pentru bicicleta noastră, vom folosi a unui socks invers pe Golang, iar clientul pentru acesta îl vom realiza pe PowerShell.
RSocksTun
Deci, cum funcționează rsockstun?
La baza funcționării RsocksTun (în continuare denumit rs) stau două componente software – Yamux și serverul Socks5. Serverul Socks5 este un socks5 local obișnuit, el se lansează pe client. Iar multiplexarea conexiunilor către acesta (țineți minte despre multithreading?) este asigurată cu ajutorul yamux (). Această schemă permite rularea mai multor servere socks5 client și distribuirea conexiunilor externe către acestea, trecându-le printr-o singură conexiune TCP (aproape ca în meterpreter) de la client la server, implementând astfel un mod multi-threaded, fără de care nu vom putea lucra eficient în rețeaua internă.
Conceptul de funcționare al yamux-ului constă în faptul că introduce un nivel suplimentar de rețea de fluxuri, implementându-l sub formă de antet de 12 bytes pentru fiecare pachet. (Aici folosim în mod intenționat termenul „flux”, nu „stream”, pentru a nu confunda cititorul cu fluxul programatic „thread” — acest concept îl vom folosi de asemenea în acest articol). În interiorul antetului yamux se află numărul fluxului, steaguri pentru deschiderea/închiderea fluxului, numărul de bytes transmiși, dimensiunea feronței.
Pe lângă deschiderea/închiderea fluxului, yamux dispune de un mecanism de keepalive-uri, care permite monitorizarea funcționării canalului de comunicare stabilit. Funcționarea mecanismului de mesaje keepalive se configurează la crearea sesiunii Yamux. De fapt, din setările disponibile există doar — două parametrii: activare/dezactivare și frecvența de trimitere a pachetelor în secunde. Mesajele keepalive pot fi trimise atât de serverul yamux, cât și de clientul yamux. La primirea unui mesaj keepalive, partea remote este obligată să răspundă cu un mesaj exact identic (de fapt — un număr) pe care l-a primit. În general, keepalive-ul este același lucru cu ping-ul, doar că pentru yamux.
Detalii despre întreaga tehnică de funcționare a multiplexorului: tipuri de pachete, steagurile de deschidere și închidere a conexiunilor, mecanismul de transmitere a datelor sunt descrise în la yamux.
Încheierea primei părți
Așadar, în prima parte a articolului ne-am familiarizat cu un anumit set de instrumente pentru organizarea tunelurilor inverse, am analizat avantajele și dezavantajele acestora, am studiat mecanismul de funcționare al multiplexorului Yamux și am descris cerințele de bază pentru modulul powershell ce urmează a fi creat. În partea următoare ne vom ocupa de dezvoltarea modulului propriu-zis, practic, de la zero. Continuarea urmează. Nu schimbați canalul 🙂
Sursa: habr.com
