Qué es RDP (protocolo de escritorio remoto) y cómo funciona

RDP (Remote Desktop Protocol, o Protocolo de Escritorio Remoto) es el protocolo de Microsoft que permite usar un equipo Windows a distancia a través de la red: tú ves su pantalla en tu equipo y le envías tu teclado y tu mouse, como si estuvieras sentado frente a él.

Además de ser la herramienta con la que el soporte técnico entra a tu PC, RDP es una de las vías favoritas de los atacantes, que lo usan tanto para entrar en una red como para moverse de un equipo a otro una vez dentro.

RDP es un protocolo complejo, con muchas extensiones, y esa complejidad hace más probable que aparezcan nuevos fallos críticos.

Primero va la explicación sencilla: qué es RDP, para qué se usa, qué son un servidor y un cliente RDP, en qué se diferencia de VNC y cómo se protege la conexión, con una prueba propia de laboratorio que muestra la negociación con tráfico real.

Después, una sección avanzada para quien quiere ver el protocolo por dentro (la pila, la secuencia de conexión y los canales), justo donde vivieron vulnerabilidades como BlueKeep y DejaBlue.

Lo esencial

• RDP es el protocolo de escritorio remoto de Microsoft: el servidor envía la pantalla y el cliente envía teclado y mouse.
• Para recibir conexiones RDP hace falta Windows Pro (o superior); Windows Home solo puede conectarse a otros equipos como cliente.
• El protocolo es multicanal: además de imagen y entrada, transporta portapapeles, audio, impresoras y unidades por canales virtuales separados.
• La seguridad depende de la capa que se negocie: lo habitual hoy es TLS con autenticación previa (NLA), no el cifrado RDP nativo, que no autentica al servidor.
• Su complejidad explica su historial de fallos graves, como BlueKeep (mayo de 2019) y DejaBlue (agosto de 2019).

Qué significa la sigla RDP y cómo la define Microsoft

RDP son las siglas de Remote Desktop Protocol, en español Protocolo de Escritorio Remoto. Microsoft lo define en su documentación oficial como el protocolo que proporciona capacidades de visualización y de entrada remotas, a través de conexiones de red, para aplicaciones basadas en Windows que se ejecutan en un servidor.

Los programas siguen ejecutándose en el equipo remoto, y a ti te llegan solo la imagen y el sonido de lo que pasa allí. Tus archivos no viajan, salvo que actives la redirección de unidades.

En muchos foros y tiendas en español se llama “un RDP” a un servidor Windows que se alquila en la nube para usarlo a distancia. Ese uso viene de que se accede a esos servidores por RDP, pero el término técnico se refiere al protocolo, no al servidor que se renta.

Para qué se usa RDP: Windows, servidores y nube

RDP se usa siempre que alguien necesita trabajar en un equipo Windows que no tiene delante. Los casos más comunes son:

• Escritorio remoto de Windows. La función que trae el propio sistema para conectarse desde casa a la PC de la oficina, o para que un técnico administre un equipo sin desplazarse.
• Administración de servidores. Los administradores de sistemas gestionan servidores Windows por RDP en lugar de conectar monitor y teclado a cada máquina.
• Remote Desktop Services (antes Terminal Services). Un servidor Windows aloja sesiones para muchos usuarios a la vez, que trabajan con escritorios o aplicaciones publicadas desde ese servidor, incluidas las de RemoteApp.
• Máquinas virtuales en Azure y Hyper-V. Las plataformas de virtualización y de nube de Microsoft utilizan RDP como protocolo de conexión remota por defecto para sus máquinas virtuales Windows.

Si lo que buscas es una alternativa libre o multiplataforma, tenemos una guía aparte de software de escritorio remoto de código abierto.

Servidor RDP y cliente RDP: qué es cada uno

Toda conexión RDP tiene dos extremos:

• Servidor RDP (o host): el equipo al que te conectas. Es el que acepta la conexión, ejecuta las aplicaciones y envía su pantalla. En Windows, es el equipo con el Escritorio remoto activado.
• Cliente RDP: el equipo desde el que te conectas. Muestra la pantalla remota y envía tu teclado y tu mouse. En Windows es la aplicación Conexión a Escritorio remoto (mstsc.exe) o la aplicación Windows App, y existen clientes para macOS, Linux, Android e iOS.

