Una història sobre recerca i desenvolupament en 3 parts. La primera part és exploratòria.
Hi ha molts faigs, encara més beneficis.
Declaració de problemes
Durant els pentests i les campanyes de RedTeam, no sempre és possible utilitzar les eines estàndard del Client, com ara VPN, RDP, Citrix, etc. com a àncora per entrar a la xarxa interna. En alguns llocs, una VPN estàndard funciona amb MFA i un token de maquinari s'utilitza com a segon factor, en altres es controla brutalment i el nostre inici de sessió VPN es fa visible de seguida, com diuen, amb tot el que comporta, però en d'altres hi ha simplement cap mitjà d'aquest tipus.
En aquests casos, constantment hem de fer els anomenats "túnels inversos": connexions des de la xarxa interna a un recurs extern o un servidor que controlem. Dins d'aquest túnel, ja podem treballar amb els recursos interns dels Clients.
Hi ha diverses varietats d'aquests túnels de retorn. El més famós d'ells és, per descomptat, Meterpreter. Els túnels SSH amb reenviament de ports inversos també tenen una gran demanda entre les masses de pirates informàtics. Hi ha molts mitjans per implementar el túnel invers i molts d'ells estan ben estudiats i descrits.
Per descomptat, per la seva banda, els desenvolupadors de solucions de seguretat no es queden al marge i detecten activament aquestes accions.
Per exemple, les sessions de MSF són detectades amb èxit per l'IPS modern de Cisco o Positive Tech, i gairebé qualsevol tallafoc normal pot detectar un túnel SSH invers.
Per tant, per passar desapercebuts en una bona campanya de RedTeam, hem de construir un túnel invers amb mitjans no estàndards i adaptar-nos el més a prop possible al mode de funcionament real de la xarxa.
Intentem trobar o inventar alguna cosa semblant.
Abans d'inventar qualsevol cosa, hem d'entendre quin resultat volem aconseguir, quines funcions ha de realitzar el nostre desenvolupament. Quins seran els requisits per al túnel perquè puguem treballar en mode sigil màxim?
És evident que per a cada cas aquests requisits poden ser molt diferents, però a partir de l'experiència laboral, es poden identificar els principals:
- funciona amb el sistema operatiu Windows-7-10. Com que la majoria de xarxes corporatives utilitzen Windows;
- el client es connecta al servidor mitjançant SSL per evitar una escolta estúpida amb ips;
- Quan es connecta, el client ha de suportar el treball mitjançant un servidor intermediari amb autorització, perquè En moltes empreses, l'accés a Internet es produeix mitjançant un proxy. De fet, és possible que la màquina client ni tan sols en sàpiga res i el proxy s'utilitza en un mode transparent. Però hem de proporcionar aquesta funcionalitat;
- la part del client ha de ser concisa i portàtil;
És evident que per treballar dins de la xarxa del client, podeu instal·lar OpenVPN a la màquina client i crear un túnel complet al vostre servidor (afortunadament, els clients openvpn poden funcionar mitjançant un proxy). Però, en primer lloc, això no sempre funcionarà, ja que potser no som administradors locals allà i, en segon lloc, farà tant de soroll que un SIEM o HIPS decents ens "enganxarà" immediatament. Idealment, el nostre client hauria de ser una anomenada ordre en línia, ja que, per exemple, s'implementen moltes intèrprets d'ordres bash i s'inicien mitjançant la línia d'ordres, per exemple, quan s'executen ordres des d'una macro de paraules. - el nostre túnel ha de ser multifil i suportar moltes connexions simultàniament;
- la connexió client-servidor ha de tenir algun tipus d'autorització perquè el túnel s'estableixi només per al nostre client, i no per a tots els que arribin al nostre servidor a l'adreça i el port especificats. Idealment, una pàgina de destinació amb gats o temes professionals relacionats amb el domini original hauria d'obrir-se per a "usuaris de tercers".
Per exemple, si el client és una organització mèdica, llavors per a un administrador de seguretat de la informació que decideix comprovar el recurs al qual ha accedit un empleat de la clínica, una pàgina amb productes farmacèutics, la Viquipèdia amb una descripció del diagnòstic o el bloc del Dr. Komarovsky, etc. s'ha d'obrir.
Anàlisi de les eines existents
Abans de reinventar la teva pròpia bicicleta, has de fer una anàlisi de les bicicletes existents i entendre si realment la necessitem i, probablement, no som els únics que hem pensat en la necessitat d'una bicicleta tan funcional.
Buscar a Google a Internet (sembla que busquem a Google normalment), així com cercar a Github amb les paraules clau "mitjons inversos" no va donar molts resultats. Bàsicament, tot es redueix a construir túnels ssh amb reenviament de ports inversos i tot el que hi estigui connectat. A més dels túnels SSH, hi ha diverses solucions:
Una implementació de llarga durada d'un túnel invers per part dels nois de Kaspersky Lab. El nom deixa clar per a què està pensat aquest guió. Implementat a Python 2.7, el túnel funciona en mode de text clar (com està de moda dir ara - hola RKN)
Una altra implementació en Python, també en text clar, però amb més possibilitats. Està escrit com un mòdul i té una API per integrar la solució als vostres projectes.
El primer enllaç és la versió original de la implementació de reverse sox a Golang (no admesa pel desenvolupador).
El segon enllaç és la nostra revisió amb funcions addicionals, també a Golang. A la nostra versió, vam implementar SSL, treballem a través d'un proxy amb autorització NTLM, autorització al client, una pàgina de destinació en cas de contrasenya incorrecta (o millor dit, una redirecció a la pàgina de destinació), mode multiprocés (és a dir, diverses persones). pot treballar amb el túnel al mateix temps), un sistema de ping al client per determinar si està viu o no.
Implementació de reverse sox dels nostres “amics xinesos” en Python. Allà, per als ganduls i els "immortals", hi ha un binari (exe) ja fet, muntat pels xinesos i llest per al seu ús. Aquí, només el déu xinès sap què més pot contenir aquest binari a més de la funcionalitat principal, així que utilitzeu-lo sota el vostre risc i risc.
Un projecte força interessant en C++ per implementar reverse sox i molt més. A més del túnel invers, pot fer reenviament de ports, crear un intèrpret d'ordres, etc.
MSF metrepreter
Aquí, com diuen, sense comentaris. Tots els pirates informàtics, fins i tot més o menys educats, estan molt familiaritzats amb això i entenen amb quina facilitat es poden detectar amb eines de seguretat.
Totes les eines descrites anteriorment funcionen amb una tecnologia similar: s'inicia un mòdul binari executable prèviament preparat en una màquina dins de la xarxa, que estableix una connexió amb un servidor extern. El servidor executa un servidor SOCKS4/5 que accepta connexions i les transmet al client.
L'inconvenient de totes les eines anteriors és que Python o Golang s'han d'instal·lar a la màquina client (has vist sovint Python instal·lat a les màquines, per exemple, d'un director d'empresa o d'oficines?), o bé un pre-muntat. binari (en realitat Python) s'ha d'arrossegar a aquesta màquina i s'ha d'escripturar en una ampolla) i executar aquest binari que ja hi ha. I baixar un exe i llançar-lo també és una signatura per a un antivirus local o HIPS.
En general, la conclusió suggereix per si mateixa: necessitem una solució de Powershell. Ara els tomàquets volaran cap a nosaltres: diuen que el Powershell ja està tot triturat, està controlat, bloquejat, etc. etcètera. De fet, no a tot arreu. Declarem amb responsabilitat. Per cert, hi ha moltes maneres d'evitar el bloqueig (aquí de nou hi ha una frase de moda sobre hola RKN 🙂), començant per l'estúpid canvi de nom de powershell.exe -> cmdd.exe i acabant amb powerdll, etc.
Comencem a inventar
Està clar que primer buscarem a Google i... no trobarem res sobre aquest tema (si algú l'ha trobat, publiqueu enllaços als comentaris). Només n'hi ha Socks5 a powershell, però aquest és un sox "directe" normal, que té diversos desavantatges (en parlarem més endavant). Podeu, per descomptat, amb un lleuger moviment de la mà, convertir-lo en el revés, però aquest només serà un sox d'un sol fil, que no és del tot el que necessitem per a nosaltres.
Per tant, no hem trobat res fet, així que encara haurem de reinventar la nostra roda. Prenem com a base la nostra bicicleta reverse sox a Golang i implementem un client per a això a Powershell.
RSocksTun
Llavors, com funciona rsockstun?
El funcionament de RsocksTun (d'ara endavant rs) es basa en dos components de programari: el servidor Yamux i Socks5. El servidor Socks5 és un socks5 local normal, s'executa al client. I la multiplexació de connexions amb ella (recordeu del multithreading?) es proporciona mitjançant yamux (). Aquest esquema us permet llançar diversos servidors de client socks5 i distribuir-hi connexions externes, reenviant-los a través d'una única connexió TCP (gairebé com a meterpreter) de client a servidor, implementant així un mode multiprocés, sense el qual simplement no estarem. capaç de treballar plenament a les xarxes internes.
L'essència de com funciona yamux és que introdueix una capa de xarxa addicional de fluxos, implementant-la en forma d'una capçalera de 12 bytes per a cada paquet. (Aquí fem servir deliberadament la paraula "stream" en lloc de fil, per no confondre el lector amb un programa "fil" - també utilitzarem aquest concepte en aquest article). La capçalera de yamux conté el número de flux, els indicadors per instal·lar/acabar el flux, el nombre de bytes transferits i la mida de la finestra de transferència.
A més d'instal·lar/acabar un flux, yamux implementa un mecanisme keepalive que us permet supervisar el rendiment del canal de comunicació establert. El funcionament del mecanisme de missatge Keeplive es configura quan es crea una sessió Yamux. De fet, de la configuració només hi ha dos paràmetres: activar/desactivar i la freqüència d'enviament de paquets en segons. Els missatges Keepalive els poden enviar un servidor yamux o un client yamux. Quan rep un missatge keepalive, la part remota ha de respondre-hi enviant exactament el mateix identificador de missatge (en realitat un número) que va rebre. En general, keepalive és el mateix ping, només per a yamux.
Tota la tècnica operativa del multiplexor: tipus de paquets, senyals de configuració de connexió i terminació i el mecanisme de transferència de dades es descriuen amb detall a a yamux.
Conclusió de la primera part
Així, a la primera part de l'article, ens vam familiaritzar amb algunes eines per organitzar túnels inversos, vam analitzar els seus avantatges i desavantatges, vam estudiar el mecanisme de funcionament del multiplexor Yamux i vam descriure els requisits bàsics per al mòdul Powershell de nova creació. En la següent part desenvoluparem el mòdul en si, pràcticament des de zero. Continuarà. No canviïs :)
Font: www.habr.com