CVE-2004-1464

Falha de negação de serviço em roteadores e switches Cisco rodando IOS 12.2(15) e versões anteriores: uma conexão TCP malformada enviada às portas de Telnet ou Reverse Telnet faz o dispositivo parar de aceitar novas conexões de gerência (Telnet, SSH, SCP, RSH e, em certos casos, HTTP). Não há execução de código nem impacto em confidencialidade ou integridade — o dano é isolar o acesso remoto de administração a um equipamento de rede, o que em infraestrutura crítica já é grave por si só. Está no catálogo KEV da CISA (adicionado em 2023, referente a exploração histórica), mas o CVSS 3.1 recalculado (5.9, AC:H) reflete que a exploração exige acertar uma condição de timing/formatação específica, não é trivial de disparar.

O problema (CWE-400, consumo não controlado de recursos / negação de serviço) está no tratamento das linhas VTY (virtual terminal) que atendem sessões de Telnet e Reverse Telnet no IOS. Ao receber uma conexão TCP especialmente formada nessas portas, o processo que gerencia a linha VTY entra em um estado que faz o dispositivo recusar conexões subsequentes a todos os serviços de gerência que dependem das mesmas linhas — não só Telnet, mas também SSH, SCP, RSH e, quando aplicável, o servidor HTTP embutido.

O atacante controla apenas o conteúdo/estrutura do pacote TCP inicial enviado à porta 23 (Telnet) ou às faixas usadas por Reverse Telnet (2001–2999, 3001–3099, 6001–6999, 7001–7099). Não é necessária autenticação nem estabelecimento completo de sessão — a falha ocorre no processamento da camada de conexão, antes de qualquer prompt de login.

Há um componente separado documentado pelo CERT/CC: o servidor HTTP embutido versão 1.0, presente em builds de IOS anteriores a 12.2(15), também é afetado como consequência do mesmo problema de VTY. A versão 1.1 do servidor HTTP, incluída a partir do 12.2(15), não sofre esse efeito colateral específico — mas isso descreve apenas o sintoma no HTTP, não confirma que o núcleo da vulnerabilidade de Telnet esteja corrigido nessa mesma versão.

Sessões já estabelecidas antes do ataque continuam funcionando normalmente; o efeito é bloquear apenas novas conexões às linhas de gerência.

O vetor é uma conexão TCP direcionada à porta de Telnet (23/tcp) ou a uma das faixas de Reverse Telnet do dispositivo. Não exige autenticação, não exige acesso privilegiado e não exige configuração não padrão — basta que o atacante tenha alcance de rede até a interface de gerência do equipamento, o que em muitos ambientes de borda ou provedores era (e ainda é, quando Telnet não foi desativado) bastante comum em 2004.

A complexidade de ataque (AC:H no vetor CVSS 3.1) vem do fato de que o pacote precisa ser malformado de um jeito específico para acionar o estado de recusa — não é qualquer conexão TCP à porta 23 que dispara o problema, e o mecanismo exato do parsing defeituoso não foi publicado em detalhe pela Cisco nem pelo CERT/CC nas fontes disponíveis. O resultado prático é a perda de acesso administrativo remoto ao dispositivo: um operador que precise entrar via Telnet, SSH, SCP, RSH ou HTTP fica bloqueado até que a conexão problemática seja limpa ou o equipamento seja reiniciado.

A entrada no catálogo KEV da CISA foi adicionada em 2023 como parte de um esforço de catalogar vulnerabilidades antigas com histórico de exploração documentada, não como indício de uma campanha de exploração ativa recente. O CERT/CC, em 2004, já registrava relatos de exploração ativa no momento da divulgação original.

As fontes disponíveis não trazem o texto completo do advisory oficial da Cisco (cisco-sa-20040827-telnet) com a lista precisa de versões corrigidas por trem de release — apenas o resumo do CERT/CC, que trata a questão como sem patch definitivo disponível no momento da publicação e recomenda workarounds. Não afirme que atualizar para 12.2(15) resolve o problema de fundo: essa versão corrige apenas o efeito colateral no servidor HTTP embutido (troca da versão 1.0 pela 1.1), não necessariamente a causa raiz no tratamento de VTY/Telnet.

Os controles compensatórios documentados pelo CERT/CC e pela Cisco são: desabilitar Telnet nas linhas VTY e usar exclusivamente SSH (`transport input ssh` nas linhas vty); aplicar uma access-class na VTY restringindo quem pode conectar por Telnet, Reverse Telnet, RSH, SSH ou SCP; bloquear nas ACLs de interface o tráfego de entrada para a porta 23 e para as faixas de Reverse Telnet (2001–2999, 3001–3099, 6001–6999, 7001–7099) como parte de uma Transit ACL ou Infrastructure ACL (iACL); em plataformas distribuídas como GSR 12000 (a partir do IOS 12.0(21)S2) e 7500 (a partir do 12.0(24)S), usar Receive ACLs (rACLs) para proteger o route processor antes que o tráfego malicioso chegue à CPU principal.

Se o dispositivo já estiver no estado de recusa de conexões, o CERT/CC indica usar o comando `who` para identificar a linha VTY afetada e limpá-la (`clear line`), ou recarregar o equipamento como último recurso — nenhuma dessas ações é preventiva, apenas restaura o acesso depois do incidente.

Sinal mais direto: administradores relatando incapacidade súbita de conectar via Telnet, SSH, RSH, SCP ou HTTP a um dispositivo que antes aceitava essas conexões normalmente, enquanto sessões de gerência já abertas continuam funcionando. Em logs de dispositivo, o comando `who` mostrando linhas VTY em estado anômalo (ocupadas sem sessão de usuário legítima correspondente) é indicativo. No tráfego de rede, procurar conexões TCP incompletas ou malformadas destinadas à porta 23 ou às faixas de Reverse Telnet vindas de origens não administrativas — mas como o mecanismo exato de disparo não foi publicado em detalhe, não há assinatura confiável e específica para diferenciar tentativa de exploração de tráfego legítimo malformado por outros motivos.