O poveste despre cercetare și dezvoltare în 3 părți. Partea 1 este exploratorie.
Există mulți fagi - chiar mai multe beneficii.
Declarație de problemă
În timpul pentesturilor și campaniilor RedTeam, nu este întotdeauna posibilă utilizarea instrumentelor standard ale Clientului, cum ar fi VPN, RDP, Citrix etc. ca ancoră pentru intrarea în reţeaua internă. În unele locuri, un VPN standard funcționează folosind MFA și un token hardware este folosit ca al doilea factor, în altele este monitorizat brutal și autentificarea noastră VPN devine imediat vizibilă, după cum se spune, cu tot ce presupune, dar în altele există pur și simplu nu există astfel de mijloace.
În astfel de cazuri, trebuie să facem în mod constant așa-numitele „tunele inverse” - conexiuni de la rețeaua internă la o resursă externă sau un server pe care îl controlăm. În interiorul unui astfel de tunel, putem deja să lucrăm cu resursele interne ale Clienților.
Există mai multe varietăți ale acestor tuneluri de întoarcere. Cel mai faimos dintre ele este, desigur, Meterpreter. Tunelurile SSH cu redirecționare inversă a portului sunt, de asemenea, la mare căutare în rândul maselor de hackeri. Există destul de multe mijloace pentru implementarea tunelului invers și multe dintre ele sunt bine studiate și descrise.
Desigur, la rândul lor, dezvoltatorii de soluții de securitate nu stau deoparte și detectează activ astfel de acțiuni.
De exemplu, sesiunile MSF sunt detectate cu succes de IPS modern de la Cisco sau Positive Tech, iar un tunel SSH invers poate fi detectat de aproape orice firewall normal.
Prin urmare, pentru a rămâne neobservați într-o campanie bună RedTeam, trebuie să construim un tunel invers folosind mijloace non-standard și să ne adaptăm cât mai mult posibil la modul real de funcționare al rețelei.
Să încercăm să găsim sau să inventăm ceva asemănător.
Înainte de a inventa ceva, trebuie să înțelegem ce rezultat 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 modul stealth maxim?
Este clar că, pentru fiecare caz, astfel de cerințe pot fi foarte diferite, dar pe baza experienței de muncă, pot fi identificate principalele:
- lucrul la sistemul de operare Windows-7-10. Întrucât majoritatea rețelelor corporative utilizează Windows;
- clientul se conectează la server prin SSL pentru a evita ascultarea stupidă folosind ips;
- La conectare, clientul trebuie să suporte lucrul printr-un server proxy cu autorizare, deoarece În multe companii, accesul la Internet se face printr-un proxy. De fapt, mașina client poate nici măcar să nu știe nimic despre aceasta, iar proxy-ul este utilizat într-un mod transparent. Dar trebuie să oferim o astfel de funcționalitate;
- partea client ar trebui să fie concisă și portabilă;
Este clar că pentru a lucra în rețeaua Clientului, este posibilă instalarea pe mașina clientului OpenVPN și configurați un tunel complet către serverul dvs. (din fericire, clienții OpenVPN pot funcționa printr-un proxy). Dar, în primul rând, acest lucru nu va funcționa întotdeauna, deoarece este posibil să nu fim administratori locali și, în al doilea rând, ar crea atât de mult zgomot încât un sistem SIEM sau HIPS reputat ne-ar raporta imediat. În mod ideal, clientul nostru ar trebui să fie o comandă inline, ca multe shell-uri Bash, și să ruleze din linia de comandă, de exemplu, atunci când executați comenzi dintr-o macrocomandă Word. - tunelul nostru trebuie să fie multi-threaded și să suporte mai multe conexiuni simultan;
- conexiunea client-server trebuie să aibă un fel de autorizare, astfel încât tunelul să fie stabilit doar pentru clientul nostru, și nu pentru toți cei care vin la serverul nostru la adresa și portul specificate. În mod ideal, o pagină de destinație cu pisici sau subiecte profesionale legate de domeniul original ar trebui să se deschidă pentru „utilizatori terți”.
De exemplu, dacă Clientul este o organizație medicală, atunci pentru un administrator de securitate a informațiilor care decide să verifice resursa pe care a accesat-o un angajat al clinicii, o pagină cu produse farmaceutice, Wikipedia cu o descriere a diagnosticului sau blogul Dr. Komarovsky etc. ar trebui să se deschidă.
Analiza instrumentelor existente
Înainte de a-ți reinventa propria bicicletă, trebuie să faci o analiză a bicicletelor existente și să înțelegi dacă chiar avem nevoie de ea și, probabil, nu suntem singurii care ne-am gândit la necesitatea unei astfel de biciclete funcționale.
Căutarea pe Google pe Internet (se pare că căutăm pe Google în mod normal), precum și căutarea pe Github folosind cuvintele cheie „șosete inversate” nu au dat prea multe rezultate. Practic, totul se reduce la construirea de tuneluri ssh cu redirecționare inversă a portului și tot ceea ce este legat de el. Pe lângă tunelurile SSH, există mai multe soluții:
O implementare de lungă durată a unui tunel invers de la băieții de la Kaspersky Lab. Numele arată clar pentru ce este destinat acest script. Implementat în Python 2.7, tunelul funcționează în modul text clar (cum este la modă să spunem acum - salut RKN)
O altă implementare în Python, tot în text clar, dar cu mai multe posibilități. Este scris ca un modul și are un API pentru integrarea soluției în proiectele dumneavoastră.
Prima legătură este versiunea originală a implementării reverse sox în Golang (nu este acceptată de dezvoltator).
Al doilea link este revizuirea noastră cu funcții suplimentare, tot în Golang. În versiunea noastră, am implementat SSL, am lucrat printr-un proxy cu autorizație NTLM, autorizare pe client, o pagină de destinație în cazul unei parole incorecte (sau mai bine zis, o redirecționare către pagina de destinație), modul multi-threaded (adică mai multe persoane). poate lucra cu tunelul în același timp), un sistem de ping client pentru a determina dacă este în viață sau nu.
Implementarea reverse sox de la „prietenii noștri chinezi” în Python. Acolo, pentru leneși și „nemuritori”, există un binar gata făcut (exe), asamblat de chinezi și gata de utilizare. Aici, numai Dumnezeul chinez știe ce altceva poate conține acest binar în afară de funcționalitatea principală, așa că utilizați-vă pe propriul risc și risc.
Un proiect destul de interesant în C++ pentru implementarea reverse sox și multe altele. Pe lângă tunelul invers, poate face redirecționarea portului, poate crea un shell de comandă etc.
Contor MSF
Aici, după cum se spune, fără comentarii. Toți hackerii chiar mai mult sau mai puțin educați sunt foarte familiarizați cu acest lucru și înțeleg cât de ușor poate fi detectat de instrumentele de securitate.
Toate instrumentele descrise mai sus funcționează folosind o tehnologie similară: un modul binar executabil pre-preparat este lansat pe o mașină din interiorul rețelei, care stabilește o conexiune cu un server extern. Serverul rulează un server SOCKS4/5 care acceptă conexiuni și le transmite către client.
Dezavantajul tuturor instrumentelor de mai sus este că fie Python, fie Golang trebuie să fie instalate pe computerul client (ați văzut adesea Python instalat pe mașinile, de exemplu, ale unui director de companie sau ale angajaților de birou?), fie un pre-asamblat. binarul (de fapt python) trebuie să fie tras pe această mașină și să scripteze într-o sticlă) și să rulați acest binar deja acolo. Și descărcarea unui exe și apoi lansarea acestuia este, de asemenea, o semnătură pentru un antivirus local sau HIPS.
În general, concluzia sugerează de la sine - avem nevoie de o soluție powershell. Acum roșiile vor zbura spre noi - se spune că Powershell este deja dezgustător, este monitorizat, blocat etc. și așa mai departe. De fapt, nu peste tot. Declaram cu responsabilitate. Apropo, există o mulțime de modalități de a ocoli blocarea (aici din nou există o frază la modă despre salut RKN 🙂), începând de la redenumirea stupidă a lui powershell.exe -> cmdd.exe și terminând cu powerdll etc.
Să începem să inventăm
Este clar că mai întâi vom căuta pe Google și... nu vom găsi nimic pe acest subiect (dacă cineva l-a găsit, postați linkuri în comentarii). Este doar Socks5 pe powershell, dar acesta este un sox obișnuit „direct”, care are o serie de propriile dezavantaje (vom vorbi despre ele mai târziu). Puteți, desigur, cu o ușoară mișcare a mâinii, să o transformați în cea inversă, dar acesta va fi doar șosete cu un singur fir, ceea ce nu este exact ceea ce avem nevoie pentru noi.
Deci, nu am găsit nimic gata făcut, așa că va trebui totuși să ne reinventăm roata. Vom lua ca bază pentru bicicleta noastră reverse sox în Golang și implementăm un client pentru acesta în powershell.
RSocksTun
Deci, cum funcționează rsockstun?
Funcționarea RsocksTun (denumită în continuare rs) se bazează pe două componente software - Yamux și serverul Socks5. Serverul Socks5 este un socks5 local obișnuit, rulează pe client. Și multiplexarea conexiunilor la acesta (vă amintiți despre multithreading?) este furnizată folosind yamux (). Această schemă vă permite să lansați mai multe servere client socks5 și să distribuiți conexiuni externe către acestea, redirecționâ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 pur și simplu nu vom fi capabil să lucreze pe deplin în rețelele interne.
Esența modului în care funcționează yamux este că introduce un strat suplimentar de rețea de fluxuri, implementându-l sub forma unui antet de 12 octeți pentru fiecare pachet. (Aici folosim în mod deliberat cuvântul „stream” în loc de thread, pentru a nu confunda cititorul cu un flux de program „thread” - vom folosi și acest concept în acest articol). Antetul yamux conține numărul fluxului, steaguri pentru instalarea/încheierea fluxului, numărul de octeți transferați și dimensiunea ferestrei de transfer.
Pe lângă instalarea/încheierea unui flux, yamux implementează un mecanism keepalive care vă permite să monitorizați performanța canalului de comunicare stabilit. Funcționarea mecanismului de mesaje keeplive este configurată la crearea unei sesiuni Yamux. De fapt, dintre setări există doar doi parametri: activare/dezactivare și frecvența de trimitere a pachetelor în secunde. Mesajele Keepalive pot fi trimise de un server yamux sau de un client yamux. Când primește un mesaj keepalive, partea de la distanță trebuie să răspundă la acesta trimițând exact același identificator de mesaj (de fapt un număr) pe care l-a primit. În general, keepalive este același ping, doar pentru yamux.
Întreaga tehnică de operare a multiplexorului: tipurile de pachete, setarea conexiunii și steagurile de terminare și mecanismul de transfer de date sunt descrise în detaliu în la yamux.
Concluzie la prima parte
Deci, în prima parte a articolului, ne-am familiarizat cu câteva 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 nou creat. În partea următoare vom dezvolta modulul în sine, practic de la zero. Va urma. nu schimba :)
Sursa: www.habr.com
