Funcionalidade em equipamentos da Cisco permite espionagem

Os pesquisadores brasileiros Joaquim Espinhara e Rafael Silva identificaram uma falha nos roteadores Cisco que possibilita monitorar toda comunicação trafegada nesses equipamentos, aprimorando estratégias de vigilância a partir da extração de qualquer dado não criptografado, como credenciais de acesso, dados de cartão e informações pessoais.

Mimosa

Não se trata exatamente de uma falha. Na realidade, a maioria dos equipamentos da Cisco possui em seu sistema operacional um mecanismo chamado EPC (Embedded Packet Capture) que permite o monitoramento de toda comunicação de entrada e saída do dispositivo e o envio destas informações para qualquer computador remoto.

O EPC não permite configurar um conjunto de computadores como destino da informação, limitando assim o acesso aos dados. Ou seja, para estar apto a receber todo tráfego, basta estar em alguma das redes controladas pelo roteador alvo.

O mecanismo foi criado com o objetivo de auxiliar os administradores no diagnóstico de falhas de comunicação. Entretanto, os pesquisadores conseguiram automatizar o processo de configuração remota do EPC para que este envie todos os pacotes trafegados para qualquer computador na rede.

Segundo os pesquisadores, a Cisco desenvolveu os seus sistemas operacionais de maneira a impedir que o EPC seja desativado. Ou seja, se sua empresa usa as versões 15 ou superiores do IOS[1. Nomenclatura dos sistemas operacionais da Cisco, não se deve confundir o iOS da Apple.], esses dispositivos comtemplam o EPC por padrão e não é possível desativá-lo De modo que, uma pessoa usando do framework, chamado pelos pesquisadores de µMIMOSAWRITERROUTER (apelidado de Mimosa) pode coletar todo o tráfego de um roteador e enviar para um repositório em qualquer lugar da internet.

Algumas limitações? Talvez não.

Por si só, o framework Mimosa não possui funcionalidades de quebra de senhas, de violação de pacotes criptografados ou de escalação de privilégios.

Dito de outra maneira, para que seja possível coletar as informações dos roteadores é necessário ter as credenciais de acesso (usuário e senha) de um administrador, bem como a certeza de que terá que usar outras técnicas para lidar com o conteúdo criptografado.

Neste momento o leitor deve estar pensando: “Ufa! Não é tão grave assim”. Recomendo refletir novamente.

Imagine uma empresa de telefonia ou um data center com milhões de roteadores para administrar. É bem provável que muitas empresas definam senhas padrão para estes dispositivos ou, se aplicarem senhas específicas, as mantenham numa base de dados para consulta.

Também é bem comum que empresas mantenham a senha padrão de fábrica em muitos dispositivos. Consultorias globais de segurança estão sempre identificando esta falha de administração em seus clientes. Compartilho dois relatórios da Verizon e Trustwave que tocam nesse tema.

Um exemplo recente é a descoberta divulgada na última RSA Conference de que dispositivos de pagamento nos EUA usavam a mesma senha desde 1990. Óbvio que esse caso não se refere a dispositivos Cisco. Entretanto, o que quero dizer é que definir senhas que permanecem ativas por muito tempo e são compartilhadas entre muitas pessoas não é exceção, mas sim regra.

Outro fator é o da criptografia. Existem sim mecanismos de criptografia ótimos para a proteção do tráfego. Porém, também existem muitas implementações toscas ou desatualizadas.

No mês passado, o NIST, órgão que define os padrões para todas as entidades do governo americano[2. Semelhante à “ABNT” no Brasil.], baniu o uso de qualquer versão do protocolo de criptografia de tráfego SSL, ainda muito usado[3. O “cadeado” de segurança exibido nos navegadores em sites seguros, popularmente conhecido como SSL, hoje utiliza um protocolo diferente e mais seguro chamado de TLS. Ainda é possível que alguns sites tenham suporte apenas ao SSL, e a recomendação do NIST é para que nenhum navegador ou servidor aceite conexões nessa modalidade e obrigue o uso do TLS.]. Ou seja, todo cuidado é pouco ao usar uma criptografia a qual você não tem o controle de suas configurações, como algoritmos e chaves.

De quem é a culpa

É comum, sobretudo para as pessoas que não atuam diretamente com segurança da informação, identificar os pesquisadores que trazem falhas como estas à tona como os culpados por tornar as redes menos seguras.

Esta é uma questão polêmica, entretanto trazer problemas à luz precisa ser visto como uma oportunidade para os desenvolvedores ou administradores de soluções injetarem a mentalidade de segurança no design e operação dos seus produtos.

Mecanismos como o EPC precisam ser passíveis de desativação e os administradores precisam implementar uma metodologia que privilegie o uso de credenciais de acesso pessoais e intransferíveis ou mecanismos de duplo fator de autenticação.

A trilha para o progresso do conhecimento humano passa por identificar formas melhores ou mais seguras de fazer as coisas. Culpar aqueles que apontam problemas é o mesmo que permitir que a proteção das nossas informações seja baseada na ocultação das falhas. Isso não é nada eficiente, pois ocultar não protege; pelo contrário, perpetua formas antiquadas de fazer as coisas.

Pude relatar um exemplo disso aqui, em que falo da negligência da Microsoft em corrigir uma vulnerabilidade que ficou ativa por quase duas décadas.

Em suma, mostrar a nudez dos reis não é, em minha opinião uma opção, mas sim uma necessidade.

Agenda

As características de Mimosa já foram apresentadas na conferência Infiltrate (Miami – EUA). Nas próximas semanas, Joaquim e Rafael estarão se dividindo para demonstrar o framework nos seguintes eventos:

• CONFidence, 25 e 26 de maio (Cracóvia — Polônia);
• HITBSecConf, 26 a 29 de maio (Amsterdam — Holanda)
• You Sh0t the Sheriff, 28 de maio em São Paulo.