Cisco Catalyst SD-WAN Controller Authentication Bypass Vulnerability

Falha de bypass de autenticação (CWE-287) no mecanismo de peering entre componentes de controle do Cisco Catalyst SD-WAN — Controller (ex-vSmart), Manager (ex-vManage) e Validator (ex-vBond) — que permite a um atacante remoto não autenticado logar como usuário interno privilegiado (não-root) e, a partir daí, acessar NETCONF para reconfigurar toda a fabric SD-WAN. CVSS 10.0 é justificado: sem pré-condição de autenticação, sem interação do usuário, impacto total em confidencialidade/integridade/disponibilidade e mudança de escopo (S:C). Está no catálogo KEV da CISA com exploração confirmada e a CISA chegou a emitir uma Emergency Directive (ED 26-03) com prazo de correção de apenas dois dias — tratamento de incidente ativo, não de risco teórico.

O SD-WAN da Cisco usa um protocolo de controle entre os componentes de gerência (Manager), controladores (Controller/vSmart) e o Validator (vBond) para estabelecer 'control connections' autenticadas — o chamado peering. Essa autenticação de peering é o que garante que apenas dispositivos legítimos da fabric consigam trocar informações de roteamento overlay e configuração. A falha está em como esse mecanismo valida a identidade do peer: ele 'não está funcionando corretamente', nas palavras do próprio fornecedor, o que caracteriza um CWE-287 (Improper Authentication) genérico — a Cisco não detalhou publicamente se é falha criptográfica, lógica de validação de certificado ou de sessão.

O atacante controla o conteúdo de requisições de peering enviadas ao componente exposto. Explorando a falha, ele consegue autenticar-se como se fosse um peer legítimo e obter uma sessão como usuário interno de alto privilégio, mas não-root, dentro do Controller/Manager. Esse usuário interno tem acesso a NETCONF, a interface de gerência de configuração de rede do SD-WAN — e é por aí que o atacante ganha capacidade de alterar políticas, rotas e configuração de todo o fabric, não apenas do dispositivo comprometido.

Um indicador técnico relevante citado pelo próprio advisory: o login resultante aparece nos logs de autenticação SSH como 'Accepted publickey for vmanage-admin', sugerindo que a conta interna abusada é essa conta de serviço padrão usada para comunicação entre componentes — não uma conta administrativa criada pelo cliente, o que explica por que ela passa despercebida em auditorias manuais.

A vulnerabilidade afeta os três componentes independente de configuração do dispositivo ('regardless of device configuration'), tanto em implantações on-premises quanto nas variantes hospedadas pela Cisco (Cisco Hosted SD-WAN Cloud, inclusive a gestão pela própria Cisco e o ambiente FedRAMP).

O vetor é de rede: o atacante envia requisições de peering forjadas diretamente às portas de controle expostas dos componentes SD-WAN. Não é necessária nenhuma credencial, interação de usuário ou condição de configuração específica — a complexidade de ataque é baixa (AC:L) e o escopo de exposição é qualquer sistema com as portas de peering acessíveis pela rede, inclusive pela internet pública. O próprio advisório afirma isso sem rodeios: 'Cisco Catalyst SD-WAN Controller systems that are exposed to the internet and that have ports exposed to the internet are at risk of exposure to compromise'.

O resultado final da exploração é uma sessão autenticada como usuário interno de alto privilégio (não-root) com acesso a NETCONF — suficiente para reescrever a configuração de rede de toda a fabric SD-WAN gerenciada por aquele Controller/Manager. Isso é, na prática, controle administrativo efetivo sobre o overlay de rede da organização, mesmo sem uma conta root tradicional.

Existe exploração ativa confirmada (presença no KEV da CISA), módulo Metasploit público e PoC pública circulando — o que reduz drasticamente a barreira técnica para exploração em massa contra qualquer instância exposta. A CISA tratou o caso como emergência: prazo de mitigação de dois dias corridos a partir da publicação, através da Emergency Directive 26-03, algo reservado a cenários de exploração ativa contra infraestrutura crítica.

O fornecedor afirma explicitamente que não há workaround que corrija a falha ('No workarounds available' / 'There are no workarounds that address this vulnerability') — a única correção real é a atualização de software. O advisory referencia uma seção 'Fixed Software' com as versões corrigidas por trem de release, mas o conteúdo dessa tabela não estava disponível no material consultado para esta página; é necessário verificar diretamente no advisory oficial (link nas fontes) qual é a primeira versão corrigida para o trem de release em uso antes de planejar a atualização.

Como mitigação temporária enquanto a atualização não é aplicada, a Cisco menciona orientação de mitigação de impacto (não de correção), mas o texto dessa orientação também não foi capturado integralmente nas fontes disponíveis — consultar a seção de Workarounds/Mitigation completa do advisory. Adicionalmente, a CISA publicou diretrizes específicas de contenção e caça a ameaças (Hunt & Hardening Guidance) associadas à ED 26-03, que devem ser seguidas por quem não pode corrigir imediatamente.

O que não funciona: reduzir exposição da interface web de administração isoladamente não neutraliza a falha, já que o problema está na autenticação de peering entre componentes de controle, não na interface administrativa comum. Restringir por firewall o acesso às portas de peering apenas a IPs de componentes legítimos da própria fabric reduz a superfície de ataque, mas não é workaround reconhecido pelo fornecedor — é controle compensatório de rede, não correção da falha.

O advisório fornece dois sinais concretos. Primeiro, no auth.log (/var/log/auth.log) dos componentes de controle, procurar entradas 'Accepted publickey for vmanage-admin from [IP]' — e cruzar esse IP com os System IPs configurados na aba WebUI > Devices > System IP do Manager; login de vmanage-admin vindo de IP fora dessa lista é indício forte de comprometimento. Segundo, nos logs de VDAEMON (mensagem NTCE-1000001, 'control-connection-state-change'), revisar todo evento de peering do tipo 'vmanage' — validando timestamp contra janelas de manutenção conhecidas, IP público contra inventário de infraestrutura autorizada, peer-system-ip contra a topologia documentada e peer-type contra os papéis esperados de dispositivo no ambiente.

Não há assinatura de rede única e confiável descrita pelo fornecedor para detectar as requisições de exploração em trânsito — a validação recomendada é essencialmente forense/manual sobre logs de peering e autenticação já gerados pelo próprio dispositivo, não uma assinatura de IDS/WAF pronta.