BeyondTrust PRA y Remote Support: cómo verificar el riesgo de CVE-2024-12356

CVE-2024-12356 permite que un atacante remoto y sin autenticación inyecte comandos en BeyondTrust Privileged Remote Access y Remote Support. La vulnerabilidad está incluida en el catálogo CISA Known Exploited Vulnerabilities, por lo que la organización que opera estos sistemas necesita identificar las instancias afectadas, comprobar su accesibilidad de red y confirmar que la corrección fue aplicada.

El 19 de diciembre de 2024, CISA agregó CVE-2024-12356 al KEV. El campo requiredAction exige aplicar las medidas indicadas por el proveedor o dejar de usar el producto si esas medidas no están disponibles; la fecha del campo dueDate es el 27 de diciembre de 2024. La inclusión en el catálogo significa que CISA dispone de información sobre explotación conocida de la vulnerabilidad. (CISA KEV, entrada de CVE-2024-12356)

BeyondTrust indica que CVE-2024-12356 afecta a Privileged Remote Access y Remote Support en las versiones 24.3.1 y anteriores. El proveedor corrigió por su cuenta las instancias en la nube. Quienes operan sistemas on-premise deben instalar la corrección BT24-10. Para las versiones 22.1 y posteriores hay un parche disponible; las versiones anteriores requieren primero una actualización a una versión soportada. (BeyondTrust BT24-10, secciones Affected Products, Affected Versions y Remediation)

De esta información no se desprende que todo portal de BeyondTrust esté publicado en internet. El vector de red describe la forma de atacar un sistema alcanzable, mientras que la accesibilidad de una instancia concreta depende de dónde está alojada y de su configuración de red. Por eso la verificación práctica debe unir tres hechos: dónde se encuentra el portal, si se puede llegar a él desde una red externa y qué corrección se aplicó.

Qué permite exactamente CVE-2024-12356

El proveedor define la vulnerabilidad como inyección de comandos sin autenticación. Un atacante remoto puede inyectar comandos que se ejecutan con los privilegios del usuario del sitio. El registro CVE indica un vector de ataque por red, ausencia de privilegios requeridos y ausencia de interacción del usuario. No hace falta una cuenta previa y activa en PRA o Remote Support. (BeyondTrust BT24-10, sección Summary; CVE-2024-12356, sección Metrics)

Para la organización, el caso más importante es el de una instancia on-premise con una versión afectada accesible desde fuera. Esa combinación no puede confirmarse con una sola fuente de datos. La verificación externa muestra si el servicio responde en una dirección pública en el momento de la observación. La versión y el estado de BT24-10 se establecen a partir de los datos de administración de la propia instancia.

Esa diferencia influye en el resultado de la verificación. Que un portal responda en una dirección pública todavía no significa que se trate de una versión afectada sin parche. Al mismo tiempo, la falta de respuesta desde un único punto externo no elimina la necesidad de comprobar la versión de una instancia local registrada: el sistema puede estar accesible en otra dirección, solo desde determinadas redes o exclusivamente desde el segmento interno.

Qué dicen las fuentes primarias

El boletín BeyondTrust BT24-10 define los productos y versiones afectados y separa el procedimiento para las instalaciones en la nube y las locales. De ahí provienen el límite de las versiones 24.3.1 y anteriores, la existencia de un parche para las ramas 22.1 y posteriores, y la necesidad de actualizar antes las versiones más antiguas. (BeyondTrust BT24-10)

El registro CVE formaliza las propiedades del defecto: ataque por red, ausencia de privilegios requeridos y de interacción del usuario, y la posibilidad de ejecutar los comandos inyectados. Describe la vulnerabilidad, pero no sustituye el procedimiento de actualización del proveedor. (CVE-2024-12356)

La entrada de CISA KEV informa sobre explotación conocida y fija la acción requerida y su plazo. No contiene información sobre la topología de una organización concreta, las versiones instaladas ni la accesibilidad de sus portales. (CISA KEV, entrada de CVE-2024-12356)

Así, las fuentes primarias permiten determinar el alcance técnico de la vulnerabilidad y las medidas previstas. La lista de instancias concretas y su accesibilidad externa se establecen ya con los datos de la organización.

