Unha historia sobre investigación e desenvolvemento en 3 partes. A parte 1 é exploratoria.
Hai moitas faias - aínda máis beneficios.
Declaración de problemas
Durante os pentests e as campañas de RedTeam, non sempre é posible utilizar as ferramentas estándar do Cliente, como VPN, RDP, Citrix, etc. como áncora para entrar na rede interna. Nalgúns lugares, unha VPN estándar funciona usando MFA e un token de hardware utilízase como segundo factor, noutros é brutalmente vixiado e o noso inicio de sesión VPN faise inmediatamente visible, como din, con todo o que supón, pero noutros hai simplemente non hai tales medios.
Nestes casos, temos que facer constantemente os chamados "túneles inversos": conexións desde a rede interna a un recurso externo ou a un servidor que controlamos. Dentro deste túnel, xa podemos traballar cos recursos internos dos Clientes.
Existen varias variedades destes túneles de retorno. O máis famoso deles é, por suposto, Meterpreter. Os túneles SSH con reenvío de portos inversos tamén teñen unha gran demanda entre as masas de hackers. Hai bastantes medios para implementar o túnel inverso e moitos deles están ben estudados e descritos.
Por suposto, pola súa banda, os desenvolvedores de solucións de seguridade non se deixan de lado e detectan activamente tales accións.
Por exemplo, as sesións de MSF son detectadas con éxito polo IPS moderno de Cisco ou Positive Tech, e case calquera firewall normal pode detectar un túnel SSH inverso.
Polo tanto, para pasar desapercibidos nunha boa campaña de RedTeam, necesitamos construír un túnel inverso utilizando medios non estándar e adaptarnos o máis posible ao modo de funcionamento real da rede.
Intentemos buscar ou inventar algo semellante.
Antes de inventar nada, temos que entender que resultado queremos acadar, que funcións debe realizar o noso desenvolvemento. Cales serán os requisitos para o túnel para que poidamos traballar no modo sigiloso máximo?
Está claro que para cada caso tales requisitos poden diferir moito, pero en función da experiencia laboral pódense identificar os principais:
- funciona en Windows-7-10 OS. Xa que a maioría das redes corporativas usan Windows;
- o cliente conéctase ao servidor a través de SSL para evitar unha escoita estúpida usando ips;
- Ao conectarse, o cliente debe soportar o traballo a través dun servidor proxy con autorización, porque En moitas empresas, o acceso a Internet prodúcese a través dun proxy. De feito, a máquina cliente pode nin sequera saber nada sobre iso e o proxy úsase nun modo transparente. Pero debemos proporcionar tal funcionalidade;
- a parte do cliente debe ser concisa e portátil;
Está claro que para traballar dentro da rede do cliente, pode instalar OpenVPN na máquina cliente e crear un túnel completo para o seu servidor (afortunadamente, os clientes openvpn poden traballar a través dun proxy). Pero, en primeiro lugar, isto non sempre funcionará, xa que é posible que non sexamos administradores locais alí, e, en segundo lugar, fará tanto ruído que un SIEM ou HIPS decente nos "snitch" de inmediato. Idealmente, o noso cliente debería ser un chamado comando en liña, xa que, por exemplo, se implementan moitos shells bash e lánzase a través da liña de comandos, por exemplo, cando se executan comandos desde unha macro de palabras. - o noso túnel debe ser multifío e admitir moitas conexións á vez;
- a conexión cliente-servidor debe ter algún tipo de autorización para que o túnel se estableza só para o noso cliente, e non para todos os que acudan ao noso servidor no enderezo e porto especificados. Idealmente, unha páxina de destino con gatos ou temas profesionais relacionados co dominio orixinal debería abrirse para "usuarios de terceiros".
Por exemplo, se o Cliente é unha organización médica, entón para un administrador de seguridade da información que decide comprobar o recurso ao que accedeu un empregado da clínica, unha páxina con produtos farmacéuticos, Wikipedia cunha descrición do diagnóstico ou o blog do doutor Komarovsky, etc. debería abrir.
Análise das ferramentas existentes
Antes de inventar a túa propia bicicleta, cómpre facer unha análise das bicicletas existentes e comprender se realmente a necesitamos e, probablemente, non somos os únicos que pensamos na necesidade dunha bicicleta tan funcional.
Buscando en Google en Internet (parece que buscamos en Google normalmente), así como buscar en Github usando as palabras clave "reverse socks" non deu moitos resultados. Basicamente, todo se reduce a construír túneles ssh con reenvío de portos inverso e todo o relacionado con el. Ademais dos túneles SSH, hai varias solucións:
Unha implementación de longa data dun túnel inverso dos mozos de Kaspersky Lab. O nome deixa claro para que está destinado este guión. Implementado en Python 2.7, o túnel funciona en modo de texto claro (como está de moda dicir agora: ola RKN)
Outra implementación en Python, tamén en texto claro, pero con máis posibilidades. Está escrito como un módulo e ten unha API para integrar a solución nos teus proxectos.
A primeira ligazón é a versión orixinal da implementación de reverse sox en Golang (non admitida polo programador).
A segunda ligazón é a nosa revisión con funcións adicionais, tamén en Golang. Na nosa versión, implementamos SSL, traballamos a través dun proxy con autorización NTLM, autorización no cliente, unha páxina de destino en caso de contrasinal incorrecto (ou mellor dito, unha redirección á páxina de destino), modo multiproceso (é dicir, varias persoas). pode traballar co túnel ao mesmo tempo), un sistema de ping ao cliente para determinar se está vivo ou non.
Implantación de reverse sox dos nosos "amigos chineses" en Python. Alí, para os preguiceiros e "inmortales", hai un binario listo (exe), montado polos chineses e listo para o seu uso. Aquí, só o Deus chinés sabe que máis pode conter este binario ademais da funcionalidade principal, polo que úsao baixo o teu propio risco e risco.
Un proxecto bastante interesante en C++ para implementar reverse sox e moito máis. Ademais do túnel inverso, pode facer o reenvío de portos, crear un shell de comandos, etc.
Medidor de MSF
Aquí, como din, sen comentarios. Todos os piratas informáticos aínda máis ou menos educados están moi familiarizados con isto e comprenden a facilidade con que pode ser detectado polas ferramentas de seguridade.
Todas as ferramentas descritas anteriormente funcionan cunha tecnoloxía similar: un módulo binario executable previamente preparado lánzase nunha máquina dentro da rede, que establece unha conexión cun servidor externo. O servidor executa un servidor SOCKS4/5 que acepta conexións e as transmite ao cliente.
A desvantaxe de todas as ferramentas anteriores é que Python ou Golang deben estar instalados na máquina cliente (xa viches a miúdo Python instalado nas máquinas de, por exemplo, un director de empresa ou traballadores de oficina?), ou un pre-ensamblado. binario (en realidade Python) debe ser arrastrado a esta máquina e script nunha botella) e executar este binario xa alí. E descargar un exe e despois lanzalo tamén é unha sinatura para un antivirus local ou HIPS.
En xeral, a conclusión suxire por si mesma: necesitamos unha solución powershell. Agora os tomates voarán cara a nós: din que o Powershell xa está todo trillado, está vixiado, bloqueado, etc. etcétera. De feito, non en todas partes. Declaramos con responsabilidade. Por certo, hai moitas formas de evitar o bloqueo (aquí de novo hai unha frase de moda sobre ola RKN 🙂), comezando polo estúpido cambio de nome de powershell.exe -> cmdd.exe e rematando con powerdll, etc.
Comecemos a inventar
Está claro que primeiro buscaremos en Google e... non atoparemos nada sobre este tema (se alguén o atopou, poña ligazóns nos comentarios). Só hai Socks5 en powershell, pero este é un sox "directo" común, que ten unha serie de desvantaxes propias (falaremos deles máis tarde). Por suposto, podes, cun leve movemento da túa man, convertela na inversa, pero este só será un sox dun só fío, que non é o que necesitamos para nós.
Polo tanto, non atopamos nada preparado, así que aínda teremos que reinventar a nosa roda. Tomaremos como base a nosa bicicleta reverse sox en Golang e implementamos un cliente para el en Powershell.
RSocksTun
Entón, como funciona rsockstun?
O funcionamento de RsocksTun (en diante rs) baséase en dous compoñentes de software: o servidor Yamux e Socks5. O servidor Socks5 é un socks5 local normal, execútase no cliente. E a multiplexación de conexións a ela (lembras do multithreading?) ofrécese usando yamux (). Este esquema permítelle lanzar varios servidores cliente socks5 e distribuírlles conexións externas, reenviándoas a través dunha única conexión TCP (case como en meterpreter) de cliente a servidor, implementando así un modo multiproceso, sen o cal simplemente non estaremos capaz de traballar plenamente nas redes internas.
A esencia de como funciona yamux é que introduce unha capa de rede adicional de fluxos, implementándoa en forma de cabeceira de 12 bytes para cada paquete. (Aquí usamos deliberadamente a palabra "fluxo" en lugar de fío, para non confundir ao lector cun programa "fío" - tamén usaremos este concepto neste artigo). A cabeceira de yamux contén o número de fluxo, os indicadores para instalar/terminar o fluxo, o número de bytes transferidos e o tamaño da xanela de transferencia.
Ademais de instalar/terminar un fluxo, yamux implementa un mecanismo keepalive que che permite supervisar o rendemento da canle de comunicación establecida. O funcionamento do mecanismo de mensaxe keeplive configúrase ao crear unha sesión Yamux. En realidade, dos axustes só hai dous parámetros: activar/desactivar e a frecuencia de envío de paquetes en segundos. As mensaxes Keepalive pódense enviar por un servidor yamux ou un cliente yamux. Ao recibir unha mensaxe Keepalive, a parte remota debe responder a ela enviando exactamente o mesmo identificador de mensaxe (en realidade un número) que recibiu. En xeral, keepalive é o mesmo ping, só para yamux.
Toda a técnica de funcionamento do multiplexor: os tipos de paquetes, as marcas de configuración e terminación da conexión e o mecanismo de transferencia de datos descríbense en detalle en a yamux.
Conclusión da primeira parte
Entón, na primeira parte do artigo, coñecemos algunhas ferramentas para organizar túneles inversos, analizamos as súas vantaxes e inconvenientes, estudamos o mecanismo de funcionamento do multiplexor Yamux e describimos os requisitos básicos para o módulo Powershell recentemente creado. Na seguinte parte desenvolveremos o propio módulo, practicamente dende cero. Continuará. Non cambies :)
Fonte: www.habr.com