Arista reveló el 22 de septiembre que los atacantes están aprovechando una nueva vulnerabilidad en VeloCloud Orchestrator (VCO) local, el servidor que gestiona los dispositivos Edge en una red SD-WAN de VeloCloud.
La falla, identificada como CVE-2026-93952, podría permitir que un atacante remoto sin credenciales de acceso escale privilegios en funciones internas y comprometa el host VCO. Solo están expuestos los orquestadores configurados para autenticar sus Edge mediante certificados.
Hasta el 22 de septiembre, hay versiones corregidas para las ramas 5.2 y 6.4, pero aún no para las 6.1 y 7.0. Arista ya ha parcheado las versiones Hosted y Dedicated de VCO. Las versiones afectadas incluyen aquellas que solucionaron otra falla de VCO que Arista reportó como explotada en julio.
Arista asignó a esta vulnerabilidad una puntuación CVSS 3.1 de 10.0. Un ataque exitoso podría comprometer el orquestador y los datos que gestiona. Un VCO comprometido también podría dar a los atacantes acceso a los dispositivos Edge que administra.
Arista afirmó que la falla 'fue descubierta externamente y se sabe que está siendo explotada activamente'. No especificó cuándo comenzaron los ataques ni su alcance. The Hacker News se ha puesto en contacto con Arista para obtener comentarios.
Qué implementaciones están expuestas
Los Edge de VeloCloud pueden autenticarse ante el orquestador en uno de tres modos. En el modo Certificate Deactivated, el Edge utiliza una clave precompartida (PSK). En los modos Certificate Acquire y Certificate Required, utiliza un certificado emitido por el orquestador.
Arista indicó que un orquestador está expuesto si 'se configura autenticación basada en certificados desde el VeloCloud Edge hacia el VeloCloud Orchestrator (VCO)'. No especificó cuál de esos modos cumple esa condición. El atacante también necesita acceso de red a la interfaz web del VCO y la parte pública del certificado de autenticación de un Edge.
La falla de julio no dependía de la configuración: el VCO estaba expuesto por defecto y ninguna configuración podía evitarlo.
Versiones corregidas
A fecha del 22 de septiembre, estas son las versiones afectadas en cada rama, las versiones que las corrigen y las que solucionaron la falla de julio:
Arista dijo que las correcciones para las ramas afectadas que aún son compatibles están en camino y se añadirán a su aviso cuando estén listas. Los clientes en una rama no compatible pueden contactar al Centro de Asistencia Técnica (TAC) de Arista para consultar opciones de actualización.
Si no puedes actualizar todavía
Hasta que se instale una versión corregida, Arista recomienda estas medidas:
- Limitar el acceso a la interfaz web del VCO a redes administrativas de confianza. Esto puede reducir el riesgo de exposición.
- Supervisar el VCO en busca de accesos desde direcciones IP maliciosas conocidas.
- Vigilar el tráfico de red saliente inesperado desde el host VCO.
- Considerar bloquear los puertos salientes que no sean necesarios para la operación normal.
- Monitorizar la presencia de daemons backdoor y webshells.
- Revisar la actividad reciente de los administradores en busca de cambios inesperados.
Indicadores de compromiso
Arista señaló que ningún indicador por sí solo prueba que un VCO haya sido comprometido a través de esta falla. Se deben revisar los registros de acceso web del VCO en busca de solicitudes con rutas similares a URL inusuales, caracteres codificados, referencias a servicios locales o internos, o tasas de solicitudes elevadas.
Los indicadores específicos a buscar son:
- Archivo: /usr/local/sbin/.vcnode.js
- Archivo: /usr/local/sbin/vc-sysmond
- MD5 (vc-sysmond): dc78e206eaeadec59fc5801fe4556bd0
- Archivo: /etc/systemd/system/vc-sysmon.service
- Encabezado HTTP en registros de nginx: x-vc-opt
- IP: 142.93.149[.]77
- IP: 104.248.126[.]159
Si encuentra alguno de estos, preserve el estado del VCO y contacte al TAC o a su equipo de cuenta de Arista. Si sospecha un compromiso, guarde los registros de acceso web, de la aplicación backend, del sistema y de la base de datos del VCO, así como las marcas de tiempo del sistema de archivos, antes de solucionar cualquier cosa, siempre que sea práctico.
Arista también aconseja realizar una respuesta a incidentes después de la actualización. Esto puede incluir la rotación de credenciales, la revisión de la actividad de los administradores, la verificación del estado de los dispositivos Edge gestionados y la restauración o reemplazo del orquestador desde fuentes confiables.
Deja una respuesta