Tu SD-WAN rota la clave cada 24 horas. El implante también

Uno de los componentes del implante que Cisco Talos describió el 28 de octubre de 2026 se llama LittleFilch y hace una sola cosa: engancha la llamada SSL_read dentro del proceso del plano de control de un controlador Catalyst SD-WAN y extrae material de clave del tráfico de control ya descifrado, para una lista predefinida de nodos de borde. Talos evalúa —esa es su palabra, assessed, no confirmado— que esos 32 bytes son material de clave AES-256 de IPsec distribuido por OMP. Lo recoge en el sitio por el que, según la documentación de Cisco, ese material tiene que pasar.

Lo que dice el manual, antes de hablar de ningún atacante

La guía de seguridad de Cisco describe el ciclo de la clave del plano de datos en dos frases. Primero: «Each router generates a new AES key for its data path periodically» —cada router genera periódicamente una clave AES nueva para su camino de datos—. Y después, cuando toca rotar: «the router sends it immediately to the Cisco SD-WAN Controllers using DTLS or TLS. The Cisco SD-WAN Controllers send the key to the peer routers». El router la fabrica y el controlador la reparte.

El diseño tiene su lógica: alguien tiene que distribuir las claves entre decenas o cientos de sedes que no se conocen entre sí de antemano, y ese alguien es el controlador. En la misma página está escrito el precio de esa comodidad. Por construcción, el controlador es el sitio donde la clave de cada sede existe en claro durante un instante.

La otra cifra del manual es la que da título a esto. Por defecto, una clave vale 86.400 segundos: 24 horas. El rango configurable va de 10 segundos a 1.209.600 —catorce días—. Esa rotación se vende, con razón, como higiene criptográfica: si alguien captura una clave, le caduca al día siguiente.

Por qué la rotación deja de ser una defensa

Un implante que vive dentro del proceso que recibe las claves no necesita que la clave dure. Necesita seguir ahí el día siguiente. Y en eso el trabajo de Talos es bastante explícito: la persistencia se monta modificando los guiones de servicio de runit bajo /etc/sv/sshd/ y /etc/sv/aaamgr/, que vuelven a montar /rootfs.rw como ejecutable y lanzan la cadena de inyección en cada arranque.

Puesto así, y esto ya es lectura nuestra y no de Talos: mientras el implante siga dentro, el ciclo de rotación de 24 horas deja de ser una defensa y pasa a ser un calendario de entrega. Cada vez que el fabric rota, vuelve a pasar por el mismo sitio. No hace falta descifrar nada ni romper AES; hace falta estar en la sala cuando se reparten los sobres.

Y las claves solas no valdrían de mucho sin el mapa. Por eso el mismo componente se lleva, junto al material de clave, las IP públicas y los system-IP de los equipos vEdge sacados de los búferes de las sesiones de control. Clave, y a qué túnel corresponde.

Para escribir en /etc/sv hace falta root. CISA metió dos CVE el mismo día

La entrada es CVE-2026-20127, un 10,0 con vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H y CWE-287: fallo de la autenticación de peering en Catalyst SD-WAN Controller (antes vSmart), Manager (antes vManage) y Validator (antes vBond). Cisco es claro en el aviso: «There are no workarounds that address this vulnerability». La descripción del catálogo KEV añade el matiz que lo explica todo: el atacante entra como «an internal, high-privileged, non-root user account» y desde ahí llega a NETCONF, es decir, a manipular la configuración del fabric.

Fíjate en el «non-root». Para escribir en /etc/sv/ y remontar un sistema de ficheros hace falta root, y Talos no cuenta cómo se hizo ese último salto: su informe no nombra ningún segundo CVE. Lo que sí es un hecho verificable es que CISA dio de alta en el catálogo KEV, el mismo día y con el mismo plazo, CVE-2022-20775: publicada el 30 de septiembre de 2022, un 7,8 que permite «execute arbitrary commands as the root user» desde la CLI de la aplicación a un atacante autenticado y local. Que dos altas simultáneas encajen tan bien es, digámoslo así, una hipótesis nuestra y no un hallazgo de nadie.

Entre la publicación de ese 7,8 y el día en que CISA lo declaró explotado pasaron tres años y casi cinco meses. Ayer mismo mirábamos aquí lo que pasa cuando dejas de quinto un 2,7, y el patrón es el de siempre: una puntuación baja manda la línea al final de la cola de parcheo, y el día que aparece arriba es porque alguien le ha encontrado un sitio en una cadena.

