CVE-2017-12235

Falha de negação de serviço no parsing do protocolo PROFINET Discovery and Configuration Protocol (PN-DCP) em Cisco IOS, que afeta switches Cisco Industrial Ethernet (IE) configurados para processar mensagens PROFINET. Um atacante não autenticado com acesso à camada 2 do switch pode forçar o reload do dispositivo enviando um pacote PN-DCP Identify Request malformado seguido de pacotes normais. Importa porque, a partir do IOS 12.2(52)SE, o PROFINET vem habilitado por padrão em todas as portas Ethernet base e de expansão dos switches IE — muita gente está exposta sem saber que o recurso está ativo.

A causa é CWE-20 (validação de entrada inadequada) na rotina que faz o parsing de pacotes PN-DCP Identify Request recebidos na interface. PN-DCP é um protocolo de camada 2 (Ethertype 0x8892, sem IP, sem porta TCP/UDP) usado para descoberta e configuração de dispositivos em redes de automação industrial baseadas em PROFINET.

O atacante controla o conteúdo do quadro PN-DCP Identify Request enviado ao switch. Um primeiro pacote malformado explora a falha de parsing; pacotes subsequentes 'normais' do mesmo tipo continuam alimentando o estado corrompido até o processo responsável falhar e o dispositivo recarregar (reload), gerando um core dump.

A vulnerabilidade só se manifesta em dispositivos com o recurso PROFINET habilitado e processando esses quadros na interface de entrada — não é uma falha genérica de todo IOS, é específica da pilha de processamento PN-DCP embutida no software dos switches industriais Cisco.

Cisco confirmou que IOS XE, IOS XR e NX-OS não são afetados; a falha está isolada ao IOS clássico usado nos switches Industrial Ethernet.

O vetor é um quadro PN-DCP Identify Request especialmente formado, enviado à porta Ethernet do switch afetado, seguido do envio continuado de requisições PN-DCP legítimas. Como PN-DCP opera em camada 2, o pré-requisito real de exploração é adjacência de rede (mesmo segmento Ethernet/VLAN) ao dispositivo vulnerável — não é um ataque roteável pela internet, ao contrário do que o vetor CVSS AV:N pode sugerir a quem não conhece o protocolo. Não é exigida autenticação alguma no protocolo PN-DCP.

A pré-condição decisiva é o recurso PROFINET estar habilitado e processando tráfego na interface — em Cisco IOS Software a partir do release 12.2(52)SE isso é o padrão de fábrica nas portas base e de expansão dos switches Industrial Ethernet, então ambientes que nunca tocaram nessa configuração provavelmente estão expostos sem saber.

O resultado de uma exploração bem-sucedida é reload do dispositivo com geração de core file — impacto de disponibilidade (A:H), sem impacto documentado em confidencialidade ou integridade. A CVE está no catálogo KEV da CISA (adicionada em 2022-03-03, prazo de remediação 2022-03-24), o que indica exploração confirmada em algum momento, embora a CISA não detalhe campanha específica nem classifique como usada em ransomware ('Unknown').

O advisory da Cisco é explícito: não há workaround para esta vulnerabilidade. A correção definitiva é atualizar para uma versão de IOS corrigida — as versões fixas variam por trem de release (12.x/15.x) e devem ser confirmadas na seção 'Fixed Software' do advisory oficial ou via Cisco Software Checker, pois o conteúdo lido não trouxe a lista completa de versões corrigidas por trem.

Um controle compensatório real, embora não endossado formalmente pela Cisco como 'workaround' no advisory, é desabilitar o processamento PROFINET em dispositivos que não usam automação industrial: verificar com show running-config | include profinet e show profinet status, e configurar no profinet quando o recurso não for necessário. Isso remove a superfície de ataque por completo, ao custo de perder a funcionalidade PN-DCP caso ela seja de fato usada na rede.

Segmentação de rede que impeça acesso de camada 2 não confiável às portas do switch reduz a exposição, mas não elimina o risco de um insider ou de um dispositivo comprometido na mesma VLAN. Não existe mitigação via ACL de camada 3/4 ou firewall perimetral eficaz aqui, porque o ataque ocorre inteiramente em camada 2 dentro do mesmo segmento Ethernet.

A exploração bem-sucedida provoca reload do dispositivo com geração de um core file; a Cisco recomenda contatar o TAC para analisar o core dump e confirmar se o reload foi causado por esta falha. Não há assinatura de tráfego documentada pelo fornecedor além de 'pacotes PN-DCP Identify Request' — monitorar quadros PN-DCP (Ethertype 0x8892, especificamente Identify Request) chegando de origens inesperadas nas portas de switches Industrial Ethernet é o sinal prático a procurar, mas não há indicador de comprometimento confiável publicado além do próprio crash/reload do dispositivo.