Que beleza hein… depois de encontrarem malware em roteadores Cisco, agora encontraram um “software não autorizado” nos firewalls Juniper. A própria Juniper descobriu o problema no ScreenOS, software que equipa firewalls da empresa. Segundo o comunicado as vulnerabilidades permitem que um atacante tenha acesso administrativo nos firewalls NetScreen (CVE-2015-7755) e seja capaz de descriptografar conexões VPN (CVE-2015-7756). Até o momento não há nenhuma informação de que estas vulnerabilidades tenham sido utilizadas, mas como a senha para acesso administrativo foi divulgada publicamente… Para resolver estes problemas os equipamentos afetados devem ser atualizados. As Vulnerabilidades O código malicioso que permite o acesso administrativo pode ser encontrado da versão 6.3.0r17 até 6.3.0r20 do ScreenOS, e uma vez que a vulnerabilidade tenha sido explorada é possível ver nos logs uma entrada “system has logged on via SSH…”. Exemplo de Log normal e comprometido: Login normal, user username1:2015-12-17 09:00:00 system warn 00515 Admin user username1 has logged on via SSH from …..2015-12-17 09:00:00 system warn 00528 SSH: Password authentication successful for admin user ‘username1’ at host … Login comprometido, user username2:2015-12-17 09:00:00 system warn 00515 Admin user system has logged on via SSH from …..2015-12-17 09:00:00 system warn 00528 SSH: Password authentication successful for admin user ‘username2’ at host … No entanto o hacker pode apagar o log, o que impediria de saber se o sistema foi comprometido. A outra vulnerabilidade (descriptografia) pode ser encontrada nos software ScreenOS 6.2.0r15 até 6.2.0r18 e da versão 6.3.0r12 até 6.3.0r20, e não há como saber se ela foi explorada. Outras informações nos links abaixo: – Important Announcement about ScreenOS – Multiple Security issues with ScreenOS Até a próxima.
Cisco CleanAir, Event Driven RRM e Persistent Non-WiFi Interference
O Cisco CleanAir é um sistema com componentes em software e hardware que permite que os access-points identifiquem interferências não WiFi. E temos muitos dispositivos não WiFi (fornos micro-ondas, dispositivos bluetooth, telefones sem fio e câmeras sem fio, entre outros) utilizando as bandas 2.4 GHz e 5 GHz. Um access-point convencional (sem CleanAir) no máximo consideraria estas interferências não WiFi como “ruído”. Já os equipamentos com CleanAir, trabalhando junto com a controladora, conseguem classificar como interferência, dizer que tipo de dispositivo é, e até a área afetada (quando integrado com Prime e MSE). Com base nestas informações a WLAN Controller pode tomar a decisão de mudar os canais que os access-points estão usando, e assim evitar a interferência. Habilitando o CleanAir Vá em Wireless > 802.11b/g/n (ou 802.11a/n/ac) > CleanAir e marque as opções CleanAir e Report Interferers. No entanto, apesar dos access-points estarem monitorando o ar o tempo todo, e enviar reportes para a controladora a cada 15 segundos, a controladora tem o seu tempo para fazer a mudança de canal (10 minutos é o intervalo padrão e o menor intervalo possível para rodar o algoritmo de mudança de canal). Isso significa que caso um interferência seja identificada, pode levar até 9’59’” para que a controladora tome uma ação. E ai entra o Event Driven RRM. Event Driven RRM O Event Driven RRM é uma forma de acelerar a mudança de canal, com base na qualidade do ar. Caso uma interferência identificada e classificada (CleanAir) faça com que a qualidade do ar fique abaixo do limite estabelecido, o ED-RRM força a mudança de canal. Isso ocorre em 30 segundos. Importante dizer que a mudança de canal é não aleatória, e sim uma escolha baseada nas informações do ambiente. A WLC sempre tentará utilizar o melhor canal para cada access-point. Uma vez feita a troca de canal, o ED-RRM tem um tempo de espera de 60 segundos antes de ser executado novamente, e além disso, o evento é registrado, evitando que o AP afetado volte a usar o canal impactado nas 3 horas seguintes. Habilitando o ED-RRM Vá em Wireless > 802.11b/g/n (ou 802.11a/n/ac) > RRM > DCA e marque a opção EDRRM. Podemos ainda escolher a sensibilidade (limite da qualidade do ar) para que o EDRRM entre em ação. As opções são Medium (qualidade do ar = 50), High (65) e Low (35). Persistent Device Avoidance Outra funcionalidade que apenas access-points com CleanAir tem é o Persistent Device Avoidance. Como já mencionando acima, o CleanAir é capaz de identificar e classificar as interferências não WiFi. Graças a este inteligência o sistema (APs / WLC) consegue identificar dispositivos que estão causando interferência e voltarão/continuarão a causar (dispositivos persistentes). Com esta informação, e se a função Persistent Device Avoidance estiver habilitada, a interferência será marcada para que os access-points que foram afetados pela interferência não voltem a usar o canal. O canal só será liberado para uso novamente se a interferência não voltar a aparecer por 7 dias. Habilitando o Persistent Device Avoidance Vá em Wireless > 802.11b/g/n (ou 802.11a/n/ac) > RRM > DCA e marque a opção Avoid Persistent Non-WiFi Interference. Importante dizer que reiniciar a WLC ou o access-point apaga as referencias de interferências persistentes. Mais informações sobre CleanAir no Wireless Network Design Guide. Até a próxima.
Configurando logging nas access-lists (Cisco ASA)
No Cisco ASA cada entrada em uma access-list, chamada ACE – Access Control Entry, pode gerar log. Por padrão, quando o tráfego é negado por uma ACE de uma access-list extendida (ou Webtype ACE) é gerada uma mensagem syslog (106023), como no exemplo abaixo: ACE: access-list inside_access_in line 1 deny ip host 10.123.45.20 any Log: %ASA-4-106023: Deny udp src inside:10.123.45.20/61619 dst outside:8.8.4.4/53 by access-group “inside_access_in” [0xf61894a9, 0x0] Mas podemos mudar esse comportamento inserindo a palavra “log” no fim da access control entry. Com essa configuração, o invés de gerar uma mensagem syslog 106023 para cada pacote negado, o ASA passa gerar uma mensagem 106100 e habilita um contador que indicará quantos pacotes foram negados em um certo intervalo de tempo (o padrão é 300 segundos) para aquele fluxo (IP e porta de origem, IP e porta de destino). ACE: access-list inside_access_in line 1 deny ip host 10.123.45.20 any log Log: %ASA-6-106100: access-list inside_access_in denied udp inside/10.123.45.20(62386) -> outside/200.221.11.100(53) hit-cnt 1 first hit [0xf61894a9, 0x0] Essa medida é extremamente útil quando o equipamento está sofrendo um ataque, pois ajuda a diminuir a quantidade de logs gerados e ainda a reduzir o processamento. Se desejado, ainda podemos desabilitar complementa a geração de logs, inserindo a opção “disable” no fim da linha. ACE: access-list inside_access_in line 1 deny ip host 10.123.45.20 any log disable Com esta configuração o tráfego será bloqueado, mas nenhuma mensagem syslog será gerada. Aliás, é o que acontece com o “deny implicito”, que bloqueia o tráfego que não foi liberado explicitamente sem gerar logs. Por fim, para remover o “log” de uma determinada linha, basta usar o parâmetro “default”. ACE: access-list inside_access_in line 1 deny ip host 10.123.45.20 any log default Com este comando a ACE voltará ao padrão, gerando mensagens syslogs 106023 para cada pacote negado. Mais detalhes no CLI Configuration Guide. Até a próxima.
SYNful Knock: Malware em roteadores Cisco
No último dia 15 a FireEye publicou a descoberta de roteadores Cisco “infectados” com a ameaça que foi chamada SYNful Knock. Até o momento 199 roteadores (1841, 2811 e 3825) foram encontrados com este malware (nenhum no Brasil). Não sei bem se infectado é o termo correto, já que na verdade alguém modificou o software incluindo esta “funcionalidade” e então colocou o software modificado nos roteadores. Acredita-se que para isso (trocar o software) não foi utilizada nenhuma vulnerabilidade do IOS original, e que tenham aproveitado de equipamentos mal configurados (utilização de senha padrão ou fraca), ou do acesso físico aos dispositivos. Roteadores utilizando este IOS modificado permitem a conexão com redes CnC (Command and Control) e acesso remoto privilegiado. Com isso podem monitorar e roubar informações, “saltar” para outros equipamentos na rede e até mesmo alterar o código do malware, conforme desejo de seu desenvolvedor. A Cisco já postou vídeo com um alerta para os consumidores, criou um página de reposta com todas as informações, criou uma nova regra para Snort, que detecta equipamento infectados, uma série de posts sobre o assunto, e ainda um scanner que pode detectar equipamentos comprometidos. Os pesquisadores acreditam que é possível verificar se um equipamento está comprometido com o comando show platform, conforme abaixo. Output de um roteador NÃO infectado BrainRT01#show platform | include RO, Valid 16M 0x60000000:0x61FFFFFF 0x00000000:0x01FFFFFF CacheMode=3, RO, Valid 4M 0x62000000:0x627FFFFF 0x02000000:0x027FFFFF CacheMode=3, RO, Valid 4M 0x62800000:0x62FFFFFF 0x02800000:0x02FFFFFF CacheMode=3, RO, Valid 4M 0x63000000:0x637FFFFF 0x03000000:0x037FFFFF CacheMode=3, RO, Valid 1M 0x63800000:0x639FFFFF 0x03800000:0x039FFFFF CacheMode=3, RO, ValidBrainRT01# Algumas área da memória permitem apenas leitura, mas no software adulterado estas áreas foram modificadas para permitirem a escrita, e assim o comando não trará nenhum output. Output de um roteador INFECTADO (exemplo) BrainRT01#show platform | include RO, Valid BrainRT01# Lembro de uma apresentação do Adilson Florentino (do blog Netfinders), no Web Security Forum, chamada “IOS Trojan – Quem é o dono do seu roteador?”. Nela o Adilson alertava justamente para o risco de alguém ter acesso ao seu equipamento e instalar um trojan, que permitiria acesso a sua rede. Na ocasião o “perigo” mais claro estava no EEM, que permite alguém criar um código no próprio roteador, liberando acesso remoto (via túnel GRE, por exemplo) e ainda maquiar o output dos comandos shows para não ser detectado. Mas isso já faz uns quatro anos… evoluíram bastante. Cisco IOS Image File Verification No próprio Cisco IOS temos a opção para verificar a autenticidade e integridade do software que está sendo utilizado. Basta usar o comando verify /md5 filesystem:filename [md5-hash] parar calcular o hash MD5 do software apontado e comparar com o hash informado pelo usuário. Verificando a autenticidade e integridade do IOS BrainRT01#verify /md5 flash:/c1841-advipservicesk9-mz.151-4.M10.bin 08cd5b9afd7da78307b392675769fb9e(output omitido)…………………………………………………………………………………………………………………………………………….…………………………………………………………………………………………………………………………………………….…………………………………………………………………………………………………………………………………….Done!Verified (flash:/c1841-advipservicesk9-mz.151-4.M10.bin) = 08cd5b9afd7da78307b392675769fb9e O hash pode ser obtido no site da Cisco (na área de download), e este é um processo normal quando fazemos a atualização do software em roteadores. Agora devemos usarmos esta funcionalidade para verificar se o equipamento não está infectado. IOS alterado ou corrompido BrainRT01#verify /md5 flash:/c1841-advipservicesk9-mz.151-4.M10.bin 08cd5b9afd7da78307b392675769fb91(output omitido)…………………………………………………………………………………………………………………………………………….…………………………………………………………………………………………………………………………………………….…………………………………………………………………………………………………………………………………….Done!%Error verifying flash:/c1841-advipservicesk9-mz.151-4.M10.binComputed signature = 08cd5b9afd7da78307b392675769fb9eSubmitted signature = 08cd5b9afd7da78307b392675769fb91 Até a próxima.
Instalando licença no Cisco Firesight
O FireSight Management Center (anteriormente chamado de Defense Center) é o software de gerência do NGIPS da Cisco. Através dele fazemos todas as configurações e podemos ver as informações das conexões que estão sendo inspecionadas pelos IPSs gerenciados. Também é no FireSight que instalamos as licenças, que são consumidas pelos sensores (NGIPS). Instalando licença no Firesight Para instalar um licença no FireSight, com a licença já em mãos (arquivo .lic recebido da Cisco), siga o procedimento abaixo. 1) Abra a licença (arquivo .lic) no Bloco de Notas e copie tudo que estiver entre “BEGIN” e “END”. 2) Acesse o FireSight (GUI) e na opção System > Licenses clique no botão Add New License. 3) Na tela seguinte, cole o texto que foi copiado do Bloco de Notas e clique em Verify License. OBS: Quando você vai solicitar a licença para a Cisco, é necessário informar o License Key do seu FireSight, que pode ser encontrado nesta tela. 4) Após, caso a licença seja válida, Clique em Submit License. 5) Você verá a mensagem de sucesso na parte superior da tela. 6) Agora que a licença já esta instalada no FireSight vá na aba Devices e clique em Add. Informe o IP, chave para comunicação entre o FireSight e o NGIPS, e política de acesso que deverá ser associada ao NGIPS. Então selecione a (s) licença (s) que você deseja associar a este dispositivo e clique em Register. Para ver o comparativo entre as licenças do FireSight, clique aqui. Até a próxima.
Compartilhar rede no Windows 8, 8.1 e 10 (hotspot)
Com o acesso mais fácil às tecnologias como 3G e 4G, e a disponibilidade de redes WiFi em muitos lugares, o compartilhamento de rede através do PC já não é muito utilizado. Porém continua disponível e pode ser uma boa solução. Recentemente estive em um hotel que disponibilizava WiFi, mas o sinal era péssimo e 3G nem pensar. Felizmente o quarto tinha um ponto de rede cabeado, e usando o notebook compartilhei a internet para os demais dispositivos (celulares e tablets). Existem aplicativos para fazer o compartilhamento, mas podemos fazer isto diretamente no Windows, usando linha de comando, e o melhor: não é complicado. Configurando hostspot no Windows 8, 8.1 e 10 (hostednetwork) 1) Clique com o botão direito do mouse no ícone Windows e selecione a opção Prompt de Comando como Administrador. 2) Via linha de comando crie e inicie a rede virtual que servirá como hotspot. Depois verifique o status. Os comando são: netsh wlan set hostednetwork mode=allow ssid=brainwork key=senha123 (cria a rede, define o nome do ssid e senha) netsh wlan start hostednetwork (inicia o serviço) netsh wlan show hostednetwork (mostra o status da rede) 3) Vá até as Conexões de Rede no Painel de Controle e clique com o botão direito do mouse em propriedades na PLACA DE REDE CABEADA. Então vá na aba Compartilhamento, marque a opção “permitir outros usuários se conectarem através deste computador”. Em seguida escolha a rede criada via linha de comando. 4) Pronto. Podem conectar no hostspot criado (brainwork). Se quiser, use o comando netsh wlan show hostednetwork para ver os clientes da sua rede. Até a próxima.