Nueve entradas en el KEV este año. Las contamos nosotros

Descargamos el catálogo KEV de CISA el 31 de octubre de 2026 (versión 2026.10.30, 1.766 vulnerabilidades) y filtramos por producto. Cisco SD-WAN acumula nueve entradas añadidas en lo que va de 2026, ocho de ellas con CVE de este mismo año:

Nueve altas entre febrero y septiembre sobre el mismo plano de gestión dicen algo que una sola no dice: el controlador es el objetivo, y lleva siéndolo todo el año. Tiene sentido desde el punto de vista del atacante. Comprometer una sede te da una sede. Comprometer el controlador te da el mapa y la política, y —si la evaluación de Talos acierta— lo que abre los túneles.

La contramedida se publicó ocho meses antes que la prueba

El 25 de febrero de 2026 —el mismo día del aviso de Cisco y de las dos entradas del KEV— CISA emitió la Directiva de Emergencia ED 26-03, «Mitigate Vulnerabilities in Cisco SD-WAN Systems». El inventario de sistemas afectados había que entregarlo antes de las 23:59 ET del día siguiente; las actualizaciones, antes de las 17:00 ET del 27 de febrero. Vincula solo a las agencias federales civiles de Estados Unidos, así que a una empresa de aquí no le obliga a nada. Pero la dirección suplementaria que acompaña a la directiva, con la guía de caza y fortificación, contiene dos frases que valen igual en Manresa que en Maryland:

Lo que esa primera línea significa técnicamente —y esto ya lo decimos nosotros, CISA no lo explica así— es dejar de hacer pasar la clave simétrica por el controlador. Y la segunda es más dura de lo que parece de primeras: para quien encuentre un compromiso de root, la instrucción no es limpiar los controladores que tiene, sino levantar unos nuevos desde imagen del fabricante y mover los extremos. Ambas están fechadas en febrero, cuando nadie había publicado todavía un implante que leyera material de clave dentro del controlador. La respuesta llevaba ocho meses publicada, y gratis, cuando llegó el análisis que explica para qué servía.

Qué cambian de verdad las claves por pares (y qué no)

La diferencia está en qué viaja. En el modo por defecto, lo que el router manda al controlador es la clave. Con claves por pares, la documentación de Cisco lo describe así: «IPSec devices share public values from Diffie-Hellman (DH) algorithm with the controllers. The controllers relay the DH public values to authorized peers of the IPsec device as defined by a centralized policy». Lo que circula por el controlador pasan a ser valores públicos, y la clave de sesión la derivan los dos extremos. Un implante sentado en SSL_read sigue viendo pasar cosas; lo que ve ya no abre el túnel.

Ahora las pegas, que las tiene y conviene decirlas antes de que alguien lo active un viernes:

El correo que le mandaríamos a quien opera tu controlador

En muchos despliegues gestionados el plano de control no está en el inventario del cliente, porque no es suyo. Eso no quita la pregunta, solo cambia a quién se le hace. Copia, pega y pide respuesta por escrito:

Tres acotaciones honestas

Primera, sobre el alcance. Cisco habla de «limited exploitation» y los objetivos que Talos describe son servicios espaciales y por satélite, tecnología de defensa y aeroespacial, e investigación de políticas públicas. Talos añade, con alta confianza, que la infraestructura de este actor se solapa de forma considerable con «Silent Train», la red de acceso encubierto de Volt Typhoon. Si tienes diez sedes y vendes material de oficina, no eres el objetivo de esta gente. Lo que sí hereda todo el mundo, antes o después, son sus técnicas.

Segunda, sobre el fabricante. En septiembre escribimos aquí sobre un 10,0 en el orquestador de otro fabricante, por un problema distinto y con el mismo sitio comprometido. No estamos diciendo que cambies de plataforma, y conviene recordar por qué centralizaste el plano de control: es lo que permite que una red de cien sedes la lleve un equipo pequeño, y eso sigue siendo verdad esta tarde. Moverse de fabricante por una noticia es la forma más cara de no resolver nada, porque lo que concentra el plano de control se concentra igual en el plano de control del siguiente. No vendemos licencias de nadie, así que esta recomendación no nos da de comer.

