Idle Scanning and Related IPID Games


Original English version of this paper

Há aproximadamente 4 anos, Antirez - um pesquisador em segurança de redes - postou uma inovadora técnica de varredura de portas TCP que se tornou conhecida como "Idlescan" e permitiu uma varredura de portas completamente invisível. Atacantes podem atualmente realizar uma varredura de portas sem a necessidade de enviar sequer um único pacote com seu próprio endereço IP ! Ao invés, uma engenhosa técnica permite que o ataque tenha como origem, um host "zombie". Qualquer sistema de detecção de intrusão (IDS) identificará o "zombie" inocente como o atacante. Além desta extraordinária invisibilidade, esta técnica de varredura permite mapear as relações de confiança baseada em IP entre duas máquinas.

Eu assumi que um problema desta magnitude geraria uma reação imediata e correções por parte dos vendedors de SO. Infelizmente, muitos escolheram ignorar o problema por anos. Aparentemente, eles acreditaram que este é apenas um problema "teórico" que não é prático para explorar no mundo real. Para refutar esta posição e aumentar a pressão nos vendedores de SO para que corrijam o problema, eu disponibilizei uma robusta implementação do Idlescan nas versões recentes do Nmap. Este artigo descreve a técnica em detalhes e oferece defesas que os administradores de rede, ISPs e vendedores de SO possam usar para mitigar a vulnerabilidade.

Note que o Idlescan é somente um dos riscos de segurança causado pela previsível seqüência dos números IPID. Este artigo descreve também outros tipos de ataques para obtenção de informações, possibilitado por esta característica.

Técnica

Embora o Idlescan seja bastante sofisticado em termos de varredura de portas, não é necessário ser um perito em TCP/IP para entendê-lo. Você precisa somente conhecer alguns fatos comuns:

  • Maioria dos servidores escutam em portas TCP, como servidores Web na porta 80 e servidores de email na porta 25. Uma porta é considerada "aberta" se uma aplicação está escutando nesta porta, no contrário estará fechada.
  • Uma maneira de determinar quando a porta está aberta, é enviando um pacote "SYN" (estabelecimento de sessão) para a porta. A máquina destino enviará de volta um "SYN|ACK" (aceitação da requisição de sessão) se a porta estiver aberta ou um pacote "RST" (Reset) se a porta estiver fechada.
  • Uma máquina que recebe um pacote "SYN|ACK" não solicitado, responderá com um RST. Um RST não solicitado será ignorado.
  • Todo pacote IP na internet tem um número "identificador de fragmento". Muitos sistemas operacionais simplesmente incrementam este número para cada pacote que enviam. Observando então este número, um atacante pode saber quantos pacotes foram enviados desde a última observação.
Combinando estas características, é possível varrer a rede destino forjando sua identidade de modo que ela pareça uma máquina "zombie" inocente. Esta técnica é fácil de descrever através de um diagrama. Nesta figura abaixo, um atacante, A, está varrendo a máquina destino enquanto culpa o Zombie, Z, da varredura. As caixas representam as máquinas e as linhas representam os pacotes. Uma breve descrição em inglês dos pacotes está impressa sobre as linhas, enquanto as flags TCP e outras informações estão impressas embaixo delas:

Idlescan technique diagram

Como mostrado pelo diagrama acima, o host destino responde diferente para o Zombie dependendo o estado da porta. Se a porta observada está aberta, o destino envia um SYN|ACK para o Zombie. O Zombie não está esperando por este SYN|ACK, então ele envia um RST de volta. Enviando o RST, o Zombie causa o incremento da seqüência numérica IPID. O atacante real detecta isto no passo 3. Se a porta está fechada, o destino envia um RST para o Zombie. Zombies ignoram este pacote RST não solicitado e não incrementam sua seqüência numérica IPID.

Vantagens do Idlescan