En los Windows compatibles no hay que instalar ningún “servidor RDP” aparte: el host forma parte del sistema y basta con activar el Escritorio remoto.

Windows Home no puede ser servidor RDP. Según el soporte oficial de Microsoft, el equipo al que te conectas debe ejecutar una edición Pro de Windows, mientras que el equipo desde el que te conectas puede ejecutar cualquier edición (Pro o Home) o incluso otro sistema operativo. Pueden recibir conexiones las ediciones Pro, Enterprise y Education, además de Windows Server.

Un Windows de escritorio tampoco es un servidor multiusuario. Para que varias personas trabajen a la vez en sesiones propias hace falta Windows Server con el rol de Remote Desktop Services y sus licencias de acceso de cliente (CAL).

En Linux, el servidor RDP libre más usado es xrdp, mientras que FreeRDP es sobre todo una implementación del lado cliente. Con xrdp montamos el servidor de nuestra prueba de laboratorio.

Cómo funciona RDP, explicado de forma simple

Una conexión RDP sigue cuatro pasos:

1. El cliente se conecta al servidor y ambos acuerdan cómo se van a comunicar y cómo van a proteger la conexión.
2. El usuario se autentica con su cuenta del equipo remoto: con NLA (autenticación previa), antes de que se cree la sesión de escritorio remoto; sin NLA, el servidor puede empezar a crearla antes de autenticarlo.
3. El servidor envía la imagen de su escritorio al cliente, y solo vuelve a enviar lo que cambia en pantalla.
4. El cliente envía cada pulsación de tecla y cada movimiento del mouse al servidor, que los aplica como si vinieran de un teclado y un mouse físicos.

El tráfico es muy asimétrico: casi todos los datos van del servidor al cliente (la imagen), y muy pocos en sentido contrario (la entrada).

Lo que hace a RDP más que un “visor de pantalla” es que es multicanal. Además de la imagen y la entrada, la misma conexión transporta canales virtuales separados para otras funciones.

Microsoft indica en su documentación que el protocolo admite, en teoría, hasta 64.000 canales de transmisión de datos. Gracias a esos canales puedes, por ejemplo:

• Copiar y pegar entre tu equipo y el remoto (portapapeles compartido).
• Escuchar en tu equipo el audio del remoto.
• Imprimir en tu impresora local un documento abierto en el equipo remoto.
• Ver tus unidades locales desde la sesión remota.

Cada canal es código que procesa datos llegados por la red, y por tanto un posible punto de fallo.

RDP frente a VNC y frente a herramientas como TeamViewer o RustDesk

RDP no es la única forma de controlar un equipo a distancia. Las diferencias principales son de enfoque:

Para comparar TeamViewer, AnyDesk, RustDesk y el resto programa por programa, tenemos una selección de los mejores programas de escritorio remoto.

Si te interesa una opción libre de este último grupo, revisa nuestra guía de RustDesk, el escritorio remoto de código abierto.

¿Es seguro RDP? Capas de seguridad y NLA

RDP puede ser razonablemente seguro o muy inseguro según cómo esté configurado. Que el protocolo cifre la conexión no lo hace seguro por sí solo: depende de qué capa de seguridad se negocie, de si se autentica al usuario antes de abrir la sesión y de qué canales se dejan activos.

Los canales de redirección son un buen ejemplo. El portapapeles, las unidades, las impresoras y el audio pueden mover datos entre el cliente y el host en los dos sentidos, así que cada uno que queda activado es un camino más por el que puede salir o entrar información.

Las capas de seguridad de RDP

La primera pieza es la capa de seguridad que negocian cliente y servidor al conectarse. La directiva de Windows “Require use of specific security layer for remote (RDP) connections” define tres opciones:

• Negotiate: usa el método más seguro que soporte el cliente. Si el cliente admite TLS, se usa TLS; si no, se recurre al cifrado RDP nativo.
• RDP: cifrado propio del protocolo. No autentica al servidor, así que no protege contra quien se haga pasar por él, y no se recomienda.
• SSL (TLS): exige TLS para autenticar al servidor. Si TLS no está disponible, la conexión falla.

