Por Oliver Sartori, Pesquisador do Real Labs

Introdução

Durante um pentest nos preocupamos com o nível de segurança e maturidade do blue team posicionado no ambiente do cliente, esperando que conexões e hosts estejam sendo monitorados. De fato, sempre tentamos começar de uma maneira menos ruidosa para entender a resposta que vamos encontrar.

Assim, por ser uma das primeiras etapas de um ataque, o levantamento de informações ativo, como o escaneamento de portas e redes via Nmap, acaba sendo bem comedido e observado nas primeiras vezes.

Quando falamos de escaneamento de portas e redes, uma das primeiras contra-medidas que vem a mente é um NIDS (Network Intrusion Detection System), seja monitorando todo o tráfego da rede, seja baseado em hosts. Desta forma, nada mais natural que aprender como um NIDS funciona para tentar enganá-lo, gerando a menor quantidade de alertas possíveis para o blue team.

Apesar de existirem diversas opções de NIDS no mercado, vamos escolher, para realizar nossos testes práticos, um dos maiores, mais difundidos e suportados NIDS open-source da atualidade, o Snort.

 

Ambiente

Abaixo vemos as especificações gerais do ambiente na qual realizaremos os testes:

Vítima:

192.168.56.101
Windows 7 32 bits
Snort 2.9.11.1-WIN32 GRE <Build 268>
Kiwi Syslog Server – Free version 9.6

 

Atacante:

192.168.56.1
Nmap 7.60

 

Configuração do Snort

Não pretendemos entrar em detalhes sobre a configuração do Snort para Windows (que é bem detalhista e com pormenores técnicos), entretanto, uma opção que vem desabilitada por padrão chamou atenção e pareceu muito propícia para o nosso caso, o pré-processador “sfportscan”.

Segundo a documentação oficial (https://www.snort.org/faq/readme-sfportscan):

“This module is designed to detect the first phase in a network attack: Reconnaissance. In the Reconnaissance phase, an attacker determines what types of network protocols or services a host supports. This is the traditional place where a portscan takes place. […] One of the most common portscanning tools in use today is Nmap. Nmap encompasses many, if not all, of the current portscanning techniques. sfPortscan was designed to be able to detect the different types of scans Nmap can produce.”

Assim, a maior diferença para os tutoriais durante a configuração foi a ativação do sfportscan:

preprocessor sfportscan: proto { all } scan_type { all } sense_level { high } watch_ip { 192.168.56.0/24 } memcap { 10000000 } logfile { portScan.log } detect_ack_scans

 

Regras do Snort

De forma geral, o funcionamento do Snort (e de alguns outros NIDS) é governado pelas regras que nele habitam, ou seja, o que será e o que não será pego depende destas regras. Como não podemos prever os conjuntos de regras que estão vigiando uma infraestrutura, vamos brincar com as regras padrões e gratuitas do Snort.

Dois conjuntos de regra estão disponíveis gratuitamente no site do Snort: “Community” e “Registered”, sendo este último disponível após um cadastro no site. Para os testes escolhi utilizar apenas o Registered.

Algo que me chamou atenção neste conjunto foi o fato de que alguns arquivos estavam vazios e outros continham muitas regras comentadas, assim, decidi juntar todos os arquivos de regras em um único arquivo e descomentar todas as regras, criando um único grande arquivo de regras. Se está certo ou não, não sei (provavelmente não)! Mas serve para mostrar o fato de que a regra já existe, ou seja, não precisa ser algo novo criado por alguma mente brilhante para identificar nosso ataque!

 

Hands-On

Para dar início a bateria de testes resolvi começar por algo simples, como um ping:

$ ping 192.168.56.101

Teste de Ping

Teste de Ping

Para nossa surpresa, duas regras distintas alertaram meu ping ( era o modo paranóico). Repare no final das linhas, as setas de fluxo do 192.168.56.1 para 192.168.56.101, aqui fica claro que duas regras distintas pegaram nosso ping e não uma para o echo request e outra para o echo reply.

Outro ponto legal é que uma das regras é “ICMP PING”, enquanto a outra é “ICMP PING Unix”. O que será que na regra fez o Snort identificar nosso Linux?

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:”PROTOCOL-ICMP PING Unix”; itype:8; content:”|10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F|”; depth:32; metadata:ruleset community; classtype:misc-activity; sid:366; rev:11;)