Técnicas de Idlescan oferecem aos atacantes muitas vantagens em comparação à outras populares técnicas de varredura como SYN e FIN. É por isso que nós recomendamos defesas importantes para ajudar a proteger sua rede contra este ataque. Aqui estão algumas das razões em que os atacantes (ou testadores de intrusão) podem utilizar este método de varredura.

  • Extremamente anônimo -- Existem muitas técnicas que as pessoas podem utilizar para proteger sua identidade durante a varredura. Exemplos incluem o uso de "decoys" (nmap -D) or varredura half-open (nmap -sS). Porém mesmo estas técnicas, requerem que o atacante envie alguns pacotes para o destino usando seu endereço IP real. Idlescan, por outro lado, é completamente invisível, nenhum pacote com o endereço real de origem é enviado ao destino.

    Uma conclusão disto é que os sistemas de detecção de intrusão (IDS) identificarão e acusaram em alertas que a máquina zombie é quem disparou a varredura contra ele.

  • Transpassando roteadores/firewalls que filtram pacotes -- Filtros de IP de origem são um mecanismo comum para limitar as máquinas que têm acesso à um host delicado. Por exemplo, o servidor de banco de dados de uma companhia pode permitir conexões somente de um servidor web público que o acessa. Um usuário comum pode permitir conexões ssh (login interativo) somente de suas estações de trabalho.

    Um cenário mais perturbador ocorre quando alguma pessoa importante na companhia solicita que os administradores de redes abram uma brecha no firewall para ele poder acessar a rede interna de seu endereço IP. Isto pode ocorrer quando os executivos não querem ou não podem usar alternativas como VPNs seguras.

    O Idlescan pode ser freqüêntemente utilizado para mapear estas relações de confiança. O fator chave é que os resultados de um Idlescan listam portas abertas da perspectiva do host zombie. Deste modo, um scan normal contra o servidor de banco de dados acima mencionado poderia mostrar nenhuma porta aberta. Entretanto, aplicando um Idlescan utilizando o IP do servidor web como zombie, poderá expor a relação de confiança mostrando as portas abertas relacionadas aos serviços de banco de dados.

    Mapear estas relações de confiança pode ser muito útil para atacantes priorizarem seus destinos. O servidor web citado acima pode parecer comum para o atacante, até que ele note o acesso especial que tem aos servidores de banco de dados.

Exemplos de uso do Nmap

O primeiro passo é encontrar um host zombie apropriado. O host não deve ter muito tráfego (por isso o nome Idlescan) e deve apresentar valores IPID previsíveis. Impressoras, máquinas Windows, hosts Linux antigos, FreeBSD e máquinas Mac OS geralmente funcionam bem. As últimas versões do Linux, Solaris e OpenBSD são imunes como zombies, porém qualquer host pode ser um desino do scan. Uma maneira de determinar a vulnerabilidade do host é simplesmente tentar o Nmap Idlescan. O Nmap testará o zombie e reportará se ele é ou não confiável.

Realizar este scan é fácil. Simplesmente deve-se prover o hostname do zombie para a opção -sI e o Nmap fará o resto. Aqui está um exemplo rápido: 