Negotiate es el valor por defecto: la documentación de Microsoft del parámetro SecurityLayer lo describe como el modo en que cliente y servidor negocian el método de autenticación antes de establecer la conexión, y lo marca como valor predeterminado. Con clientes actuales, eso termina en TLS.

Por eso el dato que repiten muchos artículos antiguos, que RDP cifra con RC4 por defecto, ya no es cierto. RC4 corresponde solo a la capa de seguridad RDP nativa, que hoy queda como último recurso: sigue disponible si se fuerza, pero Microsoft la desaconseja.

En la especificación del protocolo, estas opciones se agrupan en dos familias:

• Seguridad RDP estándar: el tráfico se cifra con el algoritmo RC4 de RSA, usando valores aleatorios del cliente y del servidor que se intercambian durante la configuración inicial de la conexión.
• Seguridad RDP mejorada: RDP delega todas las operaciones de seguridad (cifrado y descifrado, comprobaciones de integridad, etc.) en un protocolo de seguridad externo, que puede ser TLS 1.0/1.1/1.2/1.3, CredSSP (TLS + NTLM o Kerberos) o RDSTLS (RDP mejorado con TLS), según la lista de protocolos de seguridad externos de MS-RDPBCGR.

La elección de un protocolo de seguridad mejorado puede hacerse de dos formas.

En la basada en negociación, la petición y la respuesta de conexión iniciales quedan fuera del protocolo de seguridad: después de ese primer intercambio, cliente y servidor eligen el protocolo, hacen su handshake y, a partir de ahí, todas las etapas siguientes de la conexión RDP viajan encapsuladas dentro de él.

El enfoque directo prioriza la seguridad sobre la compatibilidad: el cliente arranca el handshake del protocolo de seguridad externo antes de enviar ningún dato propio de RDP.

La ventaja principal de la seguridad mejorada es que permite la autenticación a nivel de red.

Qué es NLA y por qué importa

NLA (Network Level Authentication, Autenticación a nivel de red) obliga al usuario a autenticarse antes de que el servidor cree la sesión de escritorio remoto. Se apoya en CredSSP, que combina TLS con NTLM o Kerberos. En las versiones modernas de Windows viene activada por defecto al habilitar el Escritorio remoto.

Sin NLA, el servidor empieza a reservar recursos y a mostrar la pantalla de inicio de sesión a cualquiera que se conecte. Con NLA, el servidor solo dedica recursos a usuarios autenticados, y quien no tiene credenciales válidas se queda fuera antes de llegar a esa parte del protocolo.

Eso reduce la superficie expuesta a atacantes no autenticados: si aparece una vulnerabilidad crítica en el protocolo, NLA puede limitar su explotación a quien ya tiene credenciales.

NLA reduce el riesgo, pero no lo elimina.

Lo que vimos en nuestro laboratorio

Para ver la negociación en la práctica, en nuestro laboratorio montamos un servidor RDP con xrdp sobre Ubuntu 24.04 y nos conectamos a él desde Kali Linux.

Primero preguntamos al servidor qué capas de seguridad acepta, con el script rdp-enum-encryption de Nmap:

nmap -p 3389 --script rdp-enum-encryption 10.211.55.5

La respuesta enumera las cinco opciones y todas devuelven SUCCESS: CredSSP (NLA), CredSSP with Early User Auth, Native RDP, RDSTLS y SSL.

En la capa nativa, el servidor declara un nivel de cifrado High y sigue aceptando 128-bit RC4. Es decir, un servidor con la configuración que trae al instalarlo todavía admite la capa antigua si un cliente la pide.

Después nos conectamos con el cliente xfreerdp3 mientras capturábamos el tráfico con Wireshark:

xfreerdp3 /v:10.211.55.5 /u:parallels /cert:ignore

El primer paquete que envía el cliente, la petición de conexión X.224, lleva dentro una RDP Negotiation Request con el campo requestedProtocols: 0x00000003: el cliente ofrece TLS y CredSSP.

La respuesta del servidor, la RDP Negotiation Response, trae selectedProtocol: TLS 1.0, 1.1 or 1.2 (0x00000001). Ese valor identifica TLS como protocolo elegido, sin fijar la versión concreta.

