Cisco IOS XR Software Health Check Open Port Vulnerability

Falha no RPM de health check do Cisco IOS XR Software: ao ser ativado, o pacote abre a porta TCP 6379 (Redis) sem autenticação, expondo a instância Redis que roda dentro do container NOSi nos Cisco 8000 Series Routers. O CVSS 6.5 reflete que o atacante só ganha leitura/escrita no Redis e no filesystem do container sandboxed — não há RCE nem comprometimento do host IOS XR —, mas está no catálogo KEV da CISA por exploração confirmada in-the-wild.

A causa é CWE-200 (exposição de informação) combinada com CWE-923 (configuração inadequada de canal de comunicação) conforme classificado pela Cisco e pela CISA respectivamente: o RPM xr-healthcheck, ao ser instalado e ativado, sobe um container Docker chamado NOSi que contém uma instância Redis escutando na porta 6379/TCP por padrão, sem exigir autenticação e sem estar restrita a loopback ou a uma interface de gerência isolada.

Como o Redis nessa configuração não tem senha (requirepass) nem bind restritivo, qualquer host com rota IP até o dispositivo consegue falar diretamente com o protocolo Redis. Isso permite ao atacante executar comandos Redis arbitrários: escrever chaves no banco em memória, extrair informação sobre o dataset armazenado, e usar o próprio Redis para gravar arquivos no filesystem do container (técnica clássica de abuso do comando CONFIG SET dir/dbfilename + SAVE para escrever arquivo persistido em disco).

A Cisco é explícita em dizer que, dado o sandboxing do container onde o Redis roda, esse acesso não se traduz em execução de código no sistema hospedeiro IOS XR nem em violação de integridade do host — o impacto é limitado à confidencialidade e integridade dentro do container NOSi (C:L/I:L/A:N no vetor CVSS). Isso é a diferença central entre a leitura de manchete ('acesso não autenticado a banco de dados Cisco') e o alcance real da falha.

Pré-requisito real: o roteador precisa ser um Cisco 8000 Series Router, rodando uma versão vulnerável do IOS XR, com o RPM de health check instalado e ativo (o que gera o container Docker NOSi visível via 'run docker ps'). Sem o RPM instalado/ativo, a porta 6379 nem existe. Não há necessidade de credenciais — é um vetor de rede pura (AV:N, PR:N, UI:N), então qualquer host com conectividade TCP à porta 6379 do dispositivo pode se conectar diretamente com um cliente Redis padrão e emitir comandos.

A CISA confirma exploração ativa (entrada no catálogo KEV desde 23/05/2022, prazo de correção 13/06/2022), mas não há detalhamento público de campanha, atores ou volume de exploração — o próprio catálogo KEV lista 'Known To Be Used in Ransomware Campaigns: Unknown'. Isso sugere exploração oportunista de scanners de internet buscando instâncias Redis expostas (padrão comum de abuso de Redis sem senha), mais do que uma campanha direcionada à Cisco especificamente.

Resultado final para o atacante: manipulação do banco Redis em memória, exfiltração de dados armazenados nele, e escrita de arquivos arbitrários no filesystem do container NOSi — mas confinado ao sandbox, sem pivotar para o plano de controle do IOS XR nem para outros containers/processos do dispositivo, segundo a análise da própria Cisco.

A Cisco recomenda como método preferencial desativar o health check por completo: comandos 'no healthcheck enable', 'healthcheck use-case asic-reset disable' e 'healthcheck use-case packet-drop disable', seguidos de commit, e depois remover o RPM com 'install package remove xr-healthcheck' + 'install apply restart' + 'install commit'. Isso elimina o container NOSi e a porta 6379 por completo — é a correção mais robusta quando o health check não é uma funcionalidade em uso.

Como alternativa (Option 2 do advisory), quando remover o health check não é viável, aplicar uma iACL (infrastructure ACL) de ingresso nas interfaces com IP configurado, bloqueando explicitamente TCP/6379 destinado ao espaço de endereços de infraestrutura, além de negar todo tráfego não autorizado dirigido aos endereços de gerência. A própria Cisco alerta que essa iACL não protege contra um atacante originado de um endereço já confiável/permitido pela política — ou seja, não é mitigação completa se a origem do ataque estiver dentro do perímetro liberado.

A Cisco afirma ter lançado atualizações de software que corrigem a vulnerabilidade, mas a tabela de releases corrigidas (Fixed Software) não constava no trecho do advisory disponível para esta pesquisa — não é possível citar aqui números de versão específicos sem risco de erro; consulte diretamente o advisório cisco-sa-iosxr-redis-ABJyE5xK e o Cisco Bug ID CSCwb82689 para a versão exata aplicável à sua imagem de IOS XR. Não depender apenas de 'firewall perimetral genérico' como mitigação — o controle correto é iACL aplicado na interface do próprio dispositivo, já que o tráfego de gerência costuma trafegar por VRFs ou interfaces distintas do tráfego de dados.

Para verificar exposição, executar 'run docker ps' no dispositivo IOS XR: a presença de um container com nome 'NOSi' indica que o health check está ativo e a porta 6379 provavelmente aberta. Em nível de rede, monitorar conexões TCP entrantes na porta 6379 dos endereços de gerência/infraestrutura dos roteadores Cisco 8000 é o sinal mais direto de tentativa de exploração — tráfego Redis (protocolo texto simples, comandos como CONFIG, SAVE, INFO) partindo de origens fora da rede de gerência esperada é forte indicador de sondagem ou exploração ativa.

Não há um IOC público específico de campanha documentado nas fontes consultadas além do registro genérico no catálogo KEV da CISA; a ausência de detalhamento sobre atores ou payloads sugere que a detecção depende primariamente de visibilidade de rede (NetFlow/firewall logs para porta 6379) e da auditoria de configuração do dispositivo, não de assinaturas conhecidas de exploit.