Conector de canal virtual dinámico universal para Servicios de Escritorio Remoto (UDVC)

Los Servicios de Terminal (o Servicios de Escritorio Remoto) ofrecen muchas funciones ocultas para aquellos que quieran profundizar. Uno de estos servicios es el Canal Virtual Dinámico que nos permite comunicarnos a través de una conexión RDP abierta sin necesidad de abrir un nuevo socket, conexión o puerto en un firewall. Estos canales pueden utilizarse para ocultar datos de los dispositivos de red activos, para evadir firewalls, para implementar controladores de dispositivos a través de redes o simplemente para ayudar a los pentesters a transferir datos. Las posibilidades son infinitas.

La verdadera razón por la que se creó este proyecto es XFLTReaT. Este podría usarse para construir una "VPN" sobre redes segregadas y, finalmente, permite realizar pruebas a través de jumpboxes sin solicitar cambios en el firewall. En resumen, hace la vida más fácil a los pentesters.

¿Cómo funciona esto?

Debe instalar un plugin (.dll) en su equipo cliente que use para conectarse al servidor RDP. En el servidor RDP debe usar la otra mitad del proyecto, el .exe, que crea el canal entre el plugin y el ejecutable del servidor. Si desea conocer más detalles, desplácese hacia abajo.

Instalación

Es solo para Windows. Los Canales Virtuales Dinámicos se introdujeron en Windows Server 2008 y Windows Vista SP1. Estas versiones y cualquier otra posterior deberían funcionar.

Puede descargar todo el proyecto y compilarlo usted mismo o simplemente usar los binarios compilados de la sección Releases. Es importante que se use el binario correcto en todos los casos; seleccione el adecuado para la arquitectura correspondiente (si su cliente es de 32 bits pero el servidor es de 64 bits, entonces coja la dll de 32 bits y el exe de 64 bits).

El .dll debe colocarse en el equipo cliente en cualquier directorio (para uso a largo plazo, puede ponerlo en %SYSROOT%\system32\ o %SYSROOT%\SysWoW64\) e instalarlo con el siguiente comando como usuario elevado (también conocido como Administrador): regsvr32.exe UDVC-Plugin.dll

Si su usuario no es administrador, también debe importar la configuración del registro bajo su usuario. Utilice el archivo UDVC-Plugin.reg para ello.

Si desea eliminarlo: regsvr32.exe /u UDVC-Plugin.dll

A partir de ahora, cada vez que se conecte a un servidor RDP, este plugin se cargará y se configurará según lo especificado en el registro (ver más abajo).

El .exe debe colocarse en el servidor RDP y ejecutarse como cualquier usuario.

Modos compatibles

Ambos lados soportan tres modos por el momento:

Modo servidor de socket (0 - predeterminado)

Cuando este modo está habilitado, se configurará un listener en el puerto y la interfaz (dirección IP) definidos.

Modo cliente de socket (1)

En este modo se realizará una conexión hacia un listener en la dirección IP y el puerto definidos.

Modo de tubería con nombre (2)

Este modo configura una tubería con nombre con el nombre especificado. Por ejemplo: este modo puede ser usado por otras herramientas para realizar comunicación IPC a través de RDP. Desafortunadamente, las tuberías con nombre se escriben en el disco, por lo que se consideran lentas en comparación con los modos de socket. Si le importa el ancho de banda, use los modos de socket.

Opciones/Configuración

Tanto el binario del cliente como el del servidor actúan de la misma manera y pueden configurarse con las mismas opciones.

• enabled: 0 deshabilitado, 1 habilitado (solo plugin). Por defecto está habilitado y le avisará en un cuadro de mensaje cada vez que inicie una conexión.
• mode: 0 para listen(), 1 para connect() y 2 para crear una tubería con nombre
• ip: qué IP conectar o a la que vincularse
• port: qué puerto conectar o al que vincularse
• namedpipename: nombre de la tubería con nombre
• priority (solo binario del servidor) prioridades LOW, MEDIUM, HIGH, REAL para la transmisión de datos. La prioridad REAL podría afectar gravemente la accesibilidad de la sesión en caso de una transferencia de datos intensa, ya que el protocolo prioriza los datos sobre el control.