El servidor eligió TLS, no CredSSP, aunque Nmap acababa de confirmar que lo soporta. El canal quedó cifrado, pero sin autenticación previa: en esa conexión no hubo NLA.

La prueba usa xrdp, no Windows, así que no describe cómo se comporta un Windows con su configuración por defecto.

Lo que muestra la prueba es que “RDP cifra la conexión” y “RDP autentica al usuario antes de abrir la sesión” son dos cosas distintas, y que cuál de las dos obtienes depende de lo que negocien cliente y servidor.

Cómo funciona el protocolo RDP por dentro (sección avanzada)

Nivel avanzado. Si solo querías saber qué es RDP, con lo anterior tienes la respuesta. A partir de aquí entramos en la estructura interna del protocolo. Es la base para entender por qué ciertas vulnerabilidades de RDP fueron tan graves. Las estructuras exactas, las constantes y el resto de la información están en la especificación MS-RDPBCGR.

La pila de protocolos

RDP no viaja directamente sobre TCP: se apoya en varios estándares heredados de las telecomunicaciones, apilados uno sobre otro.

• TPKT es el servicio de transporte ISO sobre TCP (ISO Transport Service on top of TCP). Sirve para que los dos extremos intercambien unidades de datos del protocolo de transporte (TPDU o PDU).
• X.224 es un protocolo de transporte orientado a la conexión. RDP lo usa en la petición y la respuesta de conexión iniciales.
• T.125 MCS (Multipoint Communication Service) permite a RDP comunicarse por múltiples canales y gestionarlos.

Sobre esas capas van los datos propios de RDP.

RDP también puede usar UDP para el transporte de datos; aquí describimos la pila sobre TCP, que es la que recorre la secuencia de conexión.

Enviar y recibir datos por esta pila es, en esencia, lo mismo que en el modelo OSI de 7 capas: los datos se fragmentan, se asignan a un canal, se cifran y se encapsulan antes de salir por el cable hacia el otro extremo, que repite el mismo proceso a la inversa.

La implementación de Microsoft oculta toda esa complejidad de la pila, así que los desarrolladores pueden escribir extensiones del protocolo sin tocarla.

La secuencia de conexión

Antes de que veas el escritorio remoto, cliente y servidor recorren varias fases definidas en la secuencia de conexión de MS-RDPBCGR. La lista recoge las fases que explicamos aquí; la especificación contempla además algunos intercambios opcionales:

1. Inicio de la conexión (Connection Initiation)
2. Intercambio de configuración básica (Basic Settings Exchange)
3. Conexión de canales (Channel Connection)
4. Inicio de la seguridad (Security Commencement)
5. Intercambio seguro de configuración (Secure Settings Exchange)
6. Licencias (Licensing)
7. Intercambio de capacidades (Capabilities Exchange)
8. Finalización de la conexión (Connection Finalization)
9. Intercambio de datos (Data Exchange)

Sin NLA, varias de estas fases se procesan antes de que el usuario demuestre quién es. El código que procesa esas fases queda al alcance de quien no tiene credenciales: si contiene una vulnerabilidad explotable, se puede aprovechar sin autenticarse.

Inicio de la conexión. El cliente abre la conexión con una PDU de petición de conexión X.224. Ese paquete contiene una RDP Negotiation Request con algunas banderas de conexión y los protocolos de seguridad que admite el cliente (seguridad RDP estándar o mejorada).

El servidor confirma la conexión con una PDU de confirmación de conexión X.224, que contiene la RDP Negotiation Response: ahí informa al cliente del protocolo de seguridad seleccionado (elegido entre los que el cliente admite), que se usará durante toda la vida de la conexión.

Es el intercambio que capturamos en el laboratorio. A partir de ese punto, los datos siguientes viajan envueltos en una PDU de datos X.224.