La nube y el on-premise requieren confirmaciones distintas

Para las instancias en la nube, el boletín informa de que la corrección la aplicó BeyondTrust. Para los sistemas locales, la acción recae en quien los opera: instalar el parche BT24-10 si la versión en uso es 22.1 o posterior, o actualizar primero una versión anterior a una versión soportada y aplicar después la corrección. (BeyondTrust BT24-10, sección Remediation)

Por eso el registro «BeyondTrust Remote Support está presente» no basta para elegir una acción. En el inventario, cada instancia necesita como mínimo:

• producto: Privileged Remote Access o Remote Support;
• modelo de alojamiento: BeyondTrust Cloud u on-premise;
• nombre de dominio o dirección pública, si el servicio está publicado;
• versión de la instancia local;
• estado de la corrección BT24-10;
• responsable del sistema.

Si se desconoce el modelo de alojamiento, el aviso del proveedor sobre las instancias en la nube ya corregidas no se puede trasladar al portal encontrado. Primero hay que determinar si pertenece a BeyondTrust Cloud o a un despliegue self-hosted de la organización.

La versión determina no solo si la instancia entra en el alcance del boletín, sino también la secuencia de trabajo. A un sistema on-premise 24.3.1 en una rama soportada se le aplica el parche BT24-10. Para una instancia por debajo de 22.1 no basta con asignar una tarea de ese parche: el boletín exige pasar antes a una versión soportada.

Ramas de trabajo según modelo de alojamiento y versión

• BeyondTrust Cloud — confirmar que el portal pertenece al alojamiento en la nube de BeyondTrust.
• On-premise 22.1–24.3.1 — confirmar la instalación de BT24-10.
• On-premise por debajo de 22.1 — confirmar la actualización a una versión soportada y la posterior instalación de BT24-10.
• On-premise posterior a 24.3.1 — confirmar la versión exacta y su posición respecto al rango de versiones afectadas.
• Modelo de alojamiento o versión desconocidos — identificar la instancia antes de asignarle cualquier estado.

Esta separación impide cerrar una versión local antigua solo con una tarea de instalación del parche y evita dar por corregido de forma automática un portal que únicamente se parece por fuera a un servicio en la nube.

Cómo establecer la accesibilidad externa

La verificación empieza por la lista de despliegues conocidos de PRA y Remote Support. Para cada uno se registran los nombres de dominio y las direcciones públicas declarados, el modelo de alojamiento, el responsable, la versión y el estado de BT24-10.

Después se comprueba la accesibilidad desde una red externa. El resultado práctico debe vincular la observación a un punto y a un momento concretos:

• qué nombre de dominio se verificó;
• a qué dirección IP se resolvió;
• si se estableció la conexión de red;
• si se recibió una respuesta de la capa de aplicación;
• cuándo y desde dónde se realizó la verificación.

Si se estableció la conexión y el servicio respondió, la dirección forma parte del perímetro externo observado. Si no hubo respuesta, el resultado correcto se formula como ausencia de accesibilidad confirmada desde el punto elegido en el momento indicado.

No es obligatorio limitarse a los nombres conocidos si el alcance aprobado del análisis abarca los dominios y direcciones públicas que pertenecen a la organización. Así puede aparecer un portal en funcionamiento que no figura en el inventario inicial. El servicio encontrado se coteja después con su responsable y con el registro del activo.

Cuatro resultados de trabajo posibles

• En el inventario, accesible desde fuera — activo conocido confirmado en el perímetro externo.
• En el inventario, no accesible desde fuera — el activo está registrado, pero no se confirmó una ruta externa en el momento de la verificación.
• Fuera del inventario, accesible desde fuera — se encontró un servicio externo sin registro asociado.
• Fuera del inventario, no accesible desde fuera — en la muestra verificada no hay ni registro ni respuesta externa.

Tras esta clasificación, los siguientes pasos se definen por el modelo de alojamiento, la versión local y el estado de BT24-10. Son precisamente esos datos los que separan un portal simplemente publicado de una instancia on-premise afectada y sin corrección confirmada.

Cuatro situaciones en lugar de una lista de control abstracta

