N-able apaga su N-central alojado tras publicarse 33 supuestos zero-days

N-able ha tomado una de las decisiones más drásticas que puede tomar un proveedor de software de gestión remota: apagar su propio servicio. La compañía sacó el lunes 9 de noviembre sus entornos N-central alojados en América, Europa y Asia-Pacífico y pidió a los clientes que ejecutan N-central en sus propios servidores que los desconectaran hasta nuevo aviso. El detonante fue la publicación, esa madrugada, de un repositorio con 33 pruebas de concepto para supuestos zero-days en la plataforma.

N-central es una herramienta de monitorización y gestión remota (RMM) que usan proveedores de servicios gestionados y equipos de TI para administrar los dispositivos de sus clientes. Un servidor N-central comprometido no es un problema aislado: puede ejecutar scripts, instalar software y abrir sesiones remotas en todos los equipos que gestiona. Esa es la razón por la que el aviso de N-able pide desconectar, no solo parchear.

Qué se publicó

El investigador Sean Bales publicó un repositorio llamado Able2Shell con pruebas de concepto para 33 vulnerabilidades. Según el propio repositorio, las pruebas se hicieron contra N-central Appliance 2026.4.0.31, una versión preliminar, y la mayoría —si no todas— deberían afectar también a versiones anteriores. En el momento de la publicación no había identificadores CVE asignados ni una versión corregida.

Los fallos cubren categorías muy distintas: omisión de autenticación, divulgación de credenciales, escritura arbitraria de archivos, salto de directorios, cross-site scripting (XSS), inyección de entidades externas XML (XXE) y ejecución remota de código. La cadena más grave parte de una vulnerabilidad XXE no autenticada en la importación de servicios. Según la documentación del repositorio, permite robar una sesión local de confianza, restablecer la contraseña de una cuenta, ejecutar un JSP con el usuario nable y crear una cuenta de administrador habilitada con credenciales elegidas por el atacante.

Otras cadenas permiten ejecutar comandos como root cuando un administrador abre metadatos de parches manipulados, o escalar desde la cuenta nable hasta root mediante el instalador de syslog y el asistente de preactualización. El repositorio incluye capturas y salidas de las pruebas. N-able no ha confirmado la lista completa ni ha publicado todavía un análisis propio de cada fallo, pero sí ha reconocido que está trabajando en un hotfix, lo que respalda que al menos parte de los problemas son reales.

Qué dice N-able

N-able abrió un incidente crítico en su página de estado a las 15:15 UTC del 9 de noviembre. En su comunicado describió la divulgación como una “comunicación no responsable” de vulnerabilidades críticas y explicó que, como medida de precaución, había desconectado el entorno N-central alojado y había pedido a los clientes con servidores propios que hicieran lo mismo hasta nuevo aviso. La empresa añadió que sus equipos de seguridad, ingeniería y operaciones trabajan en la remediación.

En la actualización de las 19:59 UTC, N-able mantuvo que no había observado explotación activa ni acceso no autorizado a datos, y que seguía desarrollando y validando un hotfix. No dio una fecha de restauración, pero prometió actualizaciones cada cuatro horas o antes si había novedades. Mientras tanto, los servicios de Ecoverse a los que se accede mediante N-able Login —Asset View, Patching, Vulnerability Management, scripting, políticas y etiquetado— siguen operativos, según la compañía. La consola clásica de N-central alojado y sus servicios asociados no están disponibles.

Por qué importa aunque no uses N-central

El alcance de un RMM no se limita al servidor que lo ejecuta. Los agentes de N-central se instalan en los equipos gestionados y suelen tener permisos elevados para instalar parches, ejecutar scripts o abrir sesiones de soporte. Si un atacante controla el servidor, hereda buena parte de esos permisos sobre todos los clientes del proveedor de servicios. Por eso un incidente en una plataforma RMM se convierte en un problema de cadena de suministro: afecta a los MSP y, a través de ellos, a sus clientes.

Hasta ahora no se ha confirmado ningún compromiso. La precaución de N-able es coherente con el riesgo estructural, no con una brecha demostrada. Pero la publicación de pruebas de concepto funcionales reduce el tiempo que un atacante necesita para intentarlo y convierte cualquier servidor expuesto a internet en un objetivo prioritario.

Qué deben hacer los administradores

La instrucción principal es mantener los servidores N-central propios desconectados hasta que N-able publique el hotfix y confirme que se pueden volver a poner en servicio. Si desconectarlos por completo no es viable, al menos hay que bloquear el acceso entrante desde internet en el cortafuegos y limitar la consola a las redes de gestión. No conviene interpretar la ausencia de síntomas como una prueba de que el servidor está limpio: las cadenas descritas pueden limpiar parte de sus rastros.

Antes de cambiar nada, lo prudente es conservar evidencias: una instantánea o imagen del servidor y los registros de cortafuegos, proxy y VPN desde el 8 de noviembre. Después, revisar cuentas de administrador y de técnico creadas o modificadas, tareas programadas y scripts no reconocidos, configuraciones de reenvío de registros y archivos nuevos en el árbol web. Si el servidor estuvo accesible desde internet después del 9 de noviembre, hay que asumir que las credenciales que contiene pueden estar expuestas.

La rotación debe incluir las cuentas de administrador y de técnico de N-central, las credenciales de descubrimiento de activos, los tokens de registro de agentes, las claves de Ecosystem Agent y cualquier contraseña embebida en políticas de Automation Manager. Conviene empezar por las cuentas de dominio que usan los scripts y el descubrimiento. N-able.app puede mantener parte del trabajo crítico mientras N-central está fuera de servicio, pero la monitorización, las alertas y las tareas programadas que dependen del servidor quedan detenidas.

La polémica sobre la divulgación

Bales declaró a BleepingComputer que publicó los fallos sin avisar antes a N-able porque, según su versión, la empresa no había atendido informes anteriores sobre otro producto. Según el investigador, aquellos fallos seguían sin parchear meses después y sus correos de seguimiento no recibieron respuesta. N-able no respondió a esas preguntas cuando el medio se las planteó, y se limitó a repetir su comunicado sobre el incidente.

La disputa es relevante porque explica el tono del aviso de N-able y el contexto de la divulgación, pero no cambia la evaluación técnica. Los fallos publicados afectan a N-central, no al producto anterior al que se refiere Bales, y la empresa tiene ahora la obligación de corregirlos. Para los administradores, la prioridad sigue siendo la misma: desconectar, conservar evidencias y esperar una versión corregida antes de reabrir el servicio.

Qué falta por saber

No hay identificadores CVE, no hay una versión corregida y no hay una fecha de restauración. Tampoco se ha confirmado de forma independiente que las 33 pruebas funcionen en todas las versiones, ni que N-able vaya a corregir cada una con un único hotfix. La empresa sostiene que no ha visto explotación, pero la ventana de exposición empieza en el momento en que el código se hizo público, no en el momento en que se detecta un incidente.

La lección más útil no es específica de N-able. Las plataformas RMM son objetivos de alto valor porque concentran privilegios sobre cientos o miles de equipos. Mantenerlas fuera de internet, segmentar su acceso, revisar quién puede ejecutar scripts y tener un plan para apagarlas sin perder la gestión esencial son medidas que deberían estar escritas antes de que llegue el próximo aviso. Cuando el proveedor pide desconectar, la respuesta correcta es desconectar.