Historia de investigación y desarrollo en 3 partes. Parte 1 - investigación.
Hay muchas letras, pero aún más beneficios.
Planteamiento del problema
Durante la realización de pruebas de penetración y campañas de Red Team, no siempre es posible utilizar las herramientas estándar del Cliente, como VPN, RDP, Citrix, etc. para acceder a la red interna. En algunos lugares, la VPN estándar funciona con MFA y se utiliza un token físico como segundo factor; en otros, es supervisada estrictamente y nuestra entrada a través de VPN se hace visible inmediatamente, como se dice, con todas las consecuencias, y en otros simplemente no hay tales medios.
En tales casos, constantemente hay que establecer lo que se llaman "túneles inversos" - conexiones de la red interna a un recurso externo o servidor que controlamos. Dentro de dicho túnel, ya podemos trabajar con los recursos internos del Cliente.
Existen varias variedades de tales túneles inversos. El más conocido, por supuesto, es Meterpreter. También hay gran demanda entre las masas de hackers de túneles SSH con redirección de puertos inversa. Hay muchas maneras de realizar el túnel inverso y muchas de ellas están bien estudiadas y documentadas.
Por supuesto, los desarrolladores de soluciones de seguridad no se quedan al margen y están detectando activamente tales acciones.
Por ejemplo, las sesiones de MSF son detectadas exitosamente por los IPS modernos de Cisco o Positive Tech, y un túnel SSH inverso puede ser detectado prácticamente por cualquier firewall normal.
Por lo tanto, para permanecer indetectable en una buena campaña de Red Team, necesitamos construir un túnel inverso utilizando medios no estándar y adaptarnos lo más posible al modo de operación real de la red.
Intentemos encontrar o inventar algo similar.
Antes de inventar algo, es necesario entender qué resultado queremos alcanzar, qué funciones debe cumplir nuestro desarrollo. ¿Cuáles serán los requisitos para el túnel para que podamos trabajar en un modo de máxima discreción?
Es obvio que estos requisitos pueden variar, pero, según la experiencia, se pueden destacar algunos principales:
- trabajo en sistema operativo Windows 7-10, ya que en la mayoría de las redes corporativas se utiliza precisamente Windows.
- El cliente se conecta al servidor a través de SSL para evitar la escucha pasiva por parte de sistemas IPS;
- Al conectarse, el cliente debe admitir el funcionamiento a través de un proxy autenticado, ya que en muchas empresas el acceso a Internet se realiza mediante un proxy. De hecho, el equipo del cliente puede no ser consciente de esto, y el proxy se utiliza en modo transparente. Sin embargo, debemos incluir tal funcionalidad;
- La parte del cliente debe ser concisa y portable;
Es evidente que para trabajar dentro de la red del Cliente, se puede instalar OpenVPN en la máquina del cliente y establecer un túnel completo hacia su servidor (afortunadamente, los clientes de OpenVPN pueden trabajar a través de proxies). Sin embargo, en primer lugar, esto no siempre será posible, ya que podríamos no ser administradores locales allí, y en segundo lugar, generará tanto ruido que cualquier SIEM o HIPS inmediatamente alertará sobre nuestra actividad. Idealmente, nuestro cliente debería ser lo que se llama un equipo 'inline', como los muchos shells de bash implementados, y ejecutarse a través de la línea de comandos, por ejemplo, al ejecutar comandos desde un macro de Word. - Nuestro túnel debe ser multihilo y soportar múltiples conexiones simultáneamente;
- La conexión cliente-servidor debe tener algún tipo de autenticación para que el túnel se establezca únicamente para nuestro cliente, y no para cualquiera que acceda a nuestro servidor en la dirección y puerto especificados. Idealmente, a los 'usuarios externos' se les debería abrir una página de aterrizaje con gatos o contenido profesional relacionado con el dominio de origen.
Por ejemplo, si el Cliente es una organización médica, el administrador de seguridad de la información que decida verificar el recurso al que se dirigió un empleado de la clínica debería ver una página con productos farmacéuticos, una Wikipedia sobre la descripción de un diagnóstico o un blog del doctor Komarovsky, etc.
Análisis de herramientas existentes
Antes de inventar nuestra propia bicicleta, es necesario analizar las bicicletas existentes y comprender si realmente las necesitamos y, probablemente, no somos los únicos que hemos considerado la necesidad de una bicicleta funcional como esta.
Buscar en Internet (parece que lo hacemos bastante bien), así como buscar en GitHub con las palabras clave «reverse socks» no ha dado muchos resultados. En su mayoría, todo se reduce a la construcción de túneles SSH con reenvío de puertos inverso y todo lo relacionado. Además de los túneles SSH, se pueden destacar algunas soluciones:
Una antigua implementación de túnel inverso de chicos del Laboratorio Kaspersky. Por el nombre, está claro para qué se destina este script. Está implementado en Python 2.7, el túnel funciona en modo cleartext (como se dice ahora — saludo a la RKN)
Otra implementación en Python, también en cleartext, pero con más funcionalidades. Está escrito como un módulo y tiene API para integrar la solución en tus proyectos.
El primer enlace es la versión original de la implementación de reverse socks en Go (no está soportada por el desarrollador).
El segundo enlace es nuestra adaptación con características adicionales, también en Go. En nuestra versión hemos implementado SSL, trabajo a través de proxy con autenticación NTLM, autorización en el cliente, una página de inicio al introducir una contraseña incorrecta (mejor dicho, redirección a la página de inicio), modo multihilo (es decir, varias personas pueden trabajar con el túnel simultáneamente), y un sistema de pings del cliente para comprobar si está vivo o no.
Implementación de reverse socks de nuestros «amigos chinos» en Python. También hay un binario listo (exe), compilado por los chinos y listo para usar. Aquí, solo un dios chino sabe qué más puede haber en este binario, además de la funcionalidad principal, así que úsalo bajo tu propio riesgo.
Un proyecto bastante interesante en C++ para implementar reverse socks y más. Además del túnel inverso, puede hacer reenvío de puertos, crear un shell por comandos, etc.
MSF meterpreter
Aquí, como se suele decir, sin comentarios. Todos los hackers medianamente educados están perfectamente familiarizados con esta herramienta y entienden lo fácil que es detectarla con los medios de protección.
Todas las herramientas descritas funcionan con una tecnología similar: se ejecuta un módulo binario preparado previamente en una máquina dentro de la red, que establece una conexión con un servidor externo. En el servidor se inicia un servidor SOCKS4/5, que acepta conexiones y las retransmite al cliente.
La desventaja de todas las herramientas mencionadas es que, o es necesario tener Python o Golang instalado en la máquina cliente (¿con qué frecuencia han encontrado Python instalado en las computadoras, por ejemplo, de un director de empresa o de empleados de oficina?), o hay que llevar un binario previamente compilado (de hecho, Python y el script en un solo paquete) y ejecutar ese binario allí. Y cargar un exe seguido de su ejecución es un signo claro para el antivirus local o HIPS.
En general, la conclusión es evidente: necesitamos una solución en PowerShell. Ahora nos lloverán tomates: dirán que PowerShell ya está muy visto, que se monitoriza, que se bloquea, etc. En realidad, no es así en todos lados. Lo decimos con responsabilidad. Por cierto, hay un montón de maneras de sortear bloqueos (aquí nuevamente la famosa frase sobre el saludo a Roskomnadzor 🙂), desde renombrar simplemente powershell.exe a cmdd.exe y hasta powerdll, etc.
Empezamos a inventar
Es evidente que primero buscaremos en Google y… no encontraremos absolutamente nada sobre este tema (si alguien ha encontrado algo, por favor comparta los enlaces en los comentarios). Solo hay Socks5 en PowerShell, pero es un socks "directo" que tiene varias desventajas (hablaremos de ellas más adelante). Claro, es posible transformarlo fácilmente en un socks inverso, pero eso solo será un socks de un solo hilo, que no es exactamente lo que necesitamos.
Así que no encontramos nada listo, por lo que tendremos que inventar nuestra propia bicicleta. Tomaremos como base nuestra de socks inverso en Golang, y realizaremos el cliente en PowerShell.
RSocksTun
Entonces, ¿cómo funciona rsockstun?
La base del funcionamiento de RsocksTun (en adelante, rs) consiste en dos componentes de software: Yamux y el servidor Socks5. El servidor Socks5 es un socks5 local normal, se inicia en el cliente. Y la multiplexación de conexiones hacia él (recuerden sobre el multihilo) se asegura a través de yamux (). Este esquema permite iniciar varios servidores socks5 para clientes y distribuir las conexiones externas a ellos, transmitiéndolas a través de una única conexión TCP (casi como en meterpreter) del cliente al servidor, implementando así un modo multihilo, sin el cual simplemente no podemos operar completamente en una red interna.
La esencia del funcionamiento de yamux es que introduce un nivel de red adicional de streams, realizándolo en forma de un encabezado de 12 bytes para cada paquete. (Aquí usamos intencionadamente la palabra “stream” y no “flujo”, para no confundir al lector con el término de “thread” que también utilizaremos en este artículo). Dentro del encabezado de yamux se contienen el número de stream, banderas para establecer/terminar el stream, número de bytes transmitidos y tamaño de ventana de transmisión.
Además de la configuración/terminación del stream, yamux implementa un mecanismo de keepalive que permite monitorear la operatividad del canal de comunicación establecido. El funcionamiento del mecanismo de mensajes keepalive se establece al crear una sesión de Yamux. En realidad, solo hay dos parámetros en la configuración: habilitar/deshabilitar y la periodicidad de envío de paquetes en segundos. Tanto el servidor yamux como el cliente yamux pueden enviar mensajes keepalive. Al recibir un mensaje keepalive, la parte remota debe responderlo enviando exactamente el mismo identificador de mensaje (de hecho, un número) que ha recibido. En resumen, keepalive es como un ping, pero para yamux.
Se detallan toda la técnica de funcionamiento del multiplexor: tipos de paquetes, banderas de establecimiento y finalización de conexiones, mecanismo de transmisión de datos en yamux.
Conclusión de la primera parte
Así, en la primera parte del artículo, nos familiarizamos con algunas herramientas para la organización de túneles inversos, observamos sus ventajas y desventajas, estudiamos el mecanismo de trabajo del multiplexor Yamux y describimos los requisitos básicos para el nuevo módulo de powershell que vamos a crear. En la siguiente parte, nos dedicaremos al desarrollo del módulo desde cero. Continuará 🙂
Fuente: habr.com
