ScreenConnect CVE-2024-1709: cómo un servidor RMM se convirtió en una vía de entrada remota

Desde el 19 de febrero de 2024, los servidores ConnectWise ScreenConnect autoalojados debían actualizarse al menos a la versión 23.9.8. Ese día ConnectWise divulgó CVE-2024-1709 —una omisión de autenticación en el componente servidor de ScreenConnect en las versiones 23.9.7 y anteriores— y publicó la corrección para instalaciones on-premises. El 22 de febrero, CISA incorporó la vulnerabilidad a su catálogo Known Exploited Vulnerabilities con estado de explotación activa. El registro oficial la califica con 10.0 en CVSS v3.1: explotable por red, sin cuenta y sin interacción del usuario (ConnectWise, boletín de seguridad del 19 de febrero; CVE-2024-1709, registro CISA-CG).

Se trataba de un defecto del servidor de acceso remoto, no de los agentes de ScreenConnect en los equipos finales. Pero fue la función de ese servidor la que definió las consecuencias: tras omitir la autenticación, un atacante podía crear un administrador y luego usar el sistema de extensiones incorporado para ejecutar código .NET como SYSTEM en el propio servidor. La vulnerabilidad no convertía cada agente en un dispositivo comprometido de forma automática, pero sí entregaba el control administrativo de un componente central de RMM (Huntress, análisis técnico).

Paso 0. El servidor era visible desde internet

Antes de cualquier explotación existía una señal observable desde fuera: un servidor ScreenConnect público y su versión. El 19 de febrero, Huntress informó de que una búsqueda en Censys mostraba más de 8.800 servidores accesibles con una versión vulnerable. Esa cifra se refiere a instancias vulnerables visibles en un momento concreto, no a intrusiones confirmadas (Huntress, vulnerabilidad reproducida el 19 de febrero).

El valor práctico de esta observación es limitado, pero real. El descubrimiento externo de un servicio no demuestra que haya habido explotación ni establece qué sistemas están detrás. Lo que sí establece es otra cosa: la organización está publicando un componente de RMM cuya versión hay que verificar y actualizar. Este paso es posible antes de que existan registros del ataque y antes de que se cree una cuenta ajena.

Aquí es donde un servidor de RMM se diferencia de una aplicación web cualquiera en cuanto a lo que significa su toma de control. Las fuentes no confirman un salto automático del servidor a todos los dispositivos gestionados. Sí confirman que las funciones administrativas propias de ScreenConnect están pensadas para la administración remota y para ampliar las capacidades del servidor. Por eso una instancia de RMM accesible desde fuera debe contabilizarse como un activo del perímetro por derecho propio, y no solo como una página web con un formulario de acceso.

Paso 1. Una ruta alternativa evitaba la comprobación de acceso

CVE-2024-1709 está clasificada como CWE-288: omisión de autenticación mediante una ruta o canal alternativo. En la cadena que reprodujo Huntress se añadía un segmento de ruta a la URL de un servidor ya configurado, tras lo cual quedaba accesible la página SetupWizard.aspx. Esa página estaba destinada a la configuración inicial, pero se abría en un servidor en funcionamiento sin la comprobación de autenticación habitual (CVE-2024-1709, descripción y CWE; Huntress, análisis de la omisión).

Esta etapa no requería credenciales válidas. La valoración oficial de CVSS también indica que no se requieren privilegios ni interacción del usuario, con vector de red y baja complejidad de ataque. De ello se deduce que la autenticación multifactor de los administradores legítimos, por sí sola, no rompía la cadena demostrada: el atacante no iniciaba sesión con una cuenta existente, sino que llegaba al asistente de configuración por otra vía.

El límite de esta conclusión es preciso. La CVE permitía omitir la comprobación de acceso al componente servidor. No era un defecto de los agentes de ScreenConnect ni implicaba el robo de contraseñas de los administradores en activo. El boletín de ConnectWise indica de forma explícita que los agentes no se ven afectados directamente; para corregir las dos vulnerabilidades divulgadas no era necesario actualizarlos.

Paso 2. El asistente de configuración creaba un nuevo administrador

Tras abrir SetupWizard.aspx, los investigadores de Huntress pudieron completar el asistente y crear un nuevo usuario administrativo. Según su descripción, en ese proceso se sobrescribía la base de datos local de usuarios anterior (Huntress, análisis técnico).

En este paso cambiaba la naturaleza del riesgo. Antes existía acceso no autenticado a una función de configuración. Después, el atacante disponía de una cuenta administrativa creada con los medios de la propia aplicación. Las acciones posteriores podían parecer el uso de funciones permitidas por parte de un administrador, aunque el derecho a usarlas se hubiera obtenido a través de una vulnerabilidad.

Huntress también señala la modificación de User.xml como uno de los artefactos posibles. Sin embargo, los investigadores advierten por separado de que los cambios en ese archivo también se producen durante la actividad normal. Ese artefacto por sí solo no demuestra que haya habido compromiso; hay que correlacionarlo con el momento, el contexto y otros eventos (Huntress, guía de detección).

Paso 3. Una extensión incorporada ejecutaba código como SYSTEM

Una vez obtenido el acceso administrativo, los investigadores usaron la función Extensions. A través de ella podían cargar una extensión que ejecutaba código .NET como SYSTEM en el servidor. Huntress subraya que este mecanismo de ejecución es una capacidad administrativa legítima de ScreenConnect, no el contenido de CVE-2024-1709 (Huntress, cadena hasta la ejecución de código).

Esta distinción es necesaria para valorar el incidente. La vulnerabilidad rompía un límite de autenticación. La ejecución de código era posible porque el administrador creado mediante la omisión obtenía acceso a una función incorporada muy potente. Dicho de otro modo, el daño no lo definía solo la clase técnica de la CVE, sino los permisos del rol que el defecto permitía crear.