El binario del servidor leerá las opciones desde la línea de comandos.

PS C:\Users\UDVC\> .\UDVC-Server.exe -h
Universal Dynamic Virtual Channel server application

Usage: C:\Users\UDVC\UDVC-Server.exe [-s | -c [-p port [-h ip]] | -m [-n name]] [-0 | -1 | -2 | -3]
Socket server mode -s (default) OR
Socket client mode -c:
        -p port   port to bind the listener (default: 31337)
        -i ip     ip to bind the listener (default: 127.0.0.1)

Named pipe mode -m:
        -n name   name of the named pipe (by default: "\\.\pipe\UDVC_{RDP SESSION NUMBER}")

Data transfer priority parameters:
        -0        real time             (WTS_CHANNEL_OPTION_DYNAMIC_PRI_REAL)
        -1        high priority         (WTS_CHANNEL_OPTION_DYNAMIC_PRI_HIGH) - default
        -2        medium priority       (WTS_CHANNEL_OPTION_DYNAMIC_PRI_MED)
        -3        low priority          (WTS_CHANNEL_OPTION_DYNAMIC_PRI_LOW)

El .dll del cliente lee todas las opciones del registro; los valores se pueden encontrar bajo la siguiente clave: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\Default\AddIns\UDVC-Plugin

Cada vez que el módulo está habilitado y antes de que se realice la conexión, se muestra un aviso recordatorio. Justo así:

Este aviso garantiza que el usuario sepa que el plugin está cargado y con qué configuración.

Uso

Los listeners, las conexiones o las tuberías con nombre solo se crean cuando el ejecutable del servidor pudo conectarse a la dll del plugin. Depende de su configuración, pero por defecto, cuando se realiza la conexión del Canal Virtual (el plugin se cargó correctamente, el binario del servidor se ejecutó), escucha en localhost:31337 en ambos extremos. Cuando se conecte a estos puertos y envíe datos a través del socket, aparecerán en el otro lado.

Ejemplos de casos de uso

Solo para mostrar algunos casos de uso donde se puede utilizar esta herramienta.

Redireccionamiento de puertos muy básico. La máquina Segregated 1 tiene un servicio HTTP en tcp/80. Esa red no está enrutada desde la red 192.168.0.0/24; se debe usar el jump box de doble interfaz para acceder. El modo listen está configurado en el lado del cliente en 0.0.0.0:31337 y el binario del servidor se ejecutó con la configuración del modo connect para crear una conexión al servidor web. El usuario en el cliente RDP puede usar su navegador para abrir http://127.0.0.1:31337 y acceder al contenido de http://10.13.37.2:80.

Un escenario un poco más avanzado para transferir archivos. Ambos extremos están configurados para escuchar en 0.0.0.0:31337. Primero, la máquina Hacking se conecta al cliente RDP y espera la entrada. Luego, la máquina Segregated 2 se conecta al Jump box y lee todo el archivo en el socket.

Como extra, también se pueden usar tuberías con nombre. En este caso, tanto el cliente RDP como el Jump box crean una tubería con nombre en ambos lados (hIPC-client y hIPC-server) y las otras máquinas pueden conectarse a estas tuberías. Todo lo que se escriba en las tuberías aparecerá en el otro extremo. No es realmente diferente del ejemplo del modo listen anterior, excepto que usa tuberías con nombre en lugar de sockets TCP.

Problemas

En caso de que el plugin no se cargue o el ejecutable no se ejecute porque faltan algunas DLL, por ejemplo la VCRUNTIME140.DLL, es posible que desee instalar el paquete Visual C++ Redistributable para Visual Studio 2015.