La détection de services avec nmap pourrait s’arrêter à simplement déterminer quels ports sont ouverts, sur quel protocole et se contenter d’énoncer les services standards sur ces ports (21 FTP, 22 SSH, 23 TELNET, …). Inopinément, cette méthode n’est pas très utile puisqu’un rien ne permet de déterminer avec un simple numéro de port que le service qui fonctionne dessus est bien celui prévu par les standards. Ça serait passé à côté de beaucoup d’information dans le cadre d’une cartographie réseau qui vise à découvrir les vulnérabilités de celui-ci. Il faut donc, comme pour la découverte des OS, réaliser une empreinte plus précise à l’aide de requêtes spécifiques. Pour cela, on peut retrouver la base de données utilisée par nmap sur KALI01 au chemin : /usr/share/nmap/nmap-service-probes
Voici un exemple de requête pour la découverte de service par nmap:
# DNS Server status request: http://www.rfc-editor.org/rfc/rfc1035.txt
##############################NEXT PROBE##############################
Probe UDP DNSStatusRequest q|\0\0\x10\0\0\0\0\0\0\0\0\0|
rarity 5
ports 53,69,135,1761
# Note when generating match lines - TCP DNS responses have two bytes at the beginning
# of the response that the UDP doesn't, otherwise they are the same. Account for this
# in the regex so that a matchline will work for both.
# Matches weird txids in bytes 0,1 (UDP) or 2,3 (TCP), we sent txid 0
# the \x0_, \x8_, \x9_ below accounts for recursion / authenticated data flags
softmatch domain m|^(?:..)?..\x90[\x01\x81\x91]\0\0\0\0\0\0\0\0$| i/generic dns response: FORMERR/
softmatch domain m|^(?:..)?..\x90[\x04\x84\x94]\0\0\0\0\0\0\0\0$| i/generic dns response: NOTIMP/
softmatch domain m|^(?:..)?..\x90[\x05\x85\x95]\0\0\0\0\0\0\0\0$| i/generic dns response: REFUSED/
# Responds with an A record for itself?
match domain m|^.{4,6}\x84\0\0\x01\0\x01\0\0\0\0[^\0]+\0\0\x01\0\x01[^\0]+\0\0\x01\0\x01\0\0\0\x1e\0\x04....$|s p/Incapsula WAF DNS/
match iodine m|^\x80\xa7\x84\0\0\x01\0\x01\0\0\0\0.*\0\0\x0a\0\x01\xc0\x0c\0\n\0\x01\0\0\0\0\0\x05BADIP$| p/iodine IP-over-DNS tunnel/ cpe:/a:kryo:iodine/
# This one below came from 2 tested Windows XP boxes
match msrpc m|^\x04\x06\0\0\x10\0\0\0\0\0\0\0|
match netprobe m|^\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0$| p/Mega System Technologies NetProbe Lite environmental sensor/ d/specialized/
match tftp m|^\0\x05\0\x02\0The IP address is not in the range of allowable addresses\.\0| p/SolarWinds tftpd/ i/IP disallowed/ o/Windows/ cpe:/a:solarwinds:tftp_server/ cpe:/o:microsoft:windows/a
match tftp m|^\0\x05\0\0Invalid TFTP Opcode| p/Cisco tftpd/ cpe:/a:cisco:tftp_server/
match tftp m|^\0\x05\0\x04Illegal TFTP operation\0| p/Plan 9 tftpd/ o/Plan 9/ cpe:/o:belllabs:plan_9/a
match tftp m|^\0\x05\0\x04Error: Illegal TFTP Operation\0\0\0\0\0| p/Zoom X5 ADSL modem tftpd/ d/broadband router/ cpe:/h:zoom:x5/a
match tftp m|^\0\x05\0\x04Illegal operation\0$| p/Cisco router tftpd/ d/router/ o/IOS/ cpe:/a:cisco:tftp_server/ cpe:/o:cisco:ios/a
match tftp m|^\0\x05\0\x04Illegal operation error\.\0$| p/Microsoft Windows Deployment Services tftpd/ o/Windows/ cpe:/o:microsoft:windows/
# version 10.9.0.25
match tftp m|^\0\x05\0\x04Unknown operatation code: 0 received from [\d.]+:\d+\0| p/SolarWinds Free tftpd/ cpe:/a:solarwinds:tftp_server/
# Brother MFC-9340CDW
match tftp m|^\0\x05\0\x04illegal \(unrecognized\) tftp operation\0$| p/Brother printer tftpd/ d/printer/
# HP IMC 7.1
match tftp m|^\0\x05\0\0Not defined, see error message\(if any\)\.\0| p/HP Intelligent Management Center tftpd/ cpe:/a:hp:intelligent_management_center/
match tftp m|^\0\x05\0\x05Unknown transfer ID\0| p/TFTP Server SP/ o/Windows/ cpe:/a:tftp:tftp_server_sp/ cpe:/o:microsoft:windows/a
# TFTP error
softmatch tftp m|^\0\x05\0[\0-\x07][^\0]+\0$|
match landesk-rc m|^\0\0\0\0USER\x01\0\x10\0\x08\0:\xd0\x08\0:\xd0\x01\x01\.\0O\0\x03\0T\0\xff\xff\0\0\0\xfd\0\0\0\0\0\0\x02\0\0\0LANDeskWorkgroup Manager ver ([\d.]+)\0| p/LANDesk Workgroup Manager/ v/$1/ o/Windows/ cpe:/o:microsoft:windows/a
Probe UDP DNSStatusRequest q|\0\0\x10\0\0\0\0\0\0\0\0\0|
La ligne Probe permet l’envoie d’une requête spécifique pour la découverte de nombreux services. Une ligne Probe se compose de la manière suivante :
Probe <protocol> <probename> <probestring>
rarity 5
La rareté est un indicateur compris entre 1 et 9 inclus, qui indique le niveau auquel le probe est susceptible de renvoyer une réponse inexploitable. Plus l’indicateur est proche de 9, moins il est susceptible de renvoyer une réponse intéressante.
ports 53,69,135,1761
La ligne ports indique les ports où le service testé se trouve généralement.
match landesk-rc m|^\0\0\0\0USER\x01\0\x10\0\x08\0:\xd0\x08\0:\xd0\x01\x01\.\0O\0\x03\0T\0\xff\xff\0\0\0\xfd\0\0\0\0\0\0\x02\0\0\0LANDeskWorkgroup Manager ver ([\d.]+)\0| p/LANDesk Workgroup Manager/ v/$1/ o/Windows/ cpe:/o:microsoft:windows/a
Le mot clé match permet de capter un message répondant au probe. Celui-ci est composé : match <service> <pattern> [<versioninfo>]
Il peut y avoir plusieurs directives match par probe. Lorsqu’un match est réalisé, l’analyse du probe s’arrête.
softmatch tftp m|^\0\x05\0[\0-\x07][^\0]+\0$|
Une directive softmatch est similaire en tous points à une directive match à l’exception près que les matchs continue lorsque le softmatch est validé. Cela permet de ne pas interrompre l’analyse sur des informations trop vagues concernant le service.
Nmap regarde si des ports ont été exclus par l’intermédiaire de la directive Exclude <port specification>.
S’il s’agit d’un port TCP, nmap s’y connecte. Si la connexion est un succès et que le port était à l’état open|filtred, il est passé à open.
Une fois la connexion TCP établie, nmap écoute pendant environ 5 secondes. Plusieurs services usuels vont eux-mêmes envoyer un message de bienvenue. C’est ce qu’on appelle un “NULL probe”, car nmap n’envoie aucun paquet, et se contente juste d’écouter le service. Le message de bienvenue est par la suite comparé à une base de données de plus de 3000 “NULL probe”. Si le service est identifié suite à cela, l’analyse du port est clôturée. Dans certains cas, nmap obtient un soft match sans information de version. Dans ce cas-là , il continue l’analyse en envoyant de nouveaux probes appropriés au service reconnu par le soft match.
Si la recherche du service n’a pas été concluante jusque-là , nmap continue avec des probes UDP et probes TCP non nuls. nmap lance tous les probes concernés par le port actuellement scanné. Comme décrit précédemment, un probe possède une string qu’il envoie à ça cible et tente de matcher la réponse de la cible grâce aux directives match, softmatch. Si jamais une réponse d’un port UDP open|filtered est reçu, l’état est passé à open.
Dans la plupart des cas, le probe NULL ou le probe dédié au port scanné reconnaît le service. Mais si aucun match n’est trouvé, nmap va devoir exécuter d’autres probes séquentiellement. Pour chaque probe TCP, une nouvelle connexion est ouverte pour éviter que d’autres probes TCP puissent interférer avec les résultats. Ce scénario peut être très long, car à chaque fois nmap va écouter la connexion TCP pendant 5 secondes après sa mise en place. nmap utilise cependant des mécanismes pour accélérer le scan :
nmap s’appuie sur des probes génériques qui permettent la détection de plusieurs services d’un seul coup. Par exemple, le probe GenericLines envoie deux lignes vides \r\n\r\n permet de détecter des services comme FTP ou Postgres.
Si une directive softmatch est reconnue, nmap utilisera les probes qui peuvent potentiellement reconnaître ce service.
Afin de hiérarchiser les probes, nmap s’appuie sur l’attribut rarity pour essayer en premier lieu les probes qui ont une forte probabilité de donner des résultats. Cette limite peut être contournée grâce au flag de commande nmap: --version-intensity 9 et --version-all
Un des probes vérifie si le port fonctionne sur SSL / TLS. Si c’est le cas, nmap se reconnecte via SSL / TLS et redémarre le scan du port pour déterminer quel service écoute derrière l’encryption.
Un autre probe générique identifie les services RPC (Remote Procedure Call) qui est un protocol de communication pour communiquer à des processus via le réseau. Lorsqu’un service basé sur RPC est trouvé, le RPC grinder de nmap est lancé pour brute force le programme RPC number/name et les versions supportées.
Le résultat des étapes précédemment décrites est renvoyé à l’utilisateur.