Tercera, sobre nosotros. No hemos verificado el implante por nuestra cuenta: los nombres de los componentes, los ficheros y el mecanismo de persistencia salen de la publicación de Talos del 28 de octubre, y la atribución del material a AES-256 es una evaluación suya, no un hecho confirmado. Lo que sí hemos hecho es contar el catálogo KEV, poner las fechas en orden y leer el manual.

Dónde está el secreto en tu red

La pregunta vale para cualquier malla cifrada, lleve el nombre que lleve: si en tu red hay un sitio por el que pasa, aunque sea durante un instante, el secreto de todas las demás sedes, ese equipo merece el inventario, el parcheo, la vigilancia de integridad y el plan de reconstrucción que le darías a una caja fuerte. Hoy, en la mayoría de despliegues, lo que tiene es un ticket de actualización trimestral.

Es la misma conversación que tuvimos aquí cuando miramos dos operadores en la factura y un solo núcleo: dos enlaces en la factura no son dos caminos si por debajo comparten un elemento único. Allí el elemento compartido era el núcleo de un operador. Aquí es tu propio controlador, y lo que comparte son las llaves.

Nosotros diseñamos y operamos SD-WAN multi-sede y redes y comunicaciones con red propia —BGP, tránsito, peering—, y en los despliegues que llevamos el plano de control va en el inventario como un servicio de producción más: con dueño, con ventana de actualización y con un número de horas medido para levantarlo de cero. Si no sabes cuál es ese número en tu red, escríbenos y lo medimos, aunque el resultado sea que todo está bien.

Fuentes (consultadas el 31 de octubre de 2026): el análisis del marco KeyDrift, los nombres de sus componentes (PolyFlame/libdssl.so, LittleFilch/libcommon.so, rsshd, conf_sshd, aaamgrd), el gancho sobre SSL_read dentro de vdaemon y la extracción de material de clave para una lista predefinida de nodos de borde —que Talos evalúa («assessed») como material de clave AES-256 de IPsec distribuido por OMP, no como hecho confirmado— junto a las IP públicas y los system-IP de los vEdge, la persistencia mediante los guiones de runit en /etc/sv/sshd/ y /etc/sv/aaamgr/ con remontaje de /rootfs.rw, los sectores objetivo y el solapamiento de infraestructura con la red de acceso encubierto «Silent Train» de Volt Typhoon son del informe de Cisco Talos «Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN», publicado el 28-10-2026. La puntuación 10,0, el vector, el CWE-287, los productos afectados, las versiones corregidas, la frase sobre la ausencia de soluciones alternativas y las fechas de primera publicación (25-02-2026) y última actualización (28-10-2026) son del aviso de Cisco cisco-sa-sdwan-rpa-EHchtZk. El ciclo de la clave del plano de datos, el valor por defecto de 86.400 segundos y el rango de 10 a 1.209.600 son de la guía de configuración de seguridad de Cisco. Las claves por pares, el intercambio de valores públicos Diffie-Hellman a través de los controladores, la validez por defecto de 3.600 segundos, el reinicio necesario y las versiones mínimas (SD-WAN 19.2.1 e IOS XE SD-WAN 16.12.1b) son de las páginas de IPsec Pairwise Keys de la misma documentación. La Directiva de Emergencia ED 26-03 (25-02-2026, actualizada el 11-03-2026) y su dirección suplementaria de caza y fortificación son de CISA; de ahí salen las dos frases citadas y el plazo de las 17:00 ET del 27-02-2026. Las nueve entradas de Cisco SD-WAN en el catálogo KEV, sus fechas y la descripción de la cuenta interna y del acceso a NETCONF las hemos contado nosotros sobre el fichero JSON del catálogo, versión 2026.10.30. Los datos de CVE-2022-20775 (publicada el 30-09-2022, 7,8, ejecución de órdenes como root desde la CLI) son del NVD. Lo nuestro, y conviene separarlo: la lectura del rekey de 24 horas como calendario de entrega mientras el implante persista, la hipótesis de que CVE-2022-20775 sea el segundo peldaño hasta root (Talos no nombra ningún segundo CVE; lo único comprobable es que CISA dio de alta las dos el mismo día), la traducción técnica de la recomendación de CISA sobre claves por pares, el recuento del KEV, la cronología febrero-octubre y el correo al proveedor. Foto de portada: Optical-fiber-distribution-frame-0a, CC BY-SA 3.0, vía Wikimedia Commons.