Idlescan

Description de l'idlescan

Dans l'établissement standard d'une connexion (SYN – SYN/ACK – ACK), les paquets transmis sont accompagnés d'un numéro d'identification appelé IPID. Ce dernier est incrémenté régulièrement sur certains systèmes (en particulier Windows).
La technique consiste à exploiter cette faille, afin de déterminer, en fonction de l'incrémentation de l'IPID, l'état d'un port. La spécificité de cette attaque réside dans le fait que l'attaquant utilise un hôte zombie afin de ne pas apparaître dans les fichier journaux de l'hôte scanné.

Etapes de l'attaque

Les étapes du schéma sont détaillées ci-dessous.
     1. L'attaquant récupère l'IPID initial de l'hôte zombie (avec hping par exemple).
     2. L'attaquant envoie des paquets avec l'indicateur SYN activé (première étape d'une connexion) à l'hôte distant, en usurpant l'adresse IP du zombie. Ainsi, l'hôte scanné considère que le paquet provient de l'adresse IP du zombie.
     3. Si le port scanné est fermé, l'hôte scanné renverra à zombie un paquet avec l'indicateur RST activé (deuxième étape de l'établissement d'une connexion). Dans ce cas, le zombie, n'étant pas à l'origine du paquet SYN de l'étape 2, n'établira pas de relation d'état, et ne répondra pas (respect de la RFC793). Il n'y a donc pas d'incrémentation de l'IPID.
3 bis. Si le port scanné est ouvert, l'hôte scanné reverra à zombie un paquet avec les indicateurs SYN et ACK actifs (deuxième étape d'une connexion). Dans ce cas, le zombie répondra par l'émission d'un paquet RST vers l'hôte scanné (respect de la RFC793). L'émission de ce paquet provoquera l'incrémentation de l'IPID.
     4. L'attaquant réinterroge l'IPID du zombie afin d'analyser son incrémentation. Si celle-ci est incrémentée de 1, cela signifie que le zombie n'a pas transmis de paquet mais a juste reçu le RST de l'hôte scanné. En revanche, si l'IPID est incrémenté de 2, cela signifie que le port est ouvert (réception d'un paquet SYN/ACK émis par l'hôte scanné + réponse RST du zombie).

Cas pratiques

Le schéma d'étude proposé est le suivant :

+--------------+                      +-----------------+
| ATTAQUANT    | -------[2]---------> | HOTE SCANNE     |
| 192.168.1.10 |                      | 192.168.1.1     |
| Ubuntu 8.04  |                      | Debian Etch 4.0 |
+--------------+                      +-----------------+
      ^                                         ^
      |                                         |
      | [1]                                 [3] |
      | [4]         +--------------+            |
      +-----------> | ZOMBIE       | <----------+
                    | 192.168.1.12 |
                    | Windows 2000 |
                    +--------------+

Remarque : une sonde tcdump est placée sur l'hôte scanné (192.168.1.1)

Test manuel port ouvert (tcp/22)