Supongamos que la verificación externa encuentra el portal support.example.com. Responde en la dirección publicada y el responsable confirma que es una instancia de BeyondTrust Cloud. En el registro de trabajo quedan ambos hechos: el portal es accesible desde fuera y corresponde al modelo en la nube. Para la corrección se aplica el aviso de BeyondTrust sobre el trabajo que realizó el proveedor. No hace falta asignar al responsable de ese portal una instalación local de BT24-10.

Un segundo portal, remote.example.com, también responde desde la red externa, pero está alojado en el centro de datos de la organización. El sistema informa de la versión 24.3.1 y no hay confirmación de BT24-10. Se trata de una instancia on-premise afectada, para la que se requiere la instalación del parche. La observación externa registra la publicación y los datos del sistema confirman que el boletín es aplicable.

El tercer caso es un PRA local de versión 21.x accesible solo desde la red interna. El orden de la corrección lo determina la versión: primero el paso a una versión soportada y después la aplicación de BT24-10. La ausencia de publicación externa confirmada cambia la caracterización de la accesibilidad de red, pero no excluye al sistema del alcance del boletín de BeyondTrust.

La cuarta variante es un portal encontrado en una dirección pública de la organización que no figura en la CMDB. Mientras el activo no esté identificado, no se le puede asignar modelo de alojamiento, versión ni estado de BT24-10. La primera acción es establecer el responsable y la relación entre la dirección y un despliegue real. Si tras la identificación el portal resulta ser una instancia local de versión 24.3.1 o anterior, se elige para él la rama correspondiente de BT24-10.

Los registros que producen estas situaciones

• Portal BeyondTrust Cloud accesible — accesibilidad externa confirmada; modelo en la nube establecido; corrección realizada por el proveedor.
• On-premise 24.3.1 accesible y sin BT24-10 — instancia afectada y publicada; se requiere el parche.
• On-premise interno por debajo de 22.1 — instancia afectada; se requieren la actualización y el parche.
• Portal externo sin responsable ni modelo de alojamiento — se requiere identificación; el estado de la corrección no está determinado.
• Portal registrado sin respuesta desde fuera — accesibilidad externa no confirmada; la versión y la corrección se comprueban con los datos del activo.

Los ejemplos muestran por qué una misma interfaz externa no lleva a la misma decisión. Para un portal en la nube, la confirmación clave es el modelo de alojamiento; para un nodo local, la versión y BT24-10; para una dirección desconocida, ante todo su pertenencia a un activo concreto.

Qué instancias revisar primero

La máxima prioridad corresponde a una instancia on-premise cuando se confirman a la vez tres circunstancias:

1. la versión instalada es 24.3.1 o anterior;
2. el servicio es accesible desde una red externa;
3. la aplicación de BT24-10 no está confirmada.

La información sobre explotación conocida ya consta en la entrada de KEV. Una vez detectada esta combinación, corresponde elegir la rama de corrección prevista por BeyondTrust y registrar su ejecución.

A continuación se revisan las instancias locales con versiones afectadas cuya accesibilidad externa no está confirmada. También entran en el alcance de BT24-10 y requieren corrección. La diferencia con los sistemas publicados está en la ruta externa comprobada, no en la aplicabilidad del boletín.

En una cola aparte quedan los portales detectados desde fuera con responsable o modelo de alojamiento desconocidos. No se pueden asignar correctamente ni a BeyondTrust Cloud ya corregido ni a un sistema local mientras no se complete la identificación. Sin ella siguen siendo desconocidos tanto el estado de la corrección como el orden de las acciones necesarias.

Restringir la publicación e instalar el parche dan resultados distintos. Lo primero cambia la accesibilidad de red del servicio; lo segundo ejecuta la medida prevista para el software afectado. Si en un portal local cambian tanto la publicación como el estado de la corrección, ambos resultados se registran en la ficha del activo.

Cómo interpretar el plazo de CISA

La entrada de KEV fija el 19 de diciembre de 2024 como fecha de incorporación y el 27 de diciembre de 2024 como plazo para la acción requerida. La acción requerida consiste en aplicar las medidas del proveedor o dejar de usar el producto si esas medidas no están disponibles. (CISA KEV, campos dateAdded, requiredAction y dueDate)