# nmap -P0 -p- -sI kiosk.adobe.com www.riaa.com
Starting nmap V. 3.10ALPHA3 ( insecure.org/nmap/ )
Idlescan using zombie kiosk.adobe.com (192.150.13.111:80); Class: Incremental
Interesting ports on 208.225.90.120:
(The 65522 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
25/tcp open smtp
80/tcp open http
111/tcp open sunrpc
135/tcp open loc-srv
443/tcp open https
1027/tcp open IIS
1030/tcp open iad1
2306/tcp open unknown
5631/tcp open pcanywheredata
7937/tcp open unknown
7938/tcp open unknown
36890/tcp open unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 2594.472 seconds

Do scan acima, nós aprendemos que a RIAA não tem consciência da segurança (note as portas abertas do PC Anywhere, Portmapper, e Legato nsrexec). Desde que aparentemente eles não tenham um firewall, tão pouco terão um IDS. Porém se tiverem, ele irá acusar 'kiosk.adobe.com' como o culpado do scan. A opção -P0 previne o Nmap de enviar um ping inicial à máquina RIAA. Isto degrada a performance do scan (menos informações de tempo disponíveis), porém assegura que nenhum pacote será enviado ao destino do seu IP real. Este scan levou um longo tempo porque todas 65535 portas foram varridas -- omita a opção "-p-" se você deseja que sejam usadas apenas as portas conhecidas e as de 1-1024. Esteja certo de encontrar seu próprio zombie -- kiosk não é muito confiável e poderá desaparecer ou ser monitorada de perto.

Defesas

Felizmente, exsitem várias defesas que podem ser aplicadas para preventir maioria dos ataques IPID:

Administradores de rede:

  • Configure seu firewall/roteadores de borda para negar pacotes de entrada com origem estranha (ex. que podem parecer vir de máquinas de dentro de sua rede, IPs reservados como 10.x.x.x ou 192.168.x.x, localhosts IPs 127.x.x.x, etc. Qualquer bom guia de firewall provê mais detalhes nestas regras essenciais.
  • As regras de firewall que mantém registro do estado das conexões - Stateful firewalls - podem também ajudar contra este tipo de ataques. Garanta que seu firewall ofereça esta característica e que esteja habilitada.
  • Tente rodar sistemas operacionais com seqüências de IP ID menos previsíveis, como versões recentes do OpenBSD, Solaris ou Linux. Embora stes sistemas operacionais sejam imunes à zombies utilizados com a versão recente do Nmap, eles podem não conseguir parar com todos ataques IPID. Maiores investigações são necessárias.
  • Implemente filtro de pacotes de saída para prevenir que pacotes forjados saiam de sua rede. Isto previne que empregados/estudantes possam usar tais tipos de ataque.
Provedores de Internet (ISPs)
  • A mais importante proteção que os ISPs podem oferecer é utilizar filtros de saída para previnir pacotes forjados de sairem de sua rede. Isto previne os usuários de executarem muitos tipos de ataques e também previne o Idlescan. Além de ajudar a Internet, filtros de saída podem poupar custos substanciais em investigações de ataques com IP forjado.
Vendedores de SO
  • Uma boa abordagem é usar uma seqüência IPID para cada conexão. Solaris faz isso, e limita serveramente a informação que atacantes podem obter sobre outras conexões. Linux 2.4 também usa valores de IPID por conexão (see net/ipv4/inetpeer.c). Adicionalmente, o Linux 2.4 zera o campo IPID dos pacotes com o bit DF (não fragmente) setado. Depois de tudo, a desfragmentação do IP é o único uso crítico do campo ID. Outra abordagem (usada pelo OpenBSD), é a propriedade aleatória das seqüências IPID. Isto é difícil de acertar -- deve-se assegurar que a seqüência não repita e que números individuais não sejam usados 2 vezes em um curto período de tempo.
Desafios do Idlescan

Eu ia descutir sobre desafios da implementação em programar Idlescanners rápidos e precisos. Entretanto, poucos de vocês estão fazendo isso, e os que estão fazendo, podem ler o código fonte do Nmap e outros scanners. Então eu irei citar alguns pontos importantes. Esta seção também incluí alguns desafios encontrados por usuários de ferramentas.

  • Desempenho -- varrer uma porta por vez (como no diagrama acima) é horrívelmente lento para milhares de portas. Nmap contorna isso enviando mais de 100 checagens em paralelo. Normalmente, todas portas irão estar fechadas se o IPID do zombie não for incrementado. Se o Nmap encontrar que o IPID incrementa, então ele limitar-se-á à busca de portas abertas usando uma abordagem de pesquisa binária.
  • Hosts não ociosos -- Idlescan funciona contando o número de pacotes enviados por um zombie e assumindo que estes pacotes são respostas aos pacotes originados do seu destino. Portanto, pacotes externos enviados por um zombie não ocioso causa uma confusão significativa. O Nmap tenta contornar este problema com retransmissão de checagens e outras técnicas para detectar resultados falsos. Por exemplo, Nmap conhece algo que é errado se ele checa 6 portas e o IPID incrementa 10 ou 20. Nmap também ajusta seu tempo de paralelismo para compensar hosts que estão ligeiramente ativos ou que descartam pacotes quando eles são detectados. Entretanto, o Nmap não será confiável com zombies altamente ativos. Uma técnica para manusear zombies altamente ativos é enviar um grande número (dezenas ou centenas) de checagens para cada porta. Esta técnica de "força bruta" pode esconder uma pequena quantidade de tráfego chamado "ruído branco". Infelizmente, o custo de disto é a largura de banda significante, scans lentos e a possibilidade de inundar (Syn flood) seu destino. Thomas Olofsson demonstrou uma ferramente para fazer isso em sua apresentação para o 2001 Black Hat Briefings. Sua (Powerpoint) apresentação de slides está disponível aqui.
  • Filtros de saída -- e você não pode forjar pacotes po causa de um filtro de saída do seu ISP, tente um novo ISP ou (para usuários avançados), um túnel IP. Você pode tentar também enviar de outra máquina da sua mesma rede (menos provável de estar filtrada).
  • Zombies imunes -- Alguns hosts não funcionarão como zombies por causa de um tráfego substancial ou por causa de um sistema operacional imune. Na maioria dos casos, pode-se simplesmente utilizar um zombie diferente.
Mais diversão com previsão de IPID

Enquanto este artigo é focado na utilização de seqüenciais IPID previsíveis para varredura de portas, há muitos outras maneiras de explorar esta informação. Aqui está uma breve lista:

Links Relacionados
  • Nmap, que agora incluí um Idlescan, está disponível em: http://nmap.org/
  • A técnica básica de scan por IPID foi inventada por Antirez (Salvator Sanfilippo). Sua página está em: http://www.kyuzz.org/antirez/.
  • Antirez também desenvolveu sua excelente ferramenta Hping , que é tremendamente útil para testes baixo-nível de IPID.
  • Liquidk postou uma PoC (prova-de-conceito) de um scaner IPID e cunhou o termo "Idlescan" em 1999. A url para este post não mais funciona, porém o fonte está disponível aqui.
  • Thomas Olofsson escreveu e demonstrou uma ferramenta de scan IPID no 2001 Black Hat Briefings. Sua (powerpoint) apresentação de slides está disponível aqui e proporciona um bom apanhado sobre a técnica básica. Como mecionado antes neste artigo, sua ferramenta é preferível ao Nmap em casos onde o "Idle zombie host" não está realmente ocioso (Idle). Infelizmente, eu não tenho uma URL funcionando para esta ferramenta.