Etape 1 (récupération de l'IPID du zombie)

$ sudo hping3 192.168.1.12
HPING 192.168.1.12 (wlan0 192.168.1.12): NO FLAGS are set, 40 headers + 0 data bytes
len=46 ip=192.168.1.12 ttl=128 id=45218 sport=0 flags=RA seq=0 win=0 rtt=9.0 ms
len=46 ip=192.168.1.12 ttl=128 id=45219 sport=0 flags=RA seq=1 win=0 rtt=1.4 ms
len=46 ip=192.168.1.12 ttl=128 id=45220 sport=0 flags=RA seq=2 win=0 rtt=1.6 ms
len=46 ip=192.168.1.12 ttl=128 id=45221 sport=0 flags=RA seq=3 win=0 rtt=1.2 ms
len=46 ip=192.168.1.12 ttl=128 id=45222 sport=0 flags=RA seq=4 win=0 rtt=2.1 ms
len=46 ip=192.168.1.12 ttl=128 id=45223 sport=0 flags=RA seq=5 win=0 rtt=3.7 ms
len=46 ip=192.168.1.12 ttl=128 id=45224 sport=0 flags=RA seq=6 win=0 rtt=1.2 ms
len=46 ip=192.168.1.12 ttl=128 id=45225 sport=0 flags=RA seq=7 win=0 rtt=1.5 ms
^C

Nous constatons que les IPID s'incrémentent régulièrement. Par ailleurs, le dernier IPID vaut 45225. Il sera notre référence pour l'analyse.

Etape 2 (envoi d'un paquet SYN sur le port 22)
Nous forgeons ici un paquet SYN sur le port 22/tcp à destination du 192.168.1.1, en se faisant passer pour le 192.168.1.12.

>>> a = IP(dst="192.168.1.1", src="192.168.1.12")/TCP(flags="S", dport=22)
>>> a.show()
###[ IP ]###
version= 4
ihl= 0
tos= 0x0
len= 0
id= 1
flags=
frag= 0
ttl= 64
proto= tcp
chksum= 0x0
src= 192.168.1.12
dst= 192.168.1.1
options= 
###[ TCP ]###
sport= ftp_data
dport= ssh
seq= 0
ack= 0
dataofs= 0
reserved= 0
flags= S
window= 8192
chksum= 0x0
urgptr= 0
options= {}

La commande suivante envoie le paquet forgé précédemment

>>> send(a)
.
Sent 1 packets.

Etape 4 (réinterrogation de l'IPID du zombie)

$ sudo hping3 192.168.1.12 -c 1
HPING 192.168.1.12 (wlan0 192.168.1.12): NO FLAGS are set, 40 headers + 0 data bytes
len=46 ip=192.168.1.12 ttl=128 id=45227 sport=0 flags=RA seq=0 win=0 rtt=1.3 ms

L'IPID vaut 45227. Au dernier relevé, il valait 45225. Il a donc augmenté de 2. Nous pouvons supposer que le port est ouvert. Effectivement, comme nous le constaterons dans les traces de l'hôte scanné, cela est du à la réponse « Reset » faite par le zombie à l'hôte scanné.

Analyse des traces de l'hôte scanné

$ tcpdump -nS -r idlescan.cap 'port 22'
reading from file idlescan.cap, link-type EN10MB (Ethernet)
13:31:30.038209 IP 192.168.1.12.20 > 192.168.1.1.22: S 0:0(0) win 8192
13:31:30.038362 IP 192.168.1.1.22 > 192.168.1.12.20: S 825401775:825401775(0) ack 1 win 5840 <mss 1460>
13:31:30.039779 IP 192.168.1.12.20 > 192.168.1.1.22: R 1:1(0) win 0

La seule adresse IP qui apparaît dans ces traces est 192.168.1.12, celle du zombie. Par ailleurs, nous pouvons constater les deux premières étapes de la connexion (SYN et SYN/ACK) ainsi que le Reset renvoyé par le zombie au serveur (car ce n'était pas lui qui était à l'origine de la demande de connexion, contrairement à ce qui a été retenu dans les traces de l'hôte scanné).

Test manuel port fermé (tcp/8080)

Etape 1 (récupération de l'IPID du zombie)

$ sudo hping3 192.168.1.12
HPING 192.168.1.12 (wlan0 192.168.1.12): NO FLAGS are set, 40 headers + 0 data bytes
len=46 ip=192.168.1.12 ttl=128 id=45276 sport=0 flags=RA seq=0 win=0 rtt=3.8 ms
len=46 ip=192.168.1.12 ttl=128 id=45277 sport=0 flags=RA seq=1 win=0 rtt=2.7 ms
len=46 ip=192.168.1.12 ttl=128 id=45278 sport=0 flags=RA seq=2 win=0 rtt=11.1 ms
len=46 ip=192.168.1.12 ttl=128 id=45279 sport=0 flags=RA seq=3 win=0 rtt=1.7 ms
len=46 ip=192.168.1.12 ttl=128 id=45280 sport=0 flags=RA seq=4 win=0 rtt=1.3 ms
^C

Nous prenons comme IPID de référence 45280.

Etape 2 (envoi d'un paquet SYN sur le port 8080)
Nous forgeons ici un paquet SYN sur le port 22/tcp à destination du 192.168.1.1, en se faisant passer pour le 192.168.1.12.

>>> a = IP(dst="192.168.1.1", src="192.168.1.12")/TCP(flags="S", dport=8080)
>>> a.summary()
'IP / TCP 192.168.1.12:ftp_data > 192.168.1.1:webcache S'
>>> send(a)
.
Sent 1 packets.

Etape 4 (réinterrogation de l'IPID du zombie)

$ sudo hping3 192.168.1.12
HPING 192.168.1.12 (wlan0 192.168.1.12): NO FLAGS are set, 40 headers + 0 data bytes
len=46 ip=192.168.1.12 ttl=128 id=45281 sport=0 flags=RA seq=0 win=0 rtt=1.5 ms

L'IPID vaut 45281 et n'indique aucun échange avec l'hôte scanné. Nous en déduisons que le port 8080 est fermé ou filtré.

Remarque : cette analyse ne nous permet pas de distinguer les ports fermés des ports filtrés. Effectivement, les résultats obtenus auraient été les mêmes dans le cas d'un port filtré.

Analyse des traces de l'hôte scanné

$ tcpdump -nS -r idlescan.cap 'port 8080'
14:02:54.788863 IP 192.168.1.12.20 > 192.168.1.1.8080: S 0:0(0) win 8192
14:02:54.788990 IP 192.168.1.1.8080 > 192.168.1.12.20: R 0:0(0) ack 1 win 0

La seule adresse IP qui apparaît dans ces traces est 192.168.1.12, celle du zombie. Par ailleurs, nous pouvons constater la première étape de la connexion (SYN) ainsi que le Reset renvoyé par le serveur au zombie.

Avec Nmap

$ sudo nmap -PN -p20-80 -sI 192.168.1.12 192.168.1.1
Starting Nmap 4.76 ( http://nmap.org ) at 2008-10-25 19:32 CEST
Idle scan using zombie 192.168.1.12 (192.168.1.12:80); Class: Incremental
Interesting ports on 192.168.1.1:
Not shown: 59 closed|filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
MAC Address: 00:50:8B:BB:F3:2E (Hewlett Packard)

Nmap done: 1 IP address (1 host up) scanned in 2.94 seconds

Remarques :

• L'option -PN permet d'éviter d'envoyer un ping initial à l'hôte scanné. Sans cette option, l'identité de l'attaquant est révélée. L'idle scan peut se révéler extrêmement long sans limitation de ports. C'est la raison pour laquelle le scan ci-dessus est limité aux ports 20 à 80.

Limitations sur l'efficacité de cette attaque

• Cette attaque nécessite que l'hôte zombie soit inactif, afin de préserver la cohérence de l'IPID récupéré initialement. En effet, les éventuels échanges de l'hôte zombie seront considérés comme des interférences et seront susceptibles de fausser les résultats obtenus.
• Par ailleurs, ce type d'attaque ne permet pas de distinguer les ports fermés des ports filtrés.