HSC
Cabinet de consultants en sécurité informatique depuis 1989 - Spécialisé sur Unix, Windows, TCP/IP et Internet
Mode texte : accès au contenu de la page
Hervé Schauer Consultants
Vous êtes ici : Accueil > Ressources > Brèves > L'option cachée de nmap
Accéder au : Site HSC des formations
Télécharger le catalogue des formations
Recherche :  
English version
   Services   
o Domaines de compétences
o Conseil & Expertise
o Prestations ISO 27001
o Audit & Évaluation
o Tests d'intrusion
o Tests de vulnérabilités (TSAR)
o Analyse Forensique
o Certification ARJEL
o Formations
o E-learning
   Conférences   
o Agenda
o Interventions passées
o Tutoriels
   Ressources   
o Index thématique
o Brèves
o Présentations
o Cours
o Articles
o Outils (téléchargement)
o Veille en vulnérabilité
   Société   
o Hervé Schauer
o Equipe
o Offres d'emploi
o Références
o Historique
o Partenariats
o Associations
   Presse et
 communication
 
 
o Newsletter HSC
o Bulletin juridique HSC
o Revue de presse
o Communiqués de presse
o Publications
   Contacts   
o Coordonnées
o Requêtes particulières
o Accès à nos locaux
o Hôtels proches de nos locaux
|>|L'option cachée de nmap  

par Denis Ducamp (27/12/2000)



Cet article montre encore une fois que la sécurité par l'obscurité est
inutile. Ceci sera illustré au travers de l'utilisation d'une option cachée
de nmap depuis la version 2.54BETA3.



nmap possède l'option -O qui permet de déterminer le type de système
d'exploitation utilisé par un système distant (stack-fingerprint en
anglais). Celle-ci fonctionne en envoyant des paquets TCP avec des ensembles
anormaux d'options IP et en examinant les réponses reçues.

Malheureusement il peut être assez simple de tromper nmap soit en changeant
quelques options dans la pile TCP/IP sur certains systèmes, soit en
renvoyant des paquets perturbateurs lorsqu'un scan nmap est détecté (e.g.
les réponses actives - FlexResp - de snort).

Les tests suivants ont été faits sur une machine qui a généré l'évènement
suivant dans un journal d'apache :

192.168.148.31 - - [27/Dec/2000:11:11:36 +0100] www.groar.org:80 "GET /~ducamp/theycame.jpg HTTP/1.0" 200 109504 "-" "Mozilla/4.76 [en] (X11; U; Linux 2.2.12 i386; Nav)" - -/-

D'après cette entrée, il s'agirait donc d'une machine sous Linux 2.2.12, ce
qui peut généralement être vérifié par quelques tests simples au niveau
applicatif :

# telnet 192.168.148.31 22
Trying 192.168.148.31...
Connected to 192.168.148.31.
Escape character is '^]'.
SSH-1.99-OpenSSH_2.3.0
quit
Protocol mismatch.
Connection closed by foreign host.

# telnet 192.168.148.31 25
Trying 192.168.148.31...
Connected to 192.168.148.31.
Escape character is '^]'.
220 kisuije ESMTP InterScan VirusWall NT ESMTP 3.24 (build 01/19/2000)
quit
221 Bye
Connection closed by foreign host.



Si le premier test peut confirmer ce qui est pressenti, le second le
contredit. Il est alors possible d'utiliser nmap avec l'option -O pour
regarder comment la pile TCP/IP réagit et l'identifier :

# nmap -sS -O -p 19-26 -n -P0 192.168.148.31

Starting nmap V. 2.54BETA5 ( www.insecure.org/nmap/ )
Interesting ports on  (192.168.148.31):
(The 6 ports scanned but not shown below are in state: closed)
Port       State       Service
22/tcp     open        ssh                     
25/tcp     open        smtp                    

TCP Sequence Prediction: Class=random positive increments
                         Difficulty=35202 (Worthy challenge)
No exact OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=2.54BETA7%P=i686-pc-linux-gnu%D=12/28%Time=3A4B1680%O=22%C=19)
TSeq(Class=RI%gcd=1%SI=5E8C)
TSeq(Class=RI%gcd=1%SI=4FFB)
TSeq(Class=RI%gcd=1%SI=8982)
T1(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=M)
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=N)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=4801%RID=E%RIPCK=F%UCK=E%ULEN=134%DAT=E)



Malheureusement ici nmap n'a pas été capable d'obtenir le type de système
d'exploitation car l'ensemble de réponses reçu ne correspond pas à une
entrée présente dans sa base (nmap-os-fingerprints).

Il est alors possible d'utiliser l'option --osscan_guess pour obtenir les
entrées ayant le plus de similitudes avec les paquets reçus :

# nmap --osscan_guess -sS -O -p 19-26 -n -P0 192.168.148.31

Starting nmap V. 2.54BETA5 ( www.insecure.org/nmap/ )
Interesting ports on  (192.168.148.31):
(The 6 ports scanned but not shown below are in state: closed)
Port       State       Service
22/tcp     open        ssh                     
25/tcp     open        smtp                    

