CVE-2018-0161

Falha de negação de serviço no subsistema SNMP do Cisco IOS em switches Catalyst 2960-L e Catalyst Digital Building (8P/8U): uma consulta SNMP GET pelo OID ciscoFlashMIB trava o processo SNMP ENGINE e reinicia o equipamento. Exige acesso autenticado ao SNMP (community string v2 válida ou credenciais v3), o que reduz a superfície real de exploração, mas está no catálogo KEV da CISA por exploração confirmada em campo.

A causa é um erro de gerenciamento de recursos (CWE-399) no tratamento de requisições SNMP de leitura para o OID ciscoFlashMIB. Quando o dispositivo processa esse GET, o processamento interno consome CPU de forma anômala, disparando o watchdog SYS-3-CPUHOG e levando o dispositivo a reiniciar.

O atacante não controla payload arbitrário nem executa código: ele controla apenas qual OID solicita via SNMP. O gatilho é a simples presença do OID ciscoFlashMIB na requisição GET — não há necessidade de manipular índices, tamanhos de buffer ou strings malformadas. É uma falha de lógica/processamento específica desse MIB, não uma corrupção de memória.

A Cisco confirma que apenas os três modelos citados, rodando releases vulneráveis de IOS clássico (não IOS XE, IOS XR ou NX-OS), são afetados — e somente quando SNMPv2 ou SNMPv3 estão configurados no dispositivo. Dispositivos sem snmp-server community (v2) ou snmp-server user (v3) configurados não são explicáveis por essa via.

O vetor é uma única requisição SNMP GET para o OID ciscoFlashMIB, enviada via UDP à porta SNMP do equipamento. Pré-requisito real: o atacante precisa de uma credencial válida de leitura SNMP — community string em SNMPv2 (frequentemente configurada com privilégios fracos ou default em ambientes de gestão de rede) ou usuário/senha SNMPv3. Isso classifica a exploração como PR:L (privilégio baixo) e não pré-autenticação; a manchete de 'ataque remoto' não deve ser lida como 'sem credenciais'.

A complexidade técnica é baixa: não há necessidade de engenharia de payload, apenas conhecimento do OID alvo e acesso de rede UDP ao SNMP do switch. O UDP também permite spoofing do IP de origem, o que é relevante tanto para o ataque quanto para entender por que ACLs simples baseadas em IP podem ser contornadas.

O resultado bem-sucedido é reinício do dispositivo (impacto de disponibilidade total, sem impacto de confidencialidade ou integridade — refletido no vetor CVSS A:H/C:N/I:N). A CISA adicionou a CVE ao catálogo KEV em março de 2022, com prazo de correção de 17/03/2022, confirmando exploração ativa observada, embora sem detalhar campanha ou ator específico nas fontes disponíveis.

A correção definitiva é atualizar para uma release de Cisco IOS que trate esse OID sem o comportamento de CPU hog, conforme a tabela 'Fixed Software' do advisory oficial da Cisco (cisco-sa-20180328-snmp). As fontes coletadas não detalham os números exatos de versão corrigida por modelo — é necessário consultar essa tabela ou o Cisco Software Checker diretamente antes de planejar upgrade, para não assumir uma versão incorreta.

Se a atualização não for possível de imediato, a Cisco publica dois paliativos: (1) restringir o acesso SNMP via ACL a hosts de gerência confiáveis — mas a própria Cisco alerta que, como SNMP usa UDP, o IP de origem pode ser falsificado, esvaziando parcialmente essa proteção; recomenda-se combinar com Unicast Reverse Path Forwarding (uRPF); (2) excluir explicitamente o ciscoFlashMIB da view SNMP usada pela community (v2) ou pelo grupo/usuário (v3), impedindo que o OID problemático seja consultável mesmo por clientes autorizados.

Desativar SNMP inteiramente nos dispositivos afetados também neutraliza o vetor, mas tem custo operacional se o SNMP for usado para monitoramento de rede — avalie substituir por outro mecanismo de coleta antes de remover.

O indicador de comprometimento documentado pela Cisco é a mensagem de log %SYS-3-CPUHOG: Task is running for (Nms), more than (2000)msecs (0/0), process = SNMP ENGINE no console/syslog do dispositivo, seguida de reinício inesperado. Em nível de rede, requisições SNMP GET direcionadas especificamente ao OID ciscoFlashMIB, vindas de fontes não usuais de monitoramento, são o sinal a procurar em captura de tráfego SNMP (UDP/161); não há assinatura de payload malformado, já que a exploração usa uma requisição SNMP sintaticamente válida.