Marc-Andre MoreauDe todos los protocolos y plataformas compatibles con Remote Desktop Manager, RDP en Windows es, con diferencia, el más popular. Aunque Microsoft ofrece su cliente de escritorio remoto oficial en todas las plataformas excepto Linux, la única interfaz de cliente RDP expuesta para integración de terceros se encuentra en Windows. FreeRDP es el único cliente RDP multiplataforma adecuado, pero nunca estará a la altura del cliente RDP oficial de Windows (MSTSC). La realidad es que, para ofrecer las funciones que quieren nuestros clientes, necesitamos la flexibilidad de FreeRDP (código abierto), pero dentro del cliente RDP de Microsoft (código cerrado).
Construyendo nuestras propias puertas
Aunque el cliente RDP de Microsoft es excelente, no expone todo lo necesario para implementar todas las solicitudes de funciones que recibimos. Cuando nos topamos con un muro, se puede optar por detenerse o intentar construir nuevas puertas en lugares donde no las había. Esto es en lo que hemos estado trabajando con el proyecto Devolutions MsRdpEx: un conjunto de nuevas «puertas» que hemos abierto utilizando la Microsoft Detours Library para API hooking. Se basa en la interfaz pública RDP ActiveX para exponer componentes y propiedades internos que, de otro modo, no serían accesibles. Ya está disponible en RDM 2022.2 una primera versión de la función de API Hooking para RDP.
¿Qué es el API hooking?
El API hooking da más miedo del que en realidad tiene: modifica un programa en memoria para interceptar una llamada a una función y redirigirla a una función «hook» que usted controla. Por ejemplo, interceptando la función LoadLibrary, es posible modificar su comportamiento de manera que, al cargar «mstscax.dll», en realidad se cargue «MsRdpEx.dll». En otras palabras, se puede «engañar» a la aplicación alterando lo que la función realmente hace. No todas las funciones se pueden interceptar con facilidad: algunas están más sujetas a cambios que otras, o sencillamente quedan fuera de alcance.
Ingeniería inversa
Es de código cerrado, ¿verdad? Eso no solo significa que no hay documentación, sino que tampoco hay código fuente que examinar. Puede obtener más información sobre la ingeniería inversa de binarios de Microsoft en nuestra entrada del blog «Finding Secret RDP Registry Keys Using IDA Free». Este es, con diferencia, el proceso más tedioso y que más tiempo consume, incluso si el resultado final es simplemente cambiar un valor en algún lugar. Por ejemplo, nuestra integración no oficial de MSRDC dejó de funcionar hace poco con un misterioso código de error 3334, y nos llevó dos días completos de depuración intensiva descubrir que había que establecer una nueva propiedad interna en «true».
Opciones de RDP ampliadas
¿Qué tipo de opciones en el cliente RDP requieren API hooking? Aquí tiene una lista rápida:
- UserSpecifiedServerName: una opción interna necesaria para especificar el nombre del servidor para la validación de TLS y Kerberos, utilizada junto con el protocolo RD Gateway, pero no expuesta para conexiones RDP normales como las que hacemos con Devolutions Gateway.
- KDCProxyName: una opción documentada públicamente para inyectar un servidor proxy KDC de forma dinámica y permitir Kerberos, pero que solo se aplica en conexiones RD Gateway.
- UsingSavedCreds: una opción interna que se establece incorrectamente si se define una contraseña en el momento de la conexión, aunque no se guarde, lo que rompe la inyección de credenciales cuando está habilitada la directiva de grupo «Preguntar siempre por la contraseña al conectar».
- DisableUDPTransport: aunque cueste creerlo, esta opción interna solo se puede establecer mediante claves de registro, lo que impide un control detallado desde un gestor de conexiones.
Las dos primeras opciones, UserSpecifiedServerName y KDCProxyName, son esenciales para facilitar Kerberos fuera de la red corporativa, pero están restringidas específicamente al protocolo RD Gateway. Tenemos prevista una función de proxy KDC en Devolutions Gateway para aprovecharlas, pero habríamos preferido no tener que dar un rodeo tan largo con el API hooking para hacerlo posible.
Azure Virtual Desktop
Muchos usuarios han solicitado compatibilidad con Azure Virtual Desktop, y actualmente vamos por la mitad del proceso. Si todo va bien, deberíamos tener una primera integración de AVD en RDM 2022.3, con mejoras que se añadirán más adelante. Esta es la lista de retos a los que nos enfrentamos:
- MSRDC es necesario para AVD, pero no expone oficialmente una API para la integración.
- MSRDC exige que el RDP esté firmado del lado del servidor, lo que impide la gestión de configuraciones del lado del cliente.
- Las extensiones del protocolo AVD no están documentadas, a diferencia del protocolo RDP normal.
- Las llamadas de control de AVD para el webfeed de RDP realizadas con Azure tampoco están documentadas.
El primer paso ya está hecho: hemos conseguido integrar MSRDC para conexiones RDP normales, tanto en modo integrado como externo. MSRDC incluye de fábrica una DLL (rdclientax.dll) que expone la misma interfaz RDP ActiveX que la DLL integrada de MSTSC (mstscax.dll).
AVD añade unas 10 nuevas opciones de fichero RDP, con las correspondientes propiedades internas para el ActiveX. Averiguar simplemente cuáles eran y qué significaban ya supuso un reto, pero al menos hemos conseguido importarlas y exportarlas correctamente en RDM por ahora.
Una firma problemática
Todo iba bien hasta que nos topamos con un primer gran obstáculo: los ficheros RDP de AVD se firman del lado del servidor y se publican a través de un webfeed especial que solo MSRDC sabe cómo obtener. Sin embargo, MSRDC no establecerá conexiones AVD con ficheros RDP sin firmar, y no se pueden modificar las opciones de RDP del lado del cliente sin romper la firma. Houston, tenemos un problema.
Cuando Remote Desktop Manager lanza MSTSC o MSRDC en modo externo, genera un fichero .RDP temporal con todas las opciones de la entrada de conexión. Si edita la entrada de conexión RDP en RDM, obtendrá un fichero RDP diferente. La única forma de evitarlo es crear una entrada de conexión vinculada a un fichero RDP local sin modificar, pero entonces tampoco se puede modificar.
¿Por qué no firmar los ficheros localmente? Lo hemos considerado, pero esto requiere un certificado de una autoridad conocida y de confianza. Las estrategias de API hooking para usar una firma válida a partir de un certificado autofirmado también eran limitadas. Nos costó unas dos semanas de esfuerzo dar finalmente con una forma de eludir la comprobación de la firma del fichero RDP para las conexiones AVD, y lograr una primera conexión AVD lanzada con MSRDC desde RDM.
¿Hemos llegado ya?
Estamos avanzando de forma lenta, pero constante. Las conexiones AVD tienen un contexto de autenticación adicional con Azure, y gestionarlo correctamente será un proyecto en sí mismo. La inyección de las credenciales RDP normales también está rota, así que probablemente tendremos que encontrar una forma diferente de hacerlo. La interfaz de usuario para las opciones específicas de AVD aún no está terminada, y resulta difícil nombrarlas y estructurarlas correctamente cuando no están documentadas. El objetivo actual es que funcione primero con MSRDC como programa externo, ya que las conexiones AVD con MSRDC en modo integrado conllevan un conjunto de retos diferente.
Conclusión
El API hooking es estupendo, pero debería considerarse un último recurso. Idealmente, la mayoría de estas opciones ampliadas se habrían expuesto públicamente de forma oficial, de modo que no tuviéramos que dedicar todo este tiempo a la ingeniería inversa y al hooking de APIs. ¿Es usted cliente de Azure Virtual Desktop? Si no lo es, ¿le interesaría usar MSRDC en lugar de MSTSC? Como ninguno de estos dos casos cuenta con soporte oficial, ¡le agradeceríamos que enviara sus comentarios a Microsoft al respecto!