CVE-2018-0179

Falha de negação de serviço no recurso Login Enhancements (Login Block) do Cisco IOS Software: um atacante remoto não autenticado que tente logins inválidos repetidos via SSH ou Telnet pode provocar reload do dispositivo. O CVSS 6.8 com AC:H reflete que a exploração exige uma sequência de configuração específica e não padrão no equipamento — não é um DoS trivial de rede aberta.

A vulnerabilidade está classificada como CWE-399 (gerenciamento impróprio de recursos): o código do Login Block tenta liberar (free) uma área de memória que nunca foi alocada. Isso ocorre dentro da lógica de 'quiet mode' do IOS, que é acionada quando o sistema detecta múltiplas falhas de autenticação e decide bloquear temporariamente novas tentativas de conexão (Telnet/SSH) para mitigar ataques de dicionário.

O gatilho depende da ordem em que os comandos foram configurados no dispositivo: a vulnerabilidade só existe se 'login quiet-mode access-class' foi configurado ANTES de 'login block-for', e se o roteador não foi reiniciado desde então. Essa combinação de ordem de configuração deixa uma estrutura de controle de acesso inconsistente na memória do processo de login, que é referenciada incorretamente quando o quiet mode é acionado por falhas de autenticação repetidas.

O CVE-2018-0180, publicado no mesmo advisory, é uma segunda falha correlata mas independente: ocorre quando um atacante tenta logins inválidos repetidos enquanto um administrador está modificando a configuração de 'login block-for' em tempo real. As duas CVEs compartilham a mesma causa raiz (free de memória não alocada) mas condições de gatilho distintas — uma release pode ser afetada por uma e não pela outra.

O impacto final é reload completo do dispositivo (crash do processo de gerenciamento), não execução de código nem persistência — é DoS puro, refletido no vetor CVSS (C:N/I:N/A:H).

O vetor de ataque é rede: o atacante envia múltiplas tentativas de autenticação inválida via SSH ou Telnet contra a interface de gerência do dispositivo. Não é necessário credencial válida nem qualquer forma de autenticação prévia — por isso PR:N e UI:N no vetor CVSS. Entretanto, a complexidade de ataque é alta (AC:H) porque o disparo depende inteiramente do estado de configuração do dispositivo-alvo: 'login quiet-mode access-class' precisa ter sido configurado antes de 'login block-for', e nenhum reload deve ter ocorrido desde então. Nenhuma dessas condições é padrão de fábrica — exigem intervenção deliberada do administrador na ordem exata.

Na prática, isso restringe bastante o universo de alvos reais: dispositivos com Login Block configurado corretamente (ordem inversa) ou nunca configurado não são exploráveis por essa CVE específica. Ambientes que aplicaram hardening de login sem seguir a ordem recomendada de comandos ficam expostos até o próximo reload — quando a condição se resolve espontaneamente, mas volta a existir se a configuração for reaplicada na ordem errada.

A presença no catálogo KEV da CISA (adicionada em março de 2022, quatro anos após a publicação) indica exploração confirmada em campo, mas não há detalhamento público sobre campanhas específicas, atores ou volume de exploração — a nota da CISA é genérica ('Known To Be Used in Ransomware Campaigns: Unknown').

O advisory da Cisco afirma explicitamente que não há workaround para nenhuma das duas vulnerabilidades ('No workarounds available'). A única mitigação real é atualizar o Cisco IOS Software para uma versão corrigida — as fontes consultadas não trazem a lista específica de releases corrigidos por trem de versão; é preciso verificar a versão fixa aplicável via Cisco Bug Search Tool (CSCuy32360 / CSCuz60599) ou Cisco Software Checker para a plataforma e trem de release em uso, já que o IOS tem múltiplos branches (T, M, CG) com ciclos de correção independentes.

Como controle compensatório imediato, se não for possível atualizar: revisar a ordem de configuração do Login Block e garantir que 'login block-for' seja configurado antes de 'login quiet-mode access-class', seguido de reload do dispositivo para eliminar o estado inconsistente em memória. Isso não corrige a falha de código, mas remove a pré-condição de disparo até nova reconfiguração incorreta.

Restringir acesso de gerência (SSH/Telnet) por ACL a origens confiáveis reduz a superfície de ataque mas não elimina o risco caso o atacante já tenha algum nível de acesso de rede interno. Não há mitigação via ACL de dados ou firewall de borda que substitua a correção — o recurso Login Block por definição precisa aceitar tentativas de conexão para funcionar.

Antes do crash e reload, o dispositivo registra pelo menos duas vezes mensagens de log como '%SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: USERNAME] [Source: xx.xx.xx.xx] [localport: 22] [Reason: Login Authentication Failed]' seguidas de '%SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is NN secs...'. A presença repetida desse par de mensagens imediatamente antes de um reload inesperado é o indicador de comprometimento citado pela própria Cisco.

Fora esse padrão de log, não há assinatura de tráfego de rede distintiva — o ataque consiste em tentativas de login normais (porém repetidas e falhas) via SSH/Telnet, indistinguíveis de um ataque de força bruta comum até o momento do crash.