Al mismo tiempo, ConnectWise divulgó CVE-2024-1708, un path traversal con una puntuación de 8.4 en CVSS. Según el análisis de Huntress, explotar ese defecto por separado requería una cuenta administrativa y acceso a Extensions. Para la cadena de ejecución de código que mostraron los investigadores no hacía falta CVE-2024-1708: el acceso administrativo obtenido mediante CVE-2024-1709 ya permitía usar el mecanismo de extensiones incorporado.

Por eso la formulación «el servidor de RMM se convirtió en una vía de entrada remota» solo es aplicable a la toma de control del propio servidor de administración remota. Las fuentes públicas no establecen que todos los servidores accesibles fueran comprometidos, que cada servidor tomado condujera al compromiso de todos los dispositivos conectados, ni que la explotación correspondiera a una única campaña.

Paso 4. La corrección existía, pero actuar sobre ella dependía del modelo de alojamiento

Un investigador independiente comunicó a ConnectWise dos posibles vulnerabilidades el 13 de febrero de 2024. La empresa las confirmó el 14 de febrero y el 19 de febrero publicó el boletín y el paquete de actualización para los clientes on-premises. Las versiones 23.9.7 y anteriores figuran como afectadas; 23.9.8 es la versión corregida mínima (ConnectWise, cronología de la divulgación; registro oficial de la CVE).

Para los entornos en la nube screenconnect.com y hostedrmm.com, ConnectWise declaró que el problema se resolvió sin acción de los partners y que el riesgo quedó mitigado en un plazo de 48 horas. Los servidores autoalojados requerían una actualización inmediata por parte del propietario de la instancia. Más adelante, la empresa facilitó un parche intermedio de la rama 22.4 a los clientes que ya no estaban en mantenimiento.

La conclusión para el control del perímetro no es que el alojamiento en la nube sea siempre más seguro. Las fuentes no establecen eso. La diferencia aquí es operativa: en un entorno gestionado por el fabricante, la corrección la aplicó el fabricante; en una instancia autoalojada, la acción dependía de si la organización conocía el servidor, su propietario y la versión instalada.

Qué debería haber funcionado antes

El primer control es el inventario de activos accesibles desde internet. Si el registro externo se limita a las VPN y los cortafuegos, un ScreenConnect autoalojado puede quedar fuera de ese mismo proceso, aunque siga siendo un servidor accesible públicamente. La observación de Huntress a través de Censys muestra que la existencia y la versión de esas instancias podían determinarse desde fuera ya el 19 de febrero.

El segundo control es la verificación continua de la versión. Un inventario puntual habría establecido que el servidor existe, pero no que su riesgo cambió tras la publicación del boletín. Desde el 19 de febrero, la condición verificable pasó a ser tener la versión 23.9.8 o superior, o la corrección intermedia aplicable. En entornos on-premises, eso exigía una acción del propietario.

El tercer control es la priorización por posibilidad de explotación, y no solo por la cifra de CVSS. En este caso ambas señales coincidieron: CVSS 10.0 y una omisión de autenticación por red sin credenciales. El 22 de febrero apareció una señal confirmada adicional: la inclusión en KEV con estado de explotación activa. En la práctica, el requisito es que un servidor así no permanezca en la cola general de vulnerabilidades web: una omisión exitosa creaba de inmediato un contexto administrativo desde el que estaba disponible la ejecución de código como SYSTEM.

ConnectWise publicó más tarde tres direcciones IP que, según sus datos, usaron los atacantes: 155.133.5.15, 155.133.5.14 y 118.69.65.60. Estos indicadores sirven para revisar registros, pero no sustituyen al control de versión: no están atribuidos a un grupo concreto ni representan la lista completa de orígenes de explotación (ConnectWise, boletín actualizado).

El texto inicial del boletín informaba de que no había evidencias de explotación en ataques reales. Esa valoración corresponde al momento de la publicación inicial. Desde el 22 de febrero es aplicable el estado posterior de CISA: explotación activa. Los materiales públicos no indican qué casos concretos sirvieron de base para la inclusión en KEV.

Dónde se podía romper la cadena

Cada línea siguiente empareja un requisito, con la fecha a partir de la cual se aplica, y la acción que le corresponde.

• Antes de la explotación: contabilizar el servidor de RMM público como activo externo — detectar las instancias de ScreenConnect accesibles desde internet junto con las VPN, los cortafuegos y otros componentes de acceso remoto; registrar el propietario y la versión
• Desde el 19 de febrero de 2024: corregir CVE-2024-1709 y CVE-2024-1708 en ScreenConnect autoalojado — actualizar el servidor a la versión 23.9.8 o superior, o aplicar la corrección proporcionada por el fabricante para la rama soportada
• Desde el 19 de febrero de 2024: separar el servidor vulnerable de la cola general de correcciones — priorizarlo por la explotación por red sin credenciales y por la posibilidad de obtener acceso administrativo
• Desde el 22 de febrero de 2024: tener en cuenta la explotación activa confirmada según CISA KEV — elevar la urgencia de la actualización y revisar los registros del servidor, la creación de administradores, los cambios en User.xml y el uso de Extensions; no considerar un artefacto aislado como prueba por sí misma de una intrusión
• Tras detectar una instancia externa vulnerable: comprobar de forma continua la accesibilidad y la versión hasta confirmar la corrección, ya que detectar un activo una vez no confirma que se haya instalado la corrección
• Al valorar las consecuencias: verificar por separado la toma del servidor y las acciones posteriores; no dar por comprometidos automáticamente los agentes ni todos los dispositivos gestionados