TCP Sequence Prediction: Class=random positive increments
                         Difficulty=2830 (Medium)
Aggressive OS guesses: FreeBSD 3.2-STABLE (91%), Microsoft NT 4.0 Server SP5
+ 2047 Hotfixes (90%), Windows 2000 RC1 through final release (90%), Windows
2000 Professional, Build 2128 (90%), Windows Millenium Edition v4.90.3000
(90%), HP-UX 10.20 (89%), Cisco IOS 12.0(3.3)S (perhaps a 7200) (88%),
F5labs Big/IP HA TCP/IP Load Balancer (BSDI kernel/x86) (88%)
No exact OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=2.54BETA7%P=i686-pc-linux-gnu%D=12/28%Time=3A4B1699%O=22%C=19)
TSeq(Class=RI%gcd=1%SI=4BA6)
TSeq(Class=RI%gcd=1%SI=C2E9)
TSeq(Class=RI%gcd=2%SI=B0E)
T1(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=M)
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=N)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=4801%RID=E%RIPCK=F%UCK=E%ULEN=134%DAT=E)



Grâce à hping il est possible d'éliminer certaines solutions :

# hping -r -S -p 23 kisuije
eth0 default routing interface selected (according to /proc)
HPING kisuije (eth0 192.168.148.31): S set, 40 headers + 0 data bytes
46 bytes from 192.168.148.31: flags=RA seq=0 ttl=64 id=29116 win=0 rtt=0.6 ms
46 bytes from 192.168.148.31: flags=RA seq=1 ttl=64 id=+38104 win=0 rtt=0.6 ms
46 bytes from 192.168.148.31: flags=RA seq=2 ttl=64 id=+4871 win=0 rtt=0.6 ms
46 bytes from 192.168.148.31: flags=RA seq=3 ttl=64 id=+59743 win=0 rtt=0.6 ms
46 bytes from 192.168.148.31: flags=RA seq=4 ttl=64 id=+61452 win=0 rtt=0.6 ms

--- kisuije hping statistic ---
5 packets tramitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.6/0.6/0.6 ms

Ce test sur un port fermé a montré que les numéros id ne sont pas consécutifs.



# hping -r -S -p 23 -W kisuije
eth0 default routing interface selected (according to /proc)
HPING kisuije (eth0 192.168.148.31): S set, 40 headers + 0 data bytes
46 bytes from 192.168.148.31: flags=RA seq=0 ttl=64 id=15985 win=0 rtt=0.6 ms
46 bytes from 192.168.148.31: flags=RA seq=1 ttl=64 id=+61720 win=0 rtt=0.6 ms
46 bytes from 192.168.148.31: flags=RA seq=2 ttl=64 id=+38339 win=0 rtt=0.6 ms
46 bytes from 192.168.148.31: flags=RA seq=3 ttl=64 id=+8930 win=0 rtt=0.6 ms
46 bytes from 192.168.148.31: flags=RA seq=4 ttl=64 id=+20405 win=0 rtt=0.6 ms

--- kisuije hping statistic ---
5 packets tramitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.6/0.6/0.6 ms

Ce test avec l'option -W a montré qu'il ne s'agit pas d'un système windows
puisque les incréments sont aléatoires.



# hping -r -S -p 22 kisuije
eth0 default routing interface selected (according to /proc)
HPING kisuije (eth0 192.168.148.31): S set, 40 headers + 0 data bytes
46 bytes from 192.168.148.31: flags=SA seq=0 ttl=64 id=22094 win=16384 rtt=0.6 ms
46 bytes from 192.168.148.31: flags=SA seq=1 ttl=64 id=+1 win=16384 rtt=0.8 ms
46 bytes from 192.168.148.31: flags=SA seq=2 ttl=64 id=+1 win=16384 rtt=0.7 ms
46 bytes from 192.168.148.31: flags=SA seq=3 ttl=64 id=+1 win=16384 rtt=0.8 ms
46 bytes from 192.168.148.31: flags=SA seq=4 ttl=64 id=+1 win=16384 rtt=0.7 ms

--- kisuije hping statistic ---
5 packets tramitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.6/0.7/0.8 ms

Ce test montre bien que sur un port ouvert, les paquets retournés possèdent
des numéros id consécutifs, il est donc possible d'imaginer qu'il s'agit
d'un système Unix avec un filtre IP évolué.



Il s'agit en fait d'un système sous FreeBSD 5.0-CURRENT (c'est pourquoi nmap
ne le possède pas encore dans sa base) utilisant ipfilter pour effectuer du
filtrage IP, notamment configuré pour répondre à la place de la pile TCP/IP
sur les ports fermés :

block return-icmp(port-unr) in log proto udp from any to any
block return-rst in log proto tcp from any to any



Encore une fois, cela montre que la sécurité par l'obscurité ne sert à rien
si ce n'est de ne retarder que de quelques minutes les crackers.



Dernière modification le 12 novembre 2003 à 13:55:00 CET - webmaster@hsc.fr
Mentions légales - Informations sur ce serveur - © 1989-2013 Hervé Schauer Consultants