Idle scan
Un idle scan est une méthode de balayage de port TCP qui, grâce à des utilitaires tels que Nmap et Hping, utilise l'envoi de paquets possédant une adresse IP usurpée.
Cet exploit complexe permet à la fois de balayer les ports d'une machine ainsi que de mettre en évidence les liaisons de confiance (s'appuyant sur les adresses IP) entre les machines. L'attaque consiste en l'envoi de paquets forgés vers une machine donnée – la cible – dans le but d'obtenir des informations à propos d'elle mais via une autre machine – le zombi. Découvert par Salvatore Sanfilippo (aussi connu sous le nom de « Antirez ») en 1998[1], l'idle scan a été utilisé par de nombreux pirates lors de la préparation d'une attaque afin d'identifier discrètement les ports ouverts sur une machine cible.
Bien qu'il ait été nommé « dumb scan » à l'origine, le terme « idle scan » a été inventé en 1999, après la publication d'une preuve de concept nommée « idlescan », par Filipe Almeida (aussi connu sous le pseudonyme de « LiquidK »). Ce type de balayage de ports peut également être appelé « zombi scan ». Toutes les appellations sont dues à la nature de l'une des machines impliquées dans l'attaque.
Principe[modifier | modifier le code]
L'idle scan exploite le fait que l'on peut, sous certaines conditions, prédire les numéros d'identification IP (IPID). L'attaquant doit d'abord rechercher une machine avec une séquence d'IPID prévisible. Par exemple, le numéro d'identification sera incrémenté de 1 à chaque fois. Les dernières versions de Linux, Solaris et OpenBSD ne sont pas des cibles appropriées puisque les algorithmes de génération d'IPID ont été corrigés[2]. Les machines choisies pour être utilisées à ce niveau sont parfois appelées « zombis ». Une fois qu'une machine zombi a été trouvée, la première étape est de déterminer le numéro IPID actuel de la machine : en envoyant un pacquet SYN/ACK au zombi, le pirate recevra un paquet RST portant le numéro de séquence.
L'étape suivante consiste en l'envoi d'un paquet SYN à la machine cible, en usurpant l'adresse IP du zombi. Si le port de la machine cible est ouvert, celle-ci répondra au zombi avec un paquet SYN/ACK. Le zombi va donc envoyer un paquet RST à la cible car il n'est pas réellement l'émetteur du premier paquet SYN. Puisque la machine zombi a dû envoyer le paquet RST, elle incrémente son IPID. C'est ce qui permet à l'attaquant de découvrir si le port de la cible est ouvert. La dernière étape est donc la vérification de l'IPID, en envoyant à nouveau un paquet SYN/ACK au zombi.
Si l'IPID contenu dans le paquet RST reçu en réponse a été incrémenté deux fois, on est certain que le port cible est ouvert. En revanche si l'IPID n'est incrémenté qu'une fois, alors l'attaquant saura que ce port est fermé ou filtré.
Démonstration avec Hping[modifier | modifier le code]
La méthode de Hping pour l'idle scan permet d'observer un exemple de la réalisation de ce type de scan à un bas niveau. Dans cet exemple, l'hôte cible (172.16.0.100) va être scanné en utilisant un hôte idle (172.16.0.105). Un port ouvert et un port fermé seront testés pour voir comment se déroule chaque scénario.
Premièrement, pour établir que l'hôte idle est bien un zombi, il faut envoyer des paquets en utilisant hping2 et observer si les numéros de séquence sont bien incrémentés de 1 à chaque fois. Si l'évolution des numéros de séquence est aléatoire, alors l'hôte n'est pas un zombi potentiel.
[root@localhost hping2-rc3]# ./hping2 -S 172.16.0.105 HPING 172.16.0.105 (eth0 172.16.0.105): S set, 40 headers + 0 data bytes len=46 ip=172.16.0.105 ttl=128 id=1371 sport=0 flags=RA seq=0 win=0 rtt=0.3 ms len=46 ip=172.16.0.105 ttl=128 id=1372 sport=0 flags=RA seq=1 win=0 rtt=0.2 ms len=46 ip=172.16.0.105 ttl=128 id=1373 sport=0 flags=RA seq=2 win=0 rtt=0.3 ms len=46 ip=172.16.0.105 ttl=128 id=1374 sport=0 flags=RA seq=3 win=0 rtt=0.2 ms len=46 ip=172.16.0.105 ttl=128 id=1375 sport=0 flags=RA seq=4 win=0 rtt=0.2 ms len=46 ip=172.16.0.105 ttl=128 id=1376 sport=0 flags=RA seq=5 win=0 rtt=0.2 ms len=46 ip=172.16.0.105 ttl=128 id=1377 sport=0 flags=RA seq=6 win=0 rtt=0.2 ms len=46 ip=172.16.0.105 ttl=128 id=1378 sport=0 flags=RA seq=7 win=0 rtt=0.2 ms len=46 ip=172.16.0.105 ttl=128 id=1379 sport=0 flags=RA seq=8 win=0 rtt=0.4 ms
Port ouvert[modifier | modifier le code]
Pour tester un port de la machine cible, on envoie un paquet usurpant l'adresse IP du zombi. Dans ce cas le port 22 (ssh).
# hping2 --spoof 172.16.0.105 -S 172.16.0.100 -p 22 -c 1 HPING 172.16.0.100 (eth0 172.16.0.100): S set, 40 headers + 0 data bytes --- 172.16.0.100 hping statistic --- 1 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms
Puisque l'adresse du paquet a été usurpée, aucune réponse n'est reçue et hping signale que 100 % des paquets ont été perdus. La cible a directement répondu à l'hôte idle avec un paquet SYN/ACK. Maintenant, il faut observer l'IPID du zombi pour voir s'il a été incrémenté.
# hping2 -S 172.16.0.105 -p 445 -c 1 HPING 172.16.0.105 (eth0 172.16.0.105): S set, 40 headers + 0 data bytes len=46 ip=172.16.0.105 ttl=128 DF id=1381 sport=445 flags=SA seq=0 win=64320 rtt=0.3 ms --- 172.16.0.105 hping statistic --- 1 packets tramitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.3/0.3/0.3 ms
Notez que l'IPID du proxy a augmenté de id=1379 à id=1381. Le paquet numéro 1380 a été utilisé quand le zombi a répondu au paquet SYN/ACK de la cible par un paquet RST.
Port fermé[modifier | modifier le code]
Maintenant, on utilise le même procédé sur un port qui est probablement fermé. Ici le port 23 (telnet).
Il est nécessaire de vérifier l'IPID actuel du zombi avant de commencer.
# hping2 -S 172.16.0.105 -p 445 -c 1 HPING 172.16.0.105 (eth0 172.16.0.105): S set, 40 headers + 0 data bytes len=46 ip=172.16.0.105 ttl=128 DF id=1382 sport=445 flags=SA seq=0 win=64320 rtt=2.1 ms --- 172.16.0.105 hping statistic --- 1 packets tramitted, 1 packets received, 0% packet loss round-trip min/avg/max = 2.1/2.1/2.1 ms
Puis, on envoie le paquet de test à la cible.
# hping2 --spoof 172.16.0.105 -S 172.16.0.100 -p 23 -c 1 HPING 172.16.0.100 (eth0 172.16.0.100): S set, 40 headers + 0 data bytes --- 172.16.0.100 hping statistic --- 1 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms
Et enfin on vérifie à nouveau l'IPID du zombi.
# hping2 -S 172.16.0.105 -p 445 -c 1 HPING 172.16.0.105 (eth0 172.16.0.105): S set, 40 headers + 0 data bytes len=46 ip=172.16.0.105 ttl=128 DF id=1383 sport=445 flags=SA seq=0 win=64320 rtt=0.3 ms --- 172.16.0.105 hping statistic --- 1 packets tramitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.3/0.3/0.3 ms
Remarquez que cette fois l'IPID a augmenté seulement d'une unité (de id=1382 à id=1383) car le port était fermé. Lorsque le paquet avec l'IP usurpée a été envoyé à la cible, celle-ci a répondu au zombi par un paquet RST. L'hôte idle n'a donc pas répondu à ce paquet et son IPID a été incrémenté lors de sa réponse à l'attaquant.
Démonstration avec Nmap[modifier | modifier le code]
La première chose à faire est de trouver une machine zombi sur le réseau.
# nmap -sP 192.168.1.0/24
Cette commande fait effectuer à Nmap un balayage d'une plage d'adresse IP et montre les hôtes qui sont en ligne.
Une fois le zombi trouvé, il faut envoyer les paquets avec l'adresse IP usurpée :
# nmap -P0 -p <port> -sI <zombi IP> <target IP>
Efficacité[modifier | modifier le code]
Toutes les versions récentes des systèmes d'exploitation (par exemple Windows Vista et successeurs) ne sont plus vulnérables à cette attaque, ne sont plus susceptibles de servir de machine zombie[3].
Lorsqu'un scan est réussi, il n'y a aucune trace de l'adresse IP de l'attaquant dans le pare-feu de la cible ou dans le log du système de détection d'intrusion.
Le scan étant effectué depuis la machine zombi, cela offre la possibilité de contourner un pare-feu, puisque le zombi peut posséder plus de droits que la machine de l'attaquant.
Notes et références[modifier | modifier le code]
- (en) http://seclists.org/bugtraq/1998/Dec/79
- (en) http://seclists.org/bugtraq/1999/Oct/263
- (en) « Idle Scan », sur primidi.com, (consulté le ).