Intercambio de configuración básica. Cliente y servidor intercambian sus ajustes básicos mediante una MCS Connect Initial PDU y una MCS Connect Response PDU, respectivamente. Esos ajustes, de ambos lados, 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 cifrado, tamaño de las claves de sesión, un valor aleatorio del servidor (que después se usa para crear las claves de sesión) y el certificado del servidor. Algunos de estos datos solo cuentan cuando se usa la seguridad RDP estándar.
• Datos de red: información sobre los canales virtuales solicitados y asignados, con el número de canales y una matriz de canales virtuales concretos. El cliente pide en su solicitud el tipo exacto de canales, y el servidor devuelve en la respuesta los ID de los canales reales.

Conexión de canales. Con la lista de canales virtuales de la sesión ya establecida, llega la etapa en la que se conecta cada canal. Tiene varias subetapas:

• MCS Erect Domain Request: indica la altura en el dominio MCS. Como RDP no aprovecha las topologías avanzadas de MCS, vale 0.
• MCS Attach User Request: solicita un ID de canal de usuario.
• MCS Attach User Confirm: devuelve el ID del canal de usuario.
• MCS Channel Join Request y Confirm: el cliente empieza a pedir la unión a los canales virtuales por sus ID, primero al canal de usuario (User Channel), luego al canal de E/S (I/O Channel) y después a los canales virtuales negociados en el intercambio de configuración básica. El servidor confirma cada unión correcta.

Desde ese momento, los datos que envía el cliente viajan envueltos en una MCS Send Data Request PDU y los que envía el servidor, en una MCS Send Data Indication PDU. Los datos ya pueden redirigirse a los canales virtuales.

Inicio de la seguridad. El cliente envía una Security Exchange PDU con su valor aleatorio cifrado con la clave pública del servidor. Después, cliente y servidor usan ese valor y el valor aleatorio del servidor, recibido antes en los datos de seguridad del intercambio de configuración básica, para crear las claves de cifrado de la sesión.

Con la seguridad estándar, a partir de aquí el tráfico RDP puede ir cifrado; con la seguridad mejorada, esta etapa no se ejecuta.

Intercambio seguro de configuración. El cliente envía una Client Info PDU cifrada con información sobre los tipos de compresión que admite, el dominio del usuario, el nombre de usuario, la contraseña, el directorio de trabajo, etc.

Licencias. Esta etapa está pensada para que los usuarios autorizados se conecten a un servidor de terminales, es decir, para admitir más de las 2 conexiones simultáneas que Windows Server permite por defecto: según Microsoft, son dos conexiones remotas para administración que no necesitan licencias de acceso de cliente (RDS CAL).

En muchos casos no se configura ningún servidor de licencias; entonces el servidor RDP simplemente envía al cliente una PDU que “aprueba” su licencia, y el límite de 2 conexiones lo sigue poniendo Windows Server, no esa PDU.

La fase de licencias extendida y la comunicación entre el servidor RDP y el servidor de licencias se describen en MS-RDPELE.

Intercambio de capacidades. El servidor envía las capacidades que admite en una Demand Active PDU, con una estructura que reúne muchas capacidades de distintos tipos.

Según Microsoft, hay 28 tipos de conjuntos de capacidades. Los principales son los generales (versión del sistema operativo, compresión general), los de entrada (tipo y características del teclado, soporte de fast-path, etc.), las fuentes, los canales virtuales y los códecs de mapas de bits.

Después, el servidor puede enviar o no una Monitor Layout PDU para describir sus monitores. El cliente responde con una Confirm Active PDU que contiene su propio conjunto de capacidades.

Finalización de la conexión. Cliente y servidor intercambian algunos tipos de PDU para completar el establecimiento de la conexión, no para cerrarla. Las que envía el cliente pueden salir una tras otra sin esperar las respuestas del servidor, siempre que se respete su orden; el servidor envía las suyas, algunas en respuesta a las del cliente:

• Client/Server Synchronize PDU: sincroniza los identificadores de usuario entre cliente y servidor.
• Client/Server Control PDU (Cooperate): cliente y servidor la envían para indicar el control compartido de la sesión.
• Client Control PDU (Request/Granted Control): el cliente solicita el control y el servidor lo concede.
• Persistent Key List PDU (opcional): el cliente envía al servidor una lista de claves, cada una de las cuales identifica un mapa de bits en caché. Así la caché de mapas de bits puede ser persistente, en lugar de durar solo lo que dura la conexión. Guardar mapas de bits en caché reduce el tráfico de red necesario para llevar la salida gráfica del servidor al cliente.
• Font List/Map PDU: debían llevar información sobre las fuentes de la sesión (nombre, ancho medio, firma, etc.), pero Microsoft no parece usarlas. Aun así, cliente y servidor las siguen intercambiando en este punto, sin datos reales; e incluso si llevaran alguno, la documentación de Microsoft indica que hay que ignorarlo.

