Cisco IOS XE Web UI: cómo revisar el perímetro externo tras CVE-2023-20198 y CVE-2023-20273

Cisco confirmó la explotación de la cadena CVE-2023-20198 y CVE-2023-20273 en el Web UI de los dispositivos con Cisco IOS XE. Aquí hay una condición esencial: lo expuesto no es «cualquier router con IOS XE», sino un dispositivo en el que la función Web UI está activada por HTTP o HTTPS. Ambas vulnerabilidades figuran además en el catálogo CISA Known Exploited Vulnerabilities.

El boletín de Cisco describe una secuencia que ya se ha utilizado en la práctica: CVE-2023-20198 permite que un usuario remoto sin autenticar cree una cuenta local con nivel de privilegio 15, y CVE-2023-20273 permite que un usuario autenticado ejecute comandos con privilegios elevados. Por eso una revisión que empieza un viernes por la tarde conviene abrirla no con la lista de todos los dispositivos IOS XE, sino con dos preguntas: dónde está activado el Web UI y dónde es accesible desde fuera.

Qué estaba accesible antes de que empezara la cadena

La función Web UI se activa con uno de estos comandos:

ip http server
ip http secure-server

El primero corresponde a HTTP y el segundo a HTTPS. Cisco propone buscarlos en la configuración con:

show running-config | include ip http server|ip http secure-server

La presencia de una de estas líneas significa que el servicio web correspondiente está activado. Es una comprobación de configuración, todavía no de accesibilidad externa. El servicio puede estar cerrado por una ACL, por un firewall o simplemente no publicado a través del dispositivo de borde. Y también ocurre lo contrario: un inventario interno puede mostrar una dirección privada del router mientras que, desde fuera, el Web UI resulta accesible mediante una regla de publicación aparte.

Por eso la comprobación externa debe hacerse desde un equipo situado fuera de la propia red. Para un primer barrido del rango de direcciones que pertenece a la organización sirve, por ejemplo:

nmap -Pn -sT -p- --open 203.0.113.0/24

Después hay que comprobar los puertos TCP encontrados como servicios HTTP/HTTPS:

nmap -Pn -sV -p 80,443,8443 203.0.113.10

Los puertos de ese comando no son la lista de puertos de IOS XE, sino un ejemplo para revisar una dirección ya encontrada. No basta con confiar solo en el 80 y el 443: lo que realmente está publicado lo determina la configuración de cada perímetro.

En este punto importa cómo se formula el resultado. Que un servicio web responda en una dirección pública no demuestra por sí solo que haya una versión vulnerable de IOS XE. Y un comando ejecutado en el dispositivo no demuestra que el servicio sea accesible desde internet. Lo que justifica un análisis es la coincidencia de tres señales:

1. un escáner externo ve un servicio HTTP o HTTPS;
2. la dirección se corresponde con un dispositivo Cisco IOS XE;
3. en ese dispositivo el Web UI está activado y hay instalada una versión afectada.

Esa coincidencia es la que convierte un hallazgo del perímetro externo en una tarea concreta para el ingeniero de guardia.

Cómo se desarrolla la cadena

El primer paso es CVE-2023-20198. Según el registro CVE y el boletín de Cisco, la vulnerabilidad está en el Web UI de Cisco IOS XE y se debe al tratamiento incorrecto de elementos de la interfaz. Con el Web UI accesible, un usuario remoto sin autenticar puede crear una cuenta con nivel de privilegio 15.

Para IOS XE eso no es una sesión web intermedia con derechos limitados. La cuenta local creada recibe el nivel de privilegio máximo previsto en el escenario descrito. Tras el primer paso, las solicitudes siguientes ya se realizan como usuario autenticado.

El segundo paso es CVE-2023-20273. Cisco la describe como una vulnerabilidad de inyección de comandos en el componente Web UI: un usuario local autenticado puede enviar una solicitud manipulada y ejecutar comandos con privilegios root. En la actividad confirmada por Cisco, los dos fallos se usaron juntos: la cuenta privilegiada creada mediante CVE-2023-20198 aportaba la autenticación necesaria para aplicar CVE-2023-20273.

En la práctica la cadena se ve así:

Web UI accesible
        ↓
CVE-2023-20198
        ↓
cuenta local con nivel de privilegio 15
        ↓
solicitud autenticada al Web UI
        ↓
CVE-2023-20273
        ↓
ejecución de comandos con privilegios root

Esto explica por qué una simple comprobación de versión no sustituye a la comprobación de lo publicado. La versión responde a una pregunta: si la entrega instalada contiene la corrección. Un escaneo externo responde a otra: si una solicitud puede siquiera llegar al componente donde empieza la cadena.

Qué versiones revisar

La versión de IOS XE se obtiene con:

show version

El resultado debe compararse con la tabla Fixed Software del boletín de Cisco correspondiente a la propia rama de versiones. Entre las entregas corregidas, Cisco indica:

• IOS XE 16.12.10a;
• IOS XE 17.3.8a;
• IOS XE 17.6.6a;
• IOS XE 17.9.4a.

