Protocolo de Escritorio Remoto (RDP): Explicado de Manera Simple

RDP es un protocolo extremadamente popular para el acceso remoto a máquinas Windows. De hecho, hay más de 4,5 millones de servidores RDP expuestos a Internet, y muchos más que son accesibles desde las redes internas.

La importancia de conocer y comprender RDP nunca ha sido mayor, especialmente a la luz de las recientes vulnerabilidades críticas que se han encontrado en el protocolo. Ahora es un conocimiento esencial que es absolutamente crucial para todos en la industria de la seguridad. RDP es un protocolo complejo con muchas extensiones y el potencial de encontrar nuevos errores críticos sigue siendo alto. Por ello, el sector de la seguridad debe formarse en él.

RDP es relevante ahora más que nunca, ya que las plataformas Azure e Hyper-V de Microsoft lo utilizan como protocolo de conexión remota por defecto y ha aumentado el interés de los atacantes por este protocolo, tanto como vector de infección inicial como método de propagación.

En este artículo repasaremos los fundamentos de RDP, su funcionamiento y cómo encajan algunas de las vulnerabilidades críticas encontradas en RDP en el panorama general de una conexión RDP real. Esperamos que te vayas con una comprensión básica del protocolo para que puedas continuar leyendo e investigando más sobre el protocolo para cualquier necesidad futura.

RDP: Lo básico

“El Protocolo de Escritorio Remoto (RDP) de Microsoft proporciona capacidades de visualización y entrada remotas a través de conexiones de red para aplicaciones basadas en Windows que se ejecutan en un servidor“. (MSDN)

Esencialmente, RDP permite a los usuarios controlar su máquina Windows remota como si estuvieran trabajando en ella localmente (bueno, casi).

La comunicación en RDP se basa en múltiples canales, y el protocolo soporta teóricamente hasta 64.000 canales únicos.

La funcionalidad básica de RDP es transmitir un monitor (dispositivo de salida) desde el servidor remoto al cliente y el teclado y/o el mouse (dispositivos de entrada) desde el cliente al servidor remoto. La comunicación durante una conexión RDP será extremadamente asimétrica, mientras que la mayoría de los datos irán del servidor al cliente. La comunicación RDP está encriptada con el cifrado en bloque RC4 de RSA por defecto.

Antes de entrar en cómo funciona realmente una conexión RDP, vamos a examinar los protocolos/estándares en los que se basa RDP. La pila de protocolos RDP tiene el siguiente aspecto:

TPKT se conoce como el Servicio de Transporte ISO sobre TCP (ISO Transport Service on top of TCP). TPKT permite a los pares intercambiar unidades de información que se conocen como Unidades de Datos del Protocolo de Transporte (TPDU o PDU).

X.224 es un protocolo de transporte orientado a la conexión, que proporciona un servicio de transporte en modo conexión. RDP lo utiliza en la solicitud y respuesta de conexión inicial.

T.125 MCS es un servicio de comunicación multipunto. Permite a RDP comunicarse a través de múltiples canales y gestionarlos.

El envío y la recepción de datos a través de la pila de RDP es esencialmente lo mismo que el modelo OSI de 7 capas para la comunicación. Los datos transmitidos se seccionan, se dirigen a un canal, se encriptan, se envuelven, se enmarcan y se empaquetan antes de pasar por el cable a la otra parte, y luego pasan por el mismo proceso a la inversa.

La implementación de MS RDP ha abstraído toda la complejidad de la pila de protocolos, y permite a los desarrolladores escribir extensiones al protocolo fácilmente.

Conexión RDP

En esta parte, explicaremos los fundamentos de una conexión RDP. Ten en cuenta que, en aras de la simplicidad, se han omitido algunos detalles. Para más información sobre la conexión (incluyendo las estructuras exactas, las constantes, etc.) por favor vea .

Secuencia de conexión

La conexión RDP puede dividirse en varias etapas: (ver Connection Sequence)

• Inicio de la Conexión (Connection Initiation)
• Intercambio de Configuración Básica (Basic Settings Exchange)
• Conexión del Canal (Channel Connection)
• Comienzo de la Seguridad (Security Commencement)
• Intercambio de Configuración Segura (Secure Settings Exchange)
• Licencia (Licensing)
• Intercambio de Capacidades (Capabilities Exchange)
• Finalización de la Conexión (Connection Finalization)
• Intercambio de Datos (Data Exchange)