De estos campos no se deduce que la fecha sea automáticamente obligatoria para cualquier organización. La aplicabilidad del plazo la determinan el régimen vigente para ella, los requisitos contractuales o una norma interna; esos documentos no forman parte de las fuentes analizadas aquí.

Por eso, en el resultado de trabajo se indican por separado la decisión sobre la acción requerida por KEV y el plazo adoptado para cada responsable del sistema. Esto no cambia el alcance técnico de BT24-10, pero sí define el orden de ejecución y de escalado dentro de la organización.

Si el plazo de KEV es obligatorio para la organización, el registro debe permitir ver no solo la existencia de una tarea general por el CVE, sino también el estado de cada instancia en la fecha establecida. Un portal en la nube ya cerrado no debe ocultar un nodo local sin parche, ni una instancia on-premise corregida debe ocultar un servicio no identificado en una dirección pública.

Qué debe confirmar el cierre de los trabajos

Para un portal en la nube, la confirmación de cierre es la pertenencia establecida a BeyondTrust Cloud, junto con el aviso del proveedor sobre la corrección realizada.

Para una instancia on-premise de versión 22.1 o posterior se requiere la confirmación de la instalación de BT24-10. Para una versión por debajo de 22.1 hacen falta datos sobre el paso a una versión soportada y sobre la posterior aplicación del parche. Si el servicio era accesible desde fuera y su publicación cambió, el resultado de la verificación externa posterior al cambio se registra por separado.

El registro final de cada instancia debe contener:

• producto y responsable;
• modelo de alojamiento;
• versión instalada;
• estado de BT24-10;
• nombre de dominio o dirección pública;
• resultado de la verificación externa, con su fecha;
• decisión sobre la acción requerida por KEV;
• plazo aplicable a la organización.

Para un portal encontrado pero aún no identificado, una suposición sobre su naturaleza local o en la nube no puede considerarse el cierre de la etapa de descubrimiento. Hace falta la relación con un responsable y con un despliegue. Después de eso, el portal pasa por la misma bifurcación: BeyondTrust Cloud, u on-premise con verificación de versión y de BT24-10.

Para una instancia local no basta una marca general de «actualización realizada» si no permite entender si se aplicó la secuencia de acciones necesaria. En el caso de una versión por debajo de 22.1, el registro debe mostrar tanto el paso a una rama soportada como el parche posterior.

Resultado de la verificación: una decisión concreta para cada instancia

La verificación termina asignando a cada instancia de PRA o Remote Support uno de los estados definidos:

• BeyondTrust Cloud, modelo confirmado — se aplica la rama del boletín sobre la corrección de las instancias en la nube;
• on-premise, versión afectada, BT24-10 confirmado — la medida del proveedor está ejecutada;
• on-premise, versión afectada, BT24-10 no confirmado — se requiere la corrección conforme a BT24-10;
• on-premise por debajo de 22.1 — se requieren la actualización a una versión soportada y el parche posterior;
• portal externo no identificado — hay que establecer el responsable y el modelo de alojamiento;
• versión o estado de la corrección desconocidos — la verificación no está terminada;
• accesibilidad externa no confirmada — el resultado corresponde al punto y al momento verificados, y el estado de la versión local se analiza por separado.

En la lista final se consideran instancias accesibles desde internet aquellos portales para los que se registró una respuesta externa con indicación del nombre o la dirección, la hora y el punto de verificación. Pero la acción por el CVE no se asigna por ese solo hecho: para cada portal encontrado se establecen el modelo de alojamiento, la versión y el estado de BT24-10.

Si desde fuera responde una instancia on-premise de versión 24.3.1 o anterior y no hay confirmación de BT24-10, la acción resultante es inequívoca: asignar un responsable, aplicar la corrección prevista por BeyondTrust y conservar la evidencia de su ejecución. Si responde BeyondTrust Cloud, en el registro se confirma el modelo en la nube. Si responde un portal desconocido, la primera acción es identificarlo.

Una lista así —con los nombres de los portales concretos y una decisión separada para cada uno— es lo que cierra la verificación. Muestra qué instancias de PRA y Remote Support se observan realmente desde la red externa, cuáles de ellas corresponden a versiones locales afectadas y dónde la corrección todavía no está confirmada.