Intercambio de datos. Con la conexión finalizada, la mayor parte de lo que se envían cliente y servidor son datos de entrada (del cliente al servidor) y datos gráficos (del servidor al cliente). También pueden viajar información de gestión de la conexión y mensajes de los canales virtuales.

Canales estáticos y dinámicos

En RDP, la mayoría de los datos viajan por distintos canales sobre la capa MCS. Hay dos tipos principales: los canales virtuales estáticos (SVC, Static Virtual Channels) y los canales virtuales dinámicos (DVC, Dynamic Virtual Channels).

Los canales virtuales estáticos permiten la comunicación entre distintos componentes del cliente y del servidor por la conexión principal de datos RDP. Según la especificación MS-RDPBCGR, se pueden crear como máximo 31 al establecer la conexión, y cada uno funciona como un flujo de datos independiente.

Son estáticos porque se solicitan y se crean en el intercambio de configuración básica, al inicio de la conexión, y no se pueden añadir otros durante la sesión: lo “estático” se refiere a cómo se establecen, no a que un canal no pueda cerrarse.

Además de los SVC que usan las extensiones, la conexión tiene canales que se establecen por defecto y son imprescindibles para que funcione: el canal de E/S, el canal de mensajes, el canal de usuario y el canal de servidor.

Los SVC de extensión, en cambio, se negocian durante el intercambio de configuración básica y habilitan distintas extensiones del protocolo. 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 cliente y servidor.
• drdynvc: extensión de canales virtuales dinámicos.

Los ID de los SVC de extensión solicitados se entregan durante el intercambio de configuración básica. Aparte, el del canal de usuario llega en la fase de conexión de canales dentro de la Attach User Confirm PDU, y el del canal de servidor tiene un valor fijo de 0x03EA (1002).

Como los estáticos están limitados a 31, RDP también admite canales virtuales dinámicos. Viajan dentro de un SVC concreto, drdynvc, y son dinámicos porque se pueden crear y destruir en cualquier momento de la conexión, una vez inicializada. De ahí sale la cifra de hasta 64.000 canales que da Microsoft.

Los desarrolladores pueden crear extensiones que transporten datos por un DVC. Los usos más comunes son la entrada de audio (del cliente al servidor), la redirección de dispositivos PnP, el renderizado de gráficos, el canal de eco y la redirección de vídeo, entre otros.

Entradas, salidas y compresión

Durante toda la conexión, el cliente envía la entrada y el servidor la salida:

• Datos de entrada: información del mouse y del teclado, además de una sincronización periódica (por ejemplo, el estado de las teclas Bloq Num y Bloq Mayús).
• Datos de salida: los fundamentales son imágenes de mapa de bits de la sesión del usuario en el servidor. El servidor también puede enviar eventos sonoros simples, como un “bip” definido por su frecuencia y duración; no hay que confundirlos con el audio completo, que viaja por el canal rdpsnd.

Estos datos básicos de entrada y salida pueden viajar de dos maneras:

• Slow-path: una PDU normal, con todas las cabeceras de la pila del protocolo RDP.
• Fast-path: como indica su nombre, se creó para reducir tanto la cantidad de datos transmitidos como el procesamiento necesario para tratarlos. Lo consigue recortando o eliminando las cabeceras de ciertos tipos de PDU, como las de entrada de teclado y mouse.

RDP puede además comprimir los datos de salida (tanto por fast-path como por slow-path) y los de los canales virtuales. Cliente y servidor tienen que admitir la compresión en general y el tipo concreto de compresión que se negocie para la conexión.

El cliente anuncia los tipos que admite en la Client Info PDU, durante el intercambio seguro de configuración. Cada PDU con datos comprimidos lleva en su cabecera unos indicadores de compresión, con el tipo de compresión y otros datos.