Iniciación de la Conexión (Connection Initiation)

La conexión RDP es iniciada por el cliente utilizando un PDU de solicitud de conexión X.224. Este paquete contiene una Solicitud de Negociación (Negotiation Request) RDP que contiene algunas banderas de conexión y los protocolos de seguridad soportados por el cliente. Estos protocolos de seguridad pueden estar en una de dos categorías:

Seguridad RDP estándar

• Por defecto de cifrado RC4 de RSA

Seguridad RDP mejorada

• TLS
• CredSSP (TLS + NTLM/Kerberos)
• RDSTLS – RDP mejorado con TLS

Más información sobre la Seguridad RDP está disponible en la siguiente sección.

La conexión es confirmada por el servidor mediante un PDU de confirmación de conexión X.224. Este paquete contiene la Respuesta de Negociación (Negotiation Request) RDP que se utiliza para informar al cliente del protocolo de seguridad seleccionado (elegido entre los protocolos soportados por el cliente) que se utilizará durante toda la vida de la conexión.

A partir de este punto, los datos subsiguientes se envolverán en una PDU de datos (Data PDU) X.224.

Intercambio de Ajustes Básicos (Basic Settings Exchange)

En esta fase, se intercambian los ajustes básicos entre el cliente y el servidor mediante una MCS Connect Initial PDU y una MCS Connect Response PDU (respectivamente). Estos ajustes (tanto del cliente como del servidor) incluyen:

• Datos básicos – Versión de RDP, resolución del escritorio, profundidad de color, información del teclado, nombre de host, información del software del cliente (ID del producto, número de compilación), etc.
• Datos de seguridad – Métodos de encriptación, tamaño de las claves de sesión, servidor aleatorio (utilizado posteriormente para crear las claves de sesión) y certificado del servidor (algunos de estos datos sólo son relevantes cuando se utiliza la seguridad RDP estándar).
• Datos de red – Información sobre los canales virtuales solicitados y asignados. Esto contiene el número de canales y una matriz de canales virtuales específicos. El cliente solicita el tipo exacto de canales en la petición, y el servidor proporciona los IDs de los canales reales en la respuesta. Para más información sobre estos canales, ve la sección Canales en RDP más abajo.

Conexión del Canal (Channel Connection)

Después de establecer la lista de canales virtuales que se utilizarán en la sesión RDP, llega la etapa en la que se realiza la conexión de cada canal individual. Esto tiene algunas sub-etapas:

• MCS Erect Domain Request – Altura en el dominio MCS. Como RDP no aprovecha las topologías avanzadas de MCS, será 0.
• MCS Attach User Request – solicitud de un ID de canal de usuario
• MCS Attach User Confirm – ID del Canal de Usuario
• (+5) MCS Channel Join Requests and Confirmations – El cliente comenzará a solicitar la unión de los canales virtuales utilizando sus IDs. Empezando por el Canal de Usuario (User Channel), el Canal de E/S (I/O Channel) y continuando con los canales virtuales negociados en el intercambio de configuración básica. El servidor, a su vez, confirmará cada unión de canales exitosa.

A partir de este momento, los datos subsiguientes enviados por el cliente se envolverán en una MCS Send Data Request PDU, mientras que los datos enviados por el servidor se envolverán en una MCS Send Data Indication PDU. Los datos pueden ahora ser redirigidos a canales virtuales.

Comienzo de la Seguridad (Security Commencement)

El cliente envía una PDU de Intercambio de Seguridad (Security Exchange PDU) que contiene los números aleatorios del cliente cifrados con la clave pública del servidor. A continuación, el cliente y el servidor utilizan los números aleatorios (tanto de los Basic Settings Exchange’s Security Data como de la Security Exchange PDU) para crear las claves de cifrado de la sesión.

A partir de este momento, el tráfico RDP posterior puede ser encriptado.

Intercambio Seguro de Configuraciones (Secure Settings Exchange)

En este punto, el cliente envía una Client Info PDU encriptada que contiene información sobre los tipos de compresión soportados, el dominio del usuario, el nombre de usuario, la contraseña, el directorio de trabajo, etc.

Licencia (Licensing)

Esta etapa está diseñada para permitir que los usuarios autorizados se conecten a un servidor de terminales. Es decir, soportar más de 2 conexiones simultáneas (que es el valor por defecto de “Windows’ RDP Server”) a un servidor. Esto requiere la compra de una licencia de Microsoft.

En muchos casos, no se configura ningún servidor de licencias para el servidor RDP, en ese caso, el servidor RDP simplemente enviará una PDU al cliente que “aprueba” su licencia (sólo hasta 2 sesiones).

Puedes encontrar más información sobre la fase de licencia extendida y la comunicación entre el servidor RDP y el servidor de licencias aquí .

Intercambio de Capacidades (Capabilities Exchange)

El servidor envía sus capacidades soportadas en una Demand Active PDU. Esta PDU contiene una estructura que tiene muchas capacidades de diferentes tipos. Según Microsoft, tenemos 28 tipos de conjuntos de capacidades. Los principales tipos son generales (versión del sistema operativo, compresión general), de entrada (tipo de teclado y características, soporte de ruta rápida, etc.), fuentes, canales virtuales, códecs de mapas de bits y muchos más. A continuación, el servidor puede enviar o no una Monitor Layout PDU para describir los monitores de visualización del servidor. El cliente responderá entonces con una Confirm Active PDU que contiene su propio conjunto de capacidades.

Finalización de la Conexión (Connection Finalization)

El cliente y el servidor intercambian algunos tipos de PDU para finalizar la conexión. Todas esas PDU se originan en el cliente (las PDU pueden enviarse una tras otra sin esperar una respuesta). Las PDUs son:

• Client/Server Synchronize PDU – Se utiliza para sincronizar los identificadores de usuario entre el cliente y el servidor.
• Client/Server Control PDU (Cooperar) – Tanto el cliente como el servidor envían esta PDU para indicar el control compartido sobre la sesión.
• Client Control PDU (solicitar/otorgar control) – El cliente envía la solicitud de control, el servidor la otorga.
• Persistent Key List PDU/PDUs (opcional): el cliente envía al servidor una lista de claves, cada una de las cuales identifica un mapa de bits en caché. Esto permite que la caché del mapa de bits sea persistente (en lugar de limitarse a la duración de la conexión). El almacenamiento en caché de mapas de bits es un mecanismo utilizado para reducir el tráfico de red necesario para transferir una salida gráfica del servidor al cliente.
• Font List/Map PDU – estos PDUs debían contener información sobre las fuentes para la sesión RDP (nombre de la fuente, ancho medio, firma, etc.), sin embargo, parece que Microsoft no lo está utilizando. Dicho esto, estos PDUs todavía se intercambian entre el cliente y el servidor en ese punto, pero sin datos reales en él (incluso si hubiera algún dato, la documentación de Microsoft especifica que debes ignorarlo).

Intercambio de Datos (Data Exchange)

Una vez finalizada la conexión, la mayor parte de los datos enviados entre el cliente y el servidor serán datos de entrada (cliente->servidor) y datos gráficos (servidor->cliente). Otros datos que pueden transferirse son la información de gestión de la conexión y los mensajes del canal virtual.

Entradas y Salidas Básicas

Durante la vida de la conexión, el cliente y el servidor intercambian datos básicos de entrada y salida. El cliente envía la entrada y el servidor la salida.

Datos de entrada – Contiene información del mouse y del teclado, así como la sincronización periódica (por ejemplo, el estado de las teclas NAM_LOCK / CAPS_LOCK)

Datos de salida – Los datos de salida fundamentales contienen imágenes de mapa de bits de la sesión del usuario en el servidor. Además, el servidor puede enviar información sonora (sólo en forma de “bip” muy básico – frecuencia + duración).

Estos datos básicos de entrada/salida pueden transmitirse de dos maneras: slow-path o fast-path.

Slow-Path – PDU normal con todas las cabeceras de la pila del protocolo RDP

Fast-Path – Como su nombre indica, se creó para reducir tanto la cantidad de datos transmitidos como la cantidad de procesamiento necesario para procesarlos. Esto se hace reduciendo/eliminando las cabeceras de la PDU de ciertos tipos de PDU (por ejemplo, la entrada del teclado/mouse).

Canales en RDP

En RDP, la mayoría de los datos se transportan a través de diferentes canales (capa MCS). Hay dos tipos principales de canales: Canales Virtuales Estáticos (SVC) y Canales Virtuales Dinámicos (DVC).

Static Virtual Channels (SVC)

Los SVCs permiten la comunicación entre diferentes componentes del cliente y del servidor a través de la conexión principal de datos RDP. Hay un máximo de 31 canales virtuales estáticos por conexión y cada canal actúa como un flujo de datos independiente. Estos canales son estáticos porque son solicitados y creados en la fase de intercambio de configuración básica durante el inicio de la conexión, y no cambian en absoluto durante la sesión.

No todos los SVC se crean igual, algunos se abren por defecto y otros se negocian durante la fase de intercambio de ajustes básicos. Los SVCs que se crean por defecto son cruciales para la funcionalidad de una conexión RDP, mientras que los otros habilitan diferentes extensiones para el protocolo.

Ejemplos de SVCs creados por defecto:

• Canal de E/S
• Canal de Mensajes
• Canal de Usuario
• Canal de Servidor

Los SVC de extensión se identifican con un nombre de 8 bytes, por ejemplo

• rdpdr – Extensión del sistema de archivos. Permite redirigir el acceso del servidor al sistema de archivos del cliente.
• rdpsnd – Extensión de salida de sonido.
• cliprdr – Extensión del portapapeles. Permite compartir el portapapeles entre el cliente y el servidor.
• drdynvc – Extensión de canal virtual dinámico (ver DVCs más abajo).

Todos los IDs de los canales SVCs se suministran durante la fase de Intercambio de Ajustes Básicos (Basic Settings Exchange) excluyendo 2 SVCs: el Canal de Usuario (User Channe) que se suministra durante la fase de Conexión de Canales (Channel Connection) en la Attach User Confirm PDU, y el Canal de Servidor (Server Channel) que tiene un valor fijo de 0x03EA (1002).

Dynamic Virtual Channels (DVC)

Dado que el número de canales virtuales estáticos está limitado a 31, RDP también soporta canales virtuales dinámicos. Los Canales Virtuales Dinámicos son transportados sobre un Static Virtual Channel – DRDYNVC específico. Estos canales son dinámicos ya que se pueden crear y destruir en cualquier etapa de la vida de la conexión (después de la inicialización). Los desarrolladores pueden crear extensiones que transporten datos a través de un Canal Virtual Dinámico con bastante facilidad. Los usos más comunes de los DVC son la entrada de audio (cliente -> servidor), la redirección PnP, el renderizado de gráficos, el canal de eco, la redirección de vídeo y otros.

La siguiente figura describe la relación entre los diferentes tipos de canales en RDP:

Compresión de Datos

RDP puede utilizar la compresión en los datos de salida (tanto fast-path como slow-path) y en los canales virtuales. Tanto el cliente como el servidor deben soportar la compresión en general, y el tipo específico de compresión negociado para la conexión. El cliente anuncia los tipos de compresión que admite en la PDU de información del cliente durante el Intercambio de Configuración Segura (Secure Settings Exchange).

Cada PDU que contenga datos comprimidos, necesita tener algunos indicadores de compresión (que contengan el tipo de compresión, etc.) establecidos en la cabecera de esa PDU específica.

Seguridad del RDP

Como ya se ha mencionado brevemente, la seguridad del protocolo RDP puede ser de dos tipos:

Seguridad estándar

El tráfico se cifra mediante el algoritmo de encriptación RC4 de RSA, utilizando valores aleatorios del cliente y del servidor que se intercambian durante la fase de intercambio de configuración básica en la inicialización de la conexión.

Seguridad mejorada

Este tipo de seguridad permite a RDP externalizar todas las operaciones de seguridad (cifrado/descifrado, comprobaciones de integridad, etc.) a un protocolo de seguridad externo. Este puede ser uno de los siguientes:

• TLS 1.0/1.1/1.2
• CredSSP
• RDSTLS

La decisión de un protocolo de seguridad mejorado puede ser basada en la negociación o directa. La basada en la negociación significa que la inicialización de la conexión (solicitud y respuesta de conexión x.224) queda fuera del ámbito del protocolo de seguridad. Después de la inicialización, el cliente y el servidor eligen un protocolo de seguridad, hacen el handshake del protocolo de seguridad externo y, a partir de ahora, todas las demás etapas de la conexión RDP se encapsularán dentro de ese protocolo de seguridad externo.

La otra opción, el enfoque directo, favorece la seguridad sobre la compatibilidad. En este enfoque, el cliente comenzará con el handshake del protocolo de seguridad externo antes de enviar cualquier dato relacionado con el RDP.

Elegir la seguridad mejorada significa que la etapa de inicio de seguridad no se ejecutará.

El beneficio clave de usar la Seguridad Mejorada RDP (RDP Enhanced Security) es que permite la Autenticación de la Capa de Red o Network Layer Authentication (detalles disponibles más abajo).

Network Layer Authentication

La Autenticación a Nivel de Red (NLA) se refiere al uso de CredSSP para autenticar al usuario antes de iniciar la conexión RDP. Esto permite que el servidor dedique recursos sólo a los usuarios autenticados.

En caso de una vulnerabilidad crítica en el protocolo RDP, NLA puede limitar la explotación de esta vulnerabilidad sólo a los usuarios autenticados.

Vulnerabilidades RDP Recientes

Ahora que entendemos los fundamentos del protocolo RDP, revisemos algunas de las vulnerabilidades críticas más recientes que se han encontrado, y veamos cómo encajan en el panorama general del protocolo RDP.

BlueKeep

BlueKeep (CVE-2019-0708) es una vulnerabilidad RCE en el servidor RDP de Microsoft, que afecta a máquinas Windows desde Windows 2000 hasta Windows 7 y Windows Server 2008 R2. Fue encontrada y parcheada en mayo de 2019. Esta vulnerabilidad es un use-after-free que estaba presente en el controlador del kernel de Windows que maneja las conexiones RDP: termdd.sys.

Esta vulnerabilidad podría ser explotada en la fase de inicialización de la conexión de RDP. Como se mencionó anteriormente, durante el Intercambio de Configuraciones Básicas (Basic Settings Exchange) el cliente y el servidor negocian qué canales virtuales estáticos inicializar para la conexión y hay canales que serán asignados a la conexión independientemente de la solicitud del cliente, incluyendo el canal MS_T120.

termdd.sys crea una tabla que contiene un puntero a una estructura de canal para cada canal creado. Esta tabla contiene hasta 32 (0x20) canales. El Static Virtual Channel MS_T120 se crea por defecto, y siempre está en el índice 0x1F. Esto ocurre incluso antes de que comience la secuencia de conexión.

Para desencadenar esta vulnerabilidad, uno necesita crear un cliente RDP personalizado, que solicitará un canal virtual estático llamado MS_T120 en el Intercambio de Configuraciones Básicas (Basic Settings Exchange). Si se solicita dicho canal, el servidor RDP intentará averiguar si este canal ya ha sido creado para esta conexión. Si es así, devolverá el puntero a la estructura de control del canal existente en lugar de crear uno nuevo. En este punto, tendremos dos punteros apuntando a una estructura de datos y el array de canales de conexión tendrá este aspecto:

Para desencadenar el bug, el cliente RDP debe enviar un paquete que haga que el servidor cierre el canal MS_T120 (comportamiento legítimo y documentado). Después de cerrar el canal, el servidor seguirá adelante y liberará la estructura de control del canal MS_T120, y el puntero a él en el array de canales de conexión, pero sólo el creado debido a la petición del cliente (no el creado automáticamente por el servidor). Ahora tenemos un puntero colgando, y la próxima vez que el servidor intente acceder al canal MS_T120 (lo que ocurre a menudo ya que es un canal crucial para el funcionamiento de RDP), el sistema comprobará el error.

Como esta vulnerabilidad tiene ya bastantes escritos, dejaré algunas referencias para quien esté interesado en conocer todos los detalles técnicos para activarla y explotarla.

Referencias:

• https://www.zerodayinitiative.com/blog/2019/5/27/cve-2019-0708-a-comprehensive-analysis-of-a-remote-desktop-services-vulnerability
• https://unit42.paloaltonetworks.com/exploitation-of-windows-cve-2019-0708-bluekeep-three-ways-to-write-data-into-the-kernel-with-rdp-pdu/
• https://www.malwaretech.com/2019/05/analysis-of-cve-2019-0708-bluekeep.html
• https://www.coresecurity.com/blog/low-level-reversing-bluekeep-vulnerability-cve-2019-0708
• https://blog.tetrane.com/2020/01/22/bluekeep.html

DejaBlue

DejaBlue (CVE-2019-1181 & CVE-2019-1182) es otra vulnerabilidad RCE en el servidor RDP de Microsoft (de ahí su nombre) descubierta en 2019. Esta vez, la vulnerabilidad afectaba a todas las versiones de Windows (7-10) hasta el parche. DejaBlue es una vulnerabilidad de desbordamiento de enteros (integer overflow) que estaba presente en una DLL del núcleo del servidor RDP – RDPCoreTS.dll / RDPBase.dll (dependiendo de la versión de Windows).

La vulnerabilidad reside en la función que descomprime los datos enviados a través de un Dynamic Virtual Channel (DVC). Los datos comprimidos en un DVC se envían en una PDU DYNVC_DATA_FIRST_COMPRESSED / DYNVC_DATA_COMPRESSED. Los datos reales en cualquiera de esos PDUs están en forma de RDP_SEGMENTED_DATA que puede contener múltiples segmentos. Un RDP_SEGMENTED_DATA comprimido contendrá los datos sin comprimir.

Cuando el servidor RDP recibe una PDU DVC comprimida, llamará a una función que la descomprimirá – DecompressUnchopper::Decompress(). La función de descompresión asignará memoria para los datos descomprimidos con un tamaño de uncompressedSize + 0x2000, sin ninguna comprobación del tamaño del resultado. Un atacante puede hacer que este entero de resultado se envuelva y haga que la memoria asignada sea menor que el tamaño de los datos descomprimidos reales. Esto conducirá efectivamente a un desbordamiento de montículo (heap overflow), que puede ser explotado para la ejecución de código.

En el momento de escribir este post, todavía no hay ningún PoC/exploit disponible públicamente. Debido al importante riesgo que esta vulnerabilidad puede suponer para el público, no compartiremos ninguna información adicional en este momento. Para más información, aquí hay algunas referencias públicas para un análisis en profundidad de DejaBlue.

• https://www.malwaretech.com/2019/08/dejablue-analyzing-a-rdp-heap-overflow.html
• https://cyberx-labs.com/blog/analyzing-the-dejablue-heap-overflow-vulnerability/#_Toc28622447
• https://bbs.pediy.com/thread-256766.htm (en Chino)

Asegurando tu RDP

Hay recomendaciones generales a seguir que pueden hacer la tarea de atacar su servidor RDP mucho más difícil para los atacantes. Hay dos acciones sencillas que puedes llevar a cabo:

• Evitar la exposición de tus servidores RDP a Internet, manteniéndolos detrás de tu firewall.
• Habilitar NLA

Esto puede minimizar la superficie de ataque limitando los potenciales atacantes sólo a aquellos que están en tu red y ya han sido autenticados.

Para clientes, es importante cambiar el puerto RDP por defecto.

Conclusión

Este artículo de RDP en una pieza de información digerible y bastante corta, por lo que hay muchas cosas que faltan cubrir. El objetivo fue llevar al lector al punto de tener una comprensión básica del protocolo, así como la capacidad de continuar leyendo e investigando más sobre sus temas específicos de interés.

En el último año, hemos visto 2 vulnerabilidades críticas en este protocolo y con más de 4,5 millones de servidores RDP expuestos a Internet (según shodan.io) y el riesgo de tener un brote impulsado por RDP es muy alto.

Aunque no todos los servidores RDP son servidores Windows, hemos visto vulnerabilidades similares compartidas entre las diferentes implementaciones de un servidor RDP, por lo que Windows no es el único objetivo potencial. DejaBlue, por ejemplo, es muy similar a CVE-2018-8785 – una vulnerabilidad en FreeRDP (popular servidor RDP de código abierto) encontrada por Eyal Itkin aproximadamente un año antes de que se descubriera DejaBlue.

RDP es un protocolo complejo con muchas extensiones. Debido a su complejidad, el potencial de encontrar nuevos bugs críticos sigue siendo alto y tenemos que estar preparados para encontrar y arreglar aquellos antes de que puedan ser abusados en la naturaleza, o tener la capacidad de responder rápidamente y minimizar el daño de posibles vulnerabilidades futuras.