Duas keywords chamam a atenção: content e depth. Olhando o manual (http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node32.html) temos:

  • content: The content keyword is one of the more important features of Snort. It allows the user to set rules that search for specific content in the packet payload and trigger response based on that data. Whenever a content option pattern match is performed, the Boyer-Moore pattern match function is called and the (rather computationally expensive) test is performed against the packet contents. If data exactly matching the argument data string is contained anywhere within the packet’s payload, the test is successful and the remainder of the rule option tests are performed. Be aware that this test is case sensitive.
  • depth: The depth keyword allows the rule writer to specify how far into a packet Snort should search for the specified pattern. depth modifies the previous `content’ keyword in the rule. A depth of 5 would tell Snort to only look for the specified pattern within the first 5 bytes of the payload.

Para tirar a prova real usaremos o Wireshark para ler os pacotes que a máquina recebe. Analisando a sessão “data” do ICMP echo request recebido veremos exatamente a sequência “10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F” no meio dos dados. Não acredita? Confira:

Wireshark icmp eche request

Wireshark icmp eche request

Ora, se disparamos uma regra apenas pelo conteúdo do “data”, o que acontece se o alterarmos? No Linux é possível mudar parcialmente o payload do ping através da opção -p:

$ ping -p 00 192.168.56.101

Teste de Ping Modificado

Teste de Ping Modificado

Lindo! Agora que acabamos nosso pequeno teste podemos passar para o Nmap. Quando adentramos em uma rede desconhecida, uma das primeiras coisas que fazemos após descobrir informações básicas como range, gateway, DNS e etc, é encontrar hosts ativos, ação conhecida como host discovery.

Assim, antes de começarmos a escanear portas como se não houvesse amanhã, vamos somente descobrir os hosts ativos na rede. Aqui, nossa melhor opção é desabilitar qualquer port scan com o comando -sn:

# nmap -sn 192.168.56.0/24

Wireshark nmap -sn

Wireshark nmap -sn

Como podemos ver pela imagem acima, o nmap encheu a rede com arp requests, enviando um para cada possível IP da rede, assim, quem estiver ativo provavelmente responderá, entregando sua posição.

Na perspectiva de um único host, esta é uma requisição normal e que não deveria gerar qualquer alerta, e é exatamente isto que acontece! O Snort não alertou nenhuma atividade anômala.

Apesar de ser normal um arp request da perspectiva de um único host, um NIDS baseado em toda a rede (e não somente no host) provavelmente geraria um alerta devido a quantidade de arp requests enviados por uma única máquina em tão pouco tempo. Portanto atenção, apesar da técnica não ser intrusiva da perspectiva de um único host ela pode sim ser considerada alarmante na perspectiva da rede como um todo.

Agora que sabemos que nosso alvo está ativo, vamos finalmente passar para o escaneamento de portas. Apenas para deixar as coisas mais interessantes, vamos abrir mais portas para serem escaneadas habilitando os serviços do XAMPP:

XAMPP

XAMPP

Uma das opções de port scan mais utilizadas no nmap é o TCP SYN scan (-sS). Por não precisar fechar o handshake da conexão, este tipo de scan é rápido e relativamente furtivo, sendo um dos queridinhos da galera. Mas será que ele é tão furtivo assim?

# nmap -sS 192.168.56.101

Snort nmap -sS

Snort nmap -sS

É… como podemos ver pela imagem acima, o Snort alertou diversas tentativas de scan, algo que com certeza alertaria o blue team.

Outro ponto de interesse a partir de agora é a classificação do alerta. Acima podemos ver diversos “[Classification: Attempted Information Leak]”, esta classificação indica a prioridade e o tipo geral do alerta (http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node31.html#SECTION00446200000000000000). No nosso caso, este tipo de classificação possui prioridade média, mas só pelo nome já não parece algo que chamaria atenção.

Assim, a partir de agora, nosso objetivo não é somente eliminar alertas, mas também diminuir a prioridade do alerta, recomendo assim darem uma olhada no link acima, ele define a tabela de classificação padrão do Snort. Acredite, alertas sempre irão existir, o importante é gerar os alertas menos severos, mas isso fica para a próxima postagem. Com isto terminamos nossa primeira parte dessa épica batalha entre ataque vs defesa, nmap vs Snort.