La superficie de ataque: BlueKeep y DejaBlue

Dos vulnerabilidades de 2019 muestran por qué importa conocer el protocolo por dentro: cada una está en una de las piezas que acabamos de ver. Las dos ya están parcheadas, y aquí no publicamos código ni pasos para explotarlas.

Las dos permitían ejecutar código de forma remota, sin credenciales, y eran «wormables»: capaces de propagarse de un equipo a otro como un gusano, sin que nadie interviniera. Microsoft lo advirtió en sus avisos de seguridad, como el aviso sobre DejaBlue.

BlueKeep (CVE-2019-0708), mayo de 2019

BlueKeep (CVE-2019-0708) es una vulnerabilidad de ejecución remota de código en Remote Desktop Services: un atacante sin autenticar podía explotarla enviando solicitudes diseñadas por RDP. Tiene una puntuación CVSS 3.1 de 9,8 (crítica). Afecta a Windows 7 SP1, Windows Server 2008 SP2 y Windows Server 2008 R2 SP1.

Microsoft la parcheó en el Patch Tuesday del 14 de mayo de 2019 y publicó también parches excepcionales para Windows XP y Windows Server 2003, que ya no tenían soporte. No afecta a Windows 8, Windows Server 2012 ni versiones posteriores.

El fallo es un use-after-free en el controlador del kernel de Windows que gestiona las conexiones RDP, termdd.sys, y se puede explotar durante el establecimiento de la conexión.

Lo que importa para entender el protocolo es dónde está: en la gestión de los canales virtuales estáticos que se negocian en el intercambio de configuración básica, una fase que, sin NLA, se procesa antes de que el usuario se autentique. Por eso un atacante sin credenciales podía alcanzarlo, como detallan los análisis técnicos de Zero Day Initiative y MalwareTech.

DejaBlue (CVE-2019-1181 y CVE-2019-1182), agosto de 2019

DejaBlue (CVE-2019-1181), junto con CVE-2019-1182, es otra vulnerabilidad de ejecución remota de código en el servidor RDP de Microsoft; el nombre alude a su parecido con BlueKeep. Se explota sin autenticación y sin interacción del usuario, y tiene también una puntuación CVSS 3.1 de 9,8 (crítica).

Se publicó el 14 de agosto de 2019, tras el Patch Tuesday del 13 de agosto. A diferencia de BlueKeep, alcanzaba versiones más recientes de Windows: entre otras, Windows 7 SP1, Windows 8.1, todas las versiones de Windows 10 con soporte en ese momento (de la 1607 a la 1903) y Windows Server 2012, 2012 R2, 2016 y 2019.

DejaBlue es un desbordamiento de entero (integer overflow) en una DLL del núcleo del servidor RDP: RDPCoreTS.dll o RDPBase.dll, según la versión de Windows.

La vulnerabilidad está en la función que descomprime los datos enviados por un canal virtual dinámico (DVC).

Igual que BlueKeep, se alcanza a través de un canal virtual, según el análisis técnico que publicó MalwareTech.

Lo que enseñan los dos casos

Cuanto más código del protocolo se ejecuta antes de autenticar al usuario, mayor es la superficie de ataque. BlueKeep estaba en la gestión de canales estáticos durante el establecimiento de la conexión; DejaBlue, en la descompresión de los canales dinámicos.

El problema no es exclusivo de Windows: otras implementaciones de RDP han tenido fallos parecidos.

DejaBlue, por ejemplo, se parece mucho a CVE-2018-8785, una vulnerabilidad en FreeRDP, la implementación libre de RDP usada sobre todo como cliente, que Eyal Itkin encontró aproximadamente un año antes de que se descubriera DejaBlue.

Cómo proteger RDP: no exponerlo y activar NLA

Dos medidas reducen el riesgo: no exponer los servidores RDP a internet, dejándolos detrás del firewall, y habilitar NLA. Así, un fallo como estos queda al alcance solo de quien ya está en tu red y tiene credenciales.

La protección práctica completa (puerto, exposición a internet, configuración) la explicamos en detalle en cómo usar escritorio remoto de forma segura sin abrir puertos.

Preguntas frecuentes sobre el protocolo RDP