Esta lista no puede usarse como regla general de que «una versión superior está corregida». Cisco mantiene varias ramas de publicación y algunas entregas no tienen imagen corregida propia, sino una vía de migración aparte. Lo que hay que revisar es la fila de la propia rama en la tabla vigente del fabricante, y no comparar únicamente las partes numéricas de la versión.

Ante un dispositivo con el Web UI activado, el orden es: registrar primero el resultado de show version, localizar después su rama en la tabla de Cisco y solo entonces comprobar por separado la accesibilidad externa. Así no se acaba tratando con la misma urgencia una interfaz de gestión cerrada y ese mismo componente publicado en una dirección pública.

Qué buscar en el propio dispositivo

Cisco recoge indicadores relacionados con la escritura de configuración a través del Web UI. La primera consulta rápida:

show logging | include %SYS-5-CONFIG_P

Merece atención especial el mensaje en el que el proceso aparece como:

SEP_webui_wsma_http

La lista de usuarios locales configurados puede consultarse así:

show running-config | include username

Una entrada desconocida, sobre todo con privilege 15, exige análisis. También aquí un nombre no basta: Cisco recomienda investigar los usuarios que no fueron creados por un administrador, en lugar de considerar maliciosa cualquier cuenta local.

El boletín incluye además una comprobación de la presencia del implante mediante un URI del Web UI:

curl -k -X POST "https://DEVICE-IP/webui/logoutconfirm.html?logon_hash=1"

Según la descripción de Cisco, una respuesta con un valor hexadecimal indica la presencia del implante. La ausencia de esa respuesta no anula la revisión de usuarios y registros: los indicadores responden a preguntas distintas y no se sustituyen entre sí.

Si ya se ha encontrado una dirección externa, conviene guardar al menos cuatro resultados en una misma ficha de incidente:

dirección IP pública y puerto accesible
show version
show running-config | include ip http server|ip http secure-server
show logging | include %SYS-5-CONFIG_P

Aparte, la salida de usuarios locales y el resultado de la solicitud a logoutconfirm.html. Un conjunto así evita discutir sobre si «la interfaz parece de Cisco» y permite enlazar el punto de entrada externo con la configuración, la versión y los indicios de cambios.

Dónde ayuda la monitorización del perímetro externo

Un inventario puntual solo responde por el estado en el momento de la comprobación. En este caso, el cambio relevante puede no ser la instalación de una nueva versión de IOS XE, sino la aparición de una nueva vía hacia un Web UI que ya existía: la publicación de una dirección, la modificación de una regla del firewall o la apertura de un puerto TCP.

Por eso el escaneo continuo del perímetro no resulta útil como forma de diagnosticar a partir de un banner. Aporta dos eventos verificables: ha aparecido un servicio web externo o ese servicio ha cambiado. Después hay que contrastar el evento con el propietario de la dirección, el dispositivo, la salida de show version y los comandos ip http server o ip http secure-server.

Ese es el alcance honesto de una capacidad de perímetro externo. No promete identificar un CVE con una sola solicitud de red. Su tarea es más acotada: mostrar que una gestión que ayer no estaba en una dirección pública hoy responde desde fuera. Para esta cadena ese cambio importa, porque el primer paso empieza justamente con una solicitud remota al Web UI.

Dónde se podía romper la cadena

El punto más temprano es no publicar el Web UI en una red no confiable. Cisco recomienda desactivar la función HTTP Server cuando no se necesita:

configure terminal
no ip http server
no ip http secure-server
end

Hay que desactivar las dos variantes si ambos comandos están presentes en la configuración. Tras el cambio, un escaneo externo desde el mismo punto de control debería dejar de recibir respuesta en el servicio que antes era accesible.

Si el Web UI es necesario, limitar el acceso a direcciones de confianza reduce la superficie, pero no sustituye a la corrección de la versión. Aquí no hay contradicción: filtrar el tráfico externo corta el escenario de internet descrito para el resto de orígenes, mientras que el equipo administrativo autorizado sigue siendo una vía aparte hacia el servicio.

El siguiente punto es instalar una entrega corregida de la tabla de Cisco. Corrige las vulnerabilidades, pero no responde a qué ocurrió antes de la actualización. Si el dispositivo estuvo accesible desde fuera con una versión afectada, hacen falta los dos trabajos: la actualización y la revisión de indicadores.

Por último, la cadena podía detectarse después del primer paso: por un usuario desconocido con nivel de privilegio 15 o por el evento SEP_webui_wsma_http. Eso ya no es prevención del acceso inicial, pero sí una oportunidad de no pasar por alto el salto a la segunda vulnerabilidad.

El resultado verificable para el propio entorno, hoy, se ve bastante simple:

• la dirección externa ya no acepta conexiones a un Web UI que no se necesita;
• en el dispositivo no están los dos comandos de servidor, o el acceso está limitado según el esquema acordado;
• show version coincide con la entrega corregida de la propia rama;
• no hay usuarios desconocidos ni, en los registros, los indicadores señalados por Cisco.

La cadena debe romperse en uno de esos puntos.