Una historia sobre investigación y desarrollo en 3 partes. La parte 1 es exploratoria.
Hay muchas hayas, y sus beneficios son aún mayores.
Formulación del problema
Durante los pentests y las campañas de RedTeam, no siempre es posible utilizar las herramientas estándar del Cliente, como VPN, RDP, Citrix, etc. como ancla para ingresar a la red interna. En algunos lugares una VPN estándar funciona mediante MFA y se utiliza un token de hardware como segundo factor, en otros es monitoreado brutalmente e inmediatamente se hace visible nuestro inicio de sesión de VPN, como dicen, con todo lo que eso conlleva, pero en otros hay simplemente no existen tales medios.
En tales casos, constantemente tenemos que realizar los llamados "túneles inversos": conexiones desde la red interna a un recurso externo o un servidor que controlamos. Dentro de dicho túnel, ya podemos trabajar con los recursos internos de los Clientes.
Existen varias variedades de estos túneles de retorno. El más famoso de ellos es, por supuesto, Meterpreter. Los túneles SSH con reenvío de puerto inverso también tienen una gran demanda entre las masas de hackers. Existen muchos medios para implementar la tunelización inversa y muchos de ellos están bien estudiados y descritos.
Por supuesto, por su parte, los desarrolladores de soluciones de seguridad no se quedan al margen y detectan activamente este tipo de acciones.
Por ejemplo, las sesiones MSF se detectan con éxito mediante IPS modernos de Cisco o Positive Tech, y casi cualquier firewall normal puede detectar un túnel SSH inverso.
Por lo tanto, para pasar desapercibidos en una buena campaña de RedTeam, necesitamos construir un túnel inverso utilizando medios no estándar y adaptarnos lo más posible al modo de funcionamiento real de la red.
Intentemos encontrar o inventar algo similar.
Antes de inventar algo, debemos entender qué resultado queremos lograr, qué funciones debe realizar nuestro desarrollo. ¿Cuáles serán los requisitos del túnel para que podamos trabajar en modo máximo sigiloso?
Está claro que para cada caso dichos requisitos pueden diferir mucho, pero en base a la experiencia laboral se pueden identificar los principales:
- Trabajar en el sistema operativo Windows-7-10. Dado que la mayoría de las redes corporativas utilizan Windows;
- el cliente se conecta al servidor a través de SSL para evitar escuchas estúpidas usando ips;
- Al conectarse, el cliente debe admitir el trabajo a través de un servidor proxy con autorización, porque En muchas empresas el acceso a Internet se produce a través de un proxy. De hecho, es posible que la máquina cliente ni siquiera sepa nada al respecto y el proxy se utiliza en modo transparente. Pero debemos proporcionar dicha funcionalidad;
- la parte del cliente debe ser concisa y portátil;
Está claro que para trabajar dentro de la red del Cliente, puede instalar OpenVPN en la máquina cliente y crear un túnel completo hacia su servidor (afortunadamente, los clientes openvpn pueden funcionar a través de un proxy). Pero, en primer lugar, esto no siempre funcionará, ya que es posible que no seamos administradores locales allí y, en segundo lugar, hará tanto ruido que un SIEM o HIPS decente nos "delatará" inmediatamente. Idealmente, nuestro cliente debería ser un comando en línea, ya que, por ejemplo, muchos shells bash se implementan y se ejecutan a través de la línea de comando, por ejemplo, cuando se ejecutan comandos desde una macro de Word. - nuestro túnel debe ser multiproceso y soportar muchas conexiones simultáneamente;
- la conexión cliente-servidor debe tener algún tipo de autorización para que el túnel se establezca solo para nuestro cliente, y no para todos los que llegan a nuestro servidor en la dirección y puerto especificado. Idealmente, debería abrirse una página de destino con gatos o temas profesionales relacionados con el dominio original para "usuarios externos".
Por ejemplo, si el Cliente es una organización médica, entonces para un administrador de seguridad de la información que decide verificar el recurso al que accedió un empleado de la clínica, una página con productos farmacéuticos, Wikipedia con una descripción del diagnóstico o el blog del Dr. Komarovsky, etc. .debe abrirse.
Análisis de herramientas existentes.
Antes de reinventar nuestra propia bicicleta, es necesario hacer un análisis de las bicicletas existentes y comprender si realmente la necesitamos y, probablemente, no somos los únicos que hemos pensado en la necesidad de una bicicleta tan funcional.
Buscar en Google en Internet (parece que lo hacemos normalmente), así como buscar en Github usando las palabras clave “calcetines inversos” no arrojó muchos resultados. Básicamente, todo se reduce a construir túneles ssh con reenvío de puertos inverso y todo lo relacionado con ellos. Además de los túneles SSH, existen varias soluciones:
Una implementación de larga data de un túnel inverso por parte de los chicos de Kaspersky Lab. El nombre deja claro para qué está destinado este script. Implementado en Python 2.7, el túnel funciona en modo de texto sin cifrar (como está de moda decir ahora: hola RKN)
Otra implementación en Python, también en texto claro, pero con más posibilidades. Está escrito como un módulo y tiene una API para integrar la solución en sus proyectos.
El primer enlace es la versión original de la implementación de Reverse Sox en Golang (no admitida por el desarrollador).
El segundo enlace es nuestra revisión con funciones adicionales, también en Golang. En nuestra versión, implementamos SSL, trabajamos a través de un proxy con autorización NTLM, autorización en el cliente, una página de inicio en caso de una contraseña incorrecta (o más bien, una redirección a la página de inicio), modo multiproceso (es decir, varias personas puede trabajar con el túnel al mismo tiempo), un sistema de hacer ping al cliente para determinar si está vivo o no.
Implementación de Reverse Sox de nuestros “amigos chinos” en Python. Allí, para los perezosos e "inmortales", hay un binario (exe) listo para usar, ensamblado por los chinos y listo para usar. Aquí, solo el Dios chino sabe qué más puede contener este binario además de la funcionalidad principal, así que úselo bajo su propia responsabilidad y riesgo.
Un proyecto bastante interesante en C++ para implementar sox inversos y más. Además del túnel inverso, puede reenviar puertos, crear un shell de comandos, etc.
medidorpreter MSF
Aquí, como dicen, no hay comentarios. Todos los piratas informáticos, incluso más o menos formados, están muy familiarizados con esto y comprenden lo fácil que pueden detectar las herramientas de seguridad.
Todas las herramientas descritas anteriormente funcionan con una tecnología similar: se inicia un módulo binario ejecutable previamente preparado en una máquina dentro de la red, que establece una conexión con un servidor externo. El servidor ejecuta un servidor SOCKS4/5 que acepta conexiones y las transmite al cliente.
La desventaja de todas las herramientas anteriores es que Python o Golang deben estar instalados en la máquina cliente (¿ha visto a menudo Python instalado en las máquinas de, por ejemplo, el director de una empresa o los trabajadores de oficina?), o un paquete preensamblado. El binario (en realidad Python) debe arrastrarse a esta máquina y el script en una botella) y ejecutar este binario que ya está allí. Y descargar un archivo ejecutable y luego ejecutarlo también es una firma para un antivirus local o HIPS.
En general, la conclusión se sugiere por sí sola: necesitamos una solución PowerShell. Ahora los tomates volarán hacia nosotros: dicen que PowerShell ya está trillado, está monitoreado, bloqueado, etc. etcétera. De hecho, no en todas partes. Declaramos responsablemente. Por cierto, hay muchas formas de evitar el bloqueo (aquí nuevamente hay una frase de moda sobre hola RKN 🙂), comenzando con el estúpido cambio de nombre de powershell.exe -> cmdd.exe y terminando con powerdll, etc.
empecemos a inventar
Está claro que primero buscaremos en Google y… no encontraremos nada sobre este tema (si alguien lo ha encontrado que ponga enlaces en los comentarios). Solo hay Socks5 en powershell, pero este es un sox "directo" ordinario, que tiene sus propias desventajas (hablaremos de ellas más adelante). Por supuesto, puede, con un ligero movimiento de la mano, convertirlo en el inverso, pero esto solo será un sox de un solo hilo, que no es exactamente lo que necesitamos para nosotros.
Entonces, no hemos encontrado nada ya hecho, así que todavía tendremos que reinventar nuestra rueda. Tomaremos como base para nuestra bicicleta. sox inverso en Golang, e implementamos un cliente para ello en powershell.
RSocksTun
Entonces, ¿cómo funciona rsockstun?
El funcionamiento de RsocksTun (en adelante, rs) se basa en dos componentes de software: el servidor Yamux y Socks5. El servidor Socks5 es un Socks5 local normal y se ejecuta en el cliente. Y la multiplexación de conexiones (¿recuerda el subproceso múltiple?) se proporciona mediante yamux (). Este esquema le permite iniciar varios servidores de calcetines de clientes5 y distribuirles conexiones externas, reenviándolas a través de una única conexión TCP (casi como en meterpreter) del cliente al servidor, implementando así un modo multiproceso, sin el cual simplemente no estaremos capaz de trabajar plenamente en las redes internas.
La esencia de cómo funciona yamux es que introduce una capa de flujo de red adicional, implementándola en forma de un encabezado de 12 bytes para cada paquete. (Aquí usamos deliberadamente la palabra "flujo" en lugar de hilo, para no confundir al lector con un "hilo" de flujo de programa; también usaremos este concepto en este artículo). El encabezado de yamux contiene el número de flujo, indicadores para instalar/terminar el flujo, la cantidad de bytes transferidos y el tamaño de la ventana de transferencia.
Además de instalar/terminar una transmisión, yamux implementa un mecanismo de mantenimiento de actividad que le permite monitorear el desempeño del canal de comunicación establecido. El funcionamiento del mecanismo de mensajes keeplive se configura al crear una sesión de Yamux. En realidad, de la configuración sólo hay dos parámetros: habilitar/deshabilitar y la frecuencia de envío de paquetes en segundos. Los mensajes Keepalive pueden ser enviados por un servidor yamux o un cliente yamux. Al recibir un mensaje de mantenimiento de actividad, la parte remota debe responder enviando exactamente el mismo identificador de mensaje (en realidad, un número) que recibió. En general, keepalive es el mismo ping, sólo que para yamux.
Toda la técnica operativa del multiplexor: tipos de paquetes, configuración de conexión y indicadores de terminación, y el mecanismo de transferencia de datos se describen en detalle en a yamux.
Conclusión de la primera parte.
Entonces, en la primera parte del artículo, nos familiarizamos con algunas herramientas para organizar túneles inversos, analizamos sus ventajas y desventajas, estudiamos el mecanismo de funcionamiento del multiplexor Yamux y describimos los requisitos básicos para el módulo PowerShell recién creado. En la siguiente parte desarrollaremos el módulo en sí, prácticamente desde cero. Continuará. No cambies :)
Fuente: habr.com