==Phrack Inc.==

            Volume 0x0b, Issue 0x39, Phile #0x07 of 0x12

|=---=[ ICMP based remote OS TCP/IP stack fingerprinting techniques ]=---=|
|=-----------------------------------------------------------------------=|
|=---------------=[ Ofir Arkin & Fyodor Yarochkin ]=---------------------=|
traduit de l'anglais par dzeta (dzeta@netcourrier.com) 

--[ICMP based fingerprinting approach]--

La prise d'empreinte d'OS basé sur TCP se fait un peu vieille et bien-
connu aujourd'hui, ici nous voudrions introduire une méthode alternative
pour determiner un OS a distance, basé sur des requetes ICMP recue depuis
l'hote distant. Certains niveaux d'exactitude ont été réalisées avec
différentes plateformes, ce qui, avec quelques systèmes ou classe de
plateforme (i.g. *Win) est significativement plus précis que ceux démontré
par la méthode de prise d'empreinte basé sur TCP.

Comme il est dit plus haut sur la méthode basée sur TCP, la prise
d'empreinte ICMP utilise plusieurs tests pour réussir un sondage de la
pile TCP/IP de l'OS, mais contrairement à la prise d'empreinte TCP, le
nombre de tests demandés pour identifier un OS peut varier de 1 à 4 (en
date actuelle de développement). 

La méthode de prise d'empreinte ICMP sur la découverte de certaines
différences dans les réponses ICMP des divers systèmes d'exploitation
(principalement due a une incorrecte, voire inconsistante implémentation),
a été trouvé par Ofir Arkin durant son "ICMP usage in scanning" projet de
recherche. Plus tard, ces découvertes ont été récapitulées dans un arbre
logique de décisions que Ofir titre "X project" et pratiquement implémenté
dans l'outil Xprobe. 

--[Information/Noise ratio with ICMP fingerprints]--

Comme cela à été précisé, le nombre de datagrammes que nous avons besoin
d'envoyer dans le but de prendre à distance l'empreinte de la machine
cible avec des sondages basés ICMP est faible. Très faible. En fait, on
peut envoyer un seul datagramme et ne recevoir qu'une seule réponse et
ceci nous aidera à identifier plus de 8 différents systèmes d'exploitation
(ou classes de systèmes d'exploitation). Le nombre maximal de datagrammes
que notre outil va utiliser au developpement actuel est de 4. C'est le
même nombre de réponses que nous aurons à analyser. Ceci fait de la prise
d'empreinte ICMP un moyen rapide et efficace.

Les sondages basés ICMP peuvent être utilisé comme très furtif. Aucun
datagrammes malformé/cassé/corrompu ne sont utilisés pour identifier un
type d'OS à distance, contrairement aux méthodes communes de prise
d'empreinte. L'analyse actuelle du noyau vise la validation des réponses
ICMP recues sur des paquets valides, plutot que d'utiliser des paquets eux-
même invalide. Les segments de tels paquets apparaissent dans un reseau
moyen sur la quotidiennement, et très peu d'IDS sont configurés pour
detecter un tel trafic (et ceux qui le sont, sont probablement très
bruyant et mal configuré. 

--[Why it still works?]--

Le désordre hérité parmi les différentes implémentations de piles TCP/IP
avec la manipulation des implémentations ICMP qui implémente different
standards RFC ( RFC originale 792, le complément RFC 1122, etc), partielle
ou incomplet support ICMP (les requetes ICMP variable ne sont pas
supportés partout), faible signification des données des messages d'erreur
ICMP (qui vérifient tout les champs du datagramme original ?!), erreurs et
incompréhension dans les implementations du protocole ICMP, font que notre
méthode est viable.

--[What do we fingerprint:]-- 

Plusieurs différences spécifiques aux OS sont utilisés dans la prise
d'empreinte ICMP pour identifier le type de syteme d'exploitation à
distance :

Champs IP d'un datagramme "fautif" à examiner:

* Taille totale du champ IP

Quelques OS (i.g. *BSD) vont ajouter 20 bytes (sizeof(ipheader))
à la taille totale du champ IP original (qui est provoqué, à cause des
erreurs de traitement interne du datagramme, veuillez notez que quand le 
même paquet de SOCK_RAW est lu le même comportement est observé: La taille
du champ du paquet IP en retour sera majoré de 20 bytes).

D'autres systèmes d'exploitation vont enlever 20 bytes a la taille totale
du champ du paquet IP original du paquet fautif.

Un troisieme groupes de systèmes reagiront a ce champ correctement.

*IP ID
Quelques systèmes ne repetent pas correctement ce champ. (l'ordre du bit
du champ à changé)

* 3 bits flags et offset

Quelques systèmes ne repetent pas correctement ce champ. (l'ordre du bit
du champ à changé)

* IP header checksum

Quelques systèmes d'exploitation vont mal calculer ce champ, d'autres vont
carrement le mettre a 0. Un troisieme groupes de systèmes vont répeter ce
champ correctement.

* UDP header checksum (dans le cas d'un datagramme UDP)

La même chose peut arriver avec l'UDP checksum header.

En-tête IP des paquets ICMP répondus:

*bits priorité
chaque datagramme IP a un champ de 8 bits appellés le "TOS byte", qui
represente le support IP pour la priorité et la manipulation du Type-Of-
Service.

Le "TOS byte" est composé de 3 champs.

Le "precedence field"\cite{rfc791}, long de 3 bits, est destiné à donner
la priorité au datagrammes IP. Il à 8 niveaux de priorité.

Le traffic prioritaire plus elevé devrait être envoyé avant le traffic à
faible priorité.

Le deuxieme champ, long de 4 bits, est le champ "Type-Of-Service". Il est
désigné pour décrire de quelle manière le réseau devrait faire des
différences entre le débit, le retard, la fiabilité et le coût dans le
routage d'un datagramme IP.

Le dernier champ, the "MBZ" (must be zero), est inutilisé et doit être à
zéro. Les routeurs et serveurs ignorent ce dernier champ. Ce champ est
long de 1 bit. Le TOS bytes et champ MBZ sont remplacés par le mécanisme
de Diffserv pour QoS.

Le RFC 1812 nécessite les points suivants pour les routeurs IPv4 :

"4.3.2.5 TOS et priorité

Les messages d'erreur ICMP source quench, si envoyés a tous doivent avoir
leurs champs de priorité IP à la même valeur que le champ de priorité IP
dans le paquet qui a provoqué l'envoi des ICMP source quench. Tout autre
message d'erreur ICMP (Destination Unreachable,Redirect, Time Exceeded,
and Parameter Problem) devrait avoir la valeur de leur priorité à 6
(INTERNETWORK CONTROL) ou 7 (NETWORK CONTROL). La valeur de priorité IP
pour ces messages d'erreurs PEUVENT être configurées".

Linux Kernel 2.0.x, 2.2.x, 2.4.x, vont agir comme routeur et vont fixés la
valeur de leurs champs de bits priorité à 0xc0 avec les messages d'erreurs
ICMP. Les dispositifs de gestion de réseaux vont agir de la même facon que
les routeurs CISCO basés sur IOS 11.x-12.x et Foundry Networks switches.

* DF bits echoing

Quelques piles TCP/IP vont répeter le DF bit avec des datagrammes
d'erreurs ICMP, d'autres (comme Linux) vont copier l'octet entierement, en
mettant a zéro  certains bits, d'autres encore vont ignorer ce champ et
configurer leur propre champ.

* IP ID filend (linux 2.4.0 - 2.4.4 kernels)

Les machines Linux basées sur un kernel 2.4.0-2.4.4 vont fixés la valeur
du champ IP identification avec leurs demandes de requetes ICMP et
répondent aux messages avec une valeur de 0.

Ceci fut fixé plus tard avec les kernels 2.4.5 et supérieurs.

* champ IP ttl (ttl la distance de la cible doit être précalculée pour
garantir la précision).

La valeur du champ est réduite à chaque point que l'en-tête IP est
traitée. La RFC791 déclare que la réduction de ce champ reflète le temps
passé à traiter le datagramme. La valeur du champ est mesurée par des
unités de secondes. La RFC déclare également que la valeur ttl maximum qui
peut être fixée est de 255 secondes, ce qui équivaut à 4.25 minutes. Le
datagramme doit être jeté si la valeur de ce champ est à zéro avant
d'atteindre sa destination.

Se réferer à ce champ comme une mesure d'évaluer le temps est un peu
trompeur. Des routeurs vont traités le datagramme plus vite qu'en une
seconde, et d'autres vont le traiter pendant plus d'une seconde. 

L'intention réelle est d'avoir une limitation supérieure à la durée de vie
du datagramme, ainsi les boucles infinies des datagrammes non délivrées ne
bloqueraient pas internet.

Avoir une limite à la durée de vie du datagramme nous aide à empecher des
vieux doubles d'arriver après qu'un certain temps soit déjà écoulé. Ainsi,
quand on retransmet une pièce de l'information qui n'a pas été délivré
precedemment, nous pouvons être assuré que le plus vieux double est déjà
jeté et qu'il n'interferera pas avec le processus.

La valeur du champ IP TTL avec ICMP a deux valeurs séparées, une pour les
demandes de messages ICMP l'autre pour les réponses aux demandes.

La valeur du champ IP TTL nous aide à identifier certains système
d'exploitation et groupes de systèmes d'exploitation. Il nous fournit
également les moyens les plus simples d'ajouter un autre contrôle de
critère quand nous faisons une demande a d'autres hôtes ou quand on écoute
le traffic (sniffing).

La prise d'empreinte basée sur le TTL demande une distance TTL de fait
pour être précalculées à l'avance (à moins que la prise d'empreinte du
systeme basé sur le réseau local soit un système performant).

Le message d'erreur ICMP va utiliser les valeurs utilisées elle-mêmes par
la réponse aux demandes de messages ICMP.

De bonne statistiques sur la dépendance des TTL sur le type d'OS à été
rassemblés à :
http://www.switch.ch/docs/ttl_default.html
(papier de recherche sur les valeurs ttl par défaut)


* champ TOS

La RFC 1349 définit l'usage du champ Type-of-Service avec les messages
ICMP. Il distingue entre les messages d'erreur ICMP (Destination
Unreachable, Source Quench, Redirect, Time Exceeded, and Parameter
Problem), demandes de messages ICMP (Echo, Router solicitation, Timestamp,
Information request, Address Mask request) et les messages de réponses
ICMP (Echo reply, Router Advertisement, Timestamp reply, Information
reply, Address Mask reply).

Des règles simples sont définies:
* Un message d'erreur ICMP est toujours envoyé avec le TOS par défault (0x0000)

* Un message de réponse ICMP peut être envoyé avec n'importe quelle valeur
dans le champ TOS. "Un mécanisme pour permettre aux utilisateurs de
spécifier la valeur TOS qui doit être utilisée serait un avantage utile
dans pas mal d'applications qui génère des messages de requetes ICMP.

Les RFC spécifient de plus que bien que les messages de requêtes ICMP soit
normallement envoyé avec le TOS par défaut, il y a parfois de bonnes
raisons pour lesquelles ils seraient envoyés avec d'autres valeurs TOS. 

* Un message de réponse ICMP est envoyé avec la même valeur dans le champ
TOS comme c'était utilisé dans les requetes de messages ICMP correspondant.

Quelques systèmes d'exploitation vont ignorer la RFC 1349 quand ils
envoient des messages de réponse ICMP echo, et n'enverrons pas la même
valeur dans le champ TOS comme utilisé dans les messages de requète ICMP
correspondant.

en-tête ICMP des paquets ICMP répondus:

* ICMP error message quoting size

Tous les messages d'erreur se composent d'un entête IP, d'un entête ICMP
et d'une certaine quantité de données du datagramme original, qui à
déclenché l'erreur (aka datagramme fautif).

Selon la RFC 792, seulement 64 bits (8 octets) du datagramme original est
supposé être inclus dans le message d'erreur ICMP. Toutefois, la RFC 1122
(parue plus tard) recommande plus de 576 octets pour être cités.

La plupart des "plus vieilles" implementations de piles TCP inclueront 8
octets dans le message d'erreur ICMP. Linux/HPUX 11.x, Solaris, MacOS et
d'autres en inclueront plus.

Remarquablement intéressant est le fait que les ingénieurs Solaris n'ont
probablement pas lu la RFC assidument ( puisqu'au lieu de 64 bits, Solaris
2.x inclus 64 octets (512 bits) du datagramme original.

* intégrité des ICMP error message echoing
Un autre objet qui a été remarqué est que quelques implémentations de
piles, quand elles renvoient une message d'erreur ICMP, peuvent modifier
l'entête IP du paquet fautif et les données fondamentales du protocole,
qui est répeté en retour avec le message d'erreur ICMP. 

Depuis des erreurs, faites pas les programmeurs de piles TCP/IP sont
différentes et spécifique à un système d'exploitation, et l'analyse de ces
erreurs peuvent donner à un attaquant potentiel la possibilité de faire
des prévisions sur le système d'exploitation de la cible.

Additional tweaks and twists:
* Utilisation différentes des champs de code zéro dans les requetes ICMP
écho.

Quand un code ICMP dont la valeur du champ est différente de zéro (0) est
envoyé avec un message ICMP echo request (type 8), les systèmes
d'exploitation qui vont répondre a notre demande avec un message de
réponse ICMP echo, sont ceux qui sont basé sur un des systèmes
d'exploitation Micro$oft, qui renverront un code ICMP dont la valeur du
champ == 0 avec réponse ICMP echo reply. D'autres systèmes d'exploitation
( et dispositif réseaux) répeteront la valeur du champ du code ICMP que
nous utilisions avec l'ICMP echo request.

Les systèmes d'exploitation Micro$oft agissent contrairement aux
directives de la RFC 792 qui instruit les systèmes d'exploitations a ne
changer que le type ICMP en Echo reply (type 0), recalculer les checksums
et envoyer l'ICMP echo reply. 

* Utilisation du DF bit echoing avec les messages ICMP query

Comme dans le cas des messages d'erreur ICMP, des piles TCP vont répondre
à ces demandes, alors que d'autres non.

* D'autres messages ICMP:
*ICMP timestamp request
*ICMP information request
*ICMP address mask request

Quelques piles TCP/IP supporte ces messages et répondent a quelques unes
de ces requêtes.

--[Xprobe implementation]--

Actuellement, Xprobe déploie un arbre logique, développé par Ofir Arkin
dans "Project X". Initialement, un datagramme UDP est envoyé à un port
fermé dans le but de déclencher le message d'erreur ICMP: ICMP unreachable
port unreach. (ceci installe une limitation d'avoir au moins un port non
filtré sur le système cible sans qu'un service soit en train de tourner).
D'ailleurs, quelques tests (icmp unreach content, DF bits, TOS ...),
peuvent être combiné dans une requête simple, puisque ils n'affectent pas
leurs resultats les uns les autres. 
Sur la réception du datagramme ICMP unreachable, le contenu du datagramme
est examiné et une décision de diagnostic est faite: si d'autres essais en
plus sont demandés, selon l'arbre logique, d'autres requetes sont
envoyées. 

--[ Logic tree]---

Récapitulation rapide de l'organisation de l'arbre logique:

Initialement toutes les implémentations de piles TCP/IP sont séparées en 2
groupes, ceux qui vont répeter la priorité des bits précedents, et ceux
qui ne le feront pas. Ceux qui repetent la priorité des bits (linux 2.0.x,
2.2.x, 2.4.x, Cisco IOS 11.x-12.x, Extreme network switches,etc..), étant
différencié encore basé sur la taille de l'ICMP error. (Linux colle avec
la RFC 1122 ici et répete jusqu'a 576 octets, alors que les autres dans ce
sous-groupe echo seulement 64 bits (8 octets). D'autres contrôles
d'intégrité echo sont utilisés pour différencier des routeurs Cisco, des
commutateurs extrêmes d'autres réseaux.

Time-to-live et champs IP ID de l'ICMP echo reply sont utilisés pour
reconnaitre la version du kernel linux.

La même approche étant utilisé pour reconnaitre d'autres piles TCP/IP. Les
données faisant l'écho de validation (quantité d'octets du datagramme
original répétés, validation du checksum, etc ...). Si des informations
supplémentaires sont demandés pour diferrencier deux piles IP
"similaires", des requetes supplémentaires sont envoyées. (referrez-vous
au diagramme a http://www.sys-security.com/html/projects/X.html pour plus
de détails sur une explication/graphic de la représentation de l'arbre
logique.

Un des sérieux problèmes avec l'arbre logique, est que ajouter un nouveau
type de système d'exploitation a celui-ci devient extremement douloureux.
Parfois, une partie entiere de l'arbre logique doit retravaillée pour
s'adapter à une description simple. Par conséquent, une méthode de prise
d'empreinte basé sur la signature a attiré de près notre attention.

--[signature based approach]--
L'approche basé sur la signature est ce sur quoi nous nous centrons
actuellement et qui, nous le croyons sera plus stable, plus fiable et plus
flexible méthode de prise d'empreinte ICMP à distance.

La méthode basé sur la signature est actuellement basé sur 5 différents
tests, qui peuvent optionnellement être inclues dans chaque empreinte de
pile de systèmes d'exploitation. Initiallement, les systèmes avec la
moindre quantité de tests sont examinés (qui démarre normallement avec un
test ICMP unreach).

Si aucune pile d'OS trouvée ne correspond à la signature recue, ces piles
qui correspondent en partie, étant regroupés encore, et un autre test
(basé sur le peu de quantité de tests émis par principe) est choisi et
executé. Cette vérification est répétée jusqu'a ce une pile de l'OS,
corresponde complètement a la signature trouvée, ou alors les tests
s'arretent.

Les tests suivants sont actuellement développés:

* test ICMP unreachable ( basé sur un port udp fermé, hote unreachable,
  reseau unreachable (pour les systèmes qui sont pensées etre des gateways)
* ICMP echo request/reply test
* ICMP timestamp request
* ICMP information request
* ICMP address mask request

--[future implementations/development]--

Les sujets suivants sont prévus d'être développé (nous acceuillons les
discussions et suggestions sur ce sujet avec grad plaisir):
* fingerprints database (actuellement en phase de test)
* Dynamic, AI based logic (projet à long terme :))
* Tests devraient fortement dépendre de la topologie du reseau (pre-test
  de mapping du reseau auront lieu.
* Path-to-target test (pour calculer l'hops distance de la cible) sondage
  des dispositifs filtrant
* Implementations futures utiliseront des paquets avec les données de
  l'application actuelle pour écarter les chances d'être détectées.
* d'autres capacités de mapping de réseau devrait être inclue
  ( indentification du rôle du reseau, recherche de port UDP fermé,
  reachability tests, etc).

--[code for kids]--

Codes actuellement implémentés et plus de documentation sont disponibles a
ces adresses suivantes:

http://www.sys-security.com/html/projects/X.html

http://xprobe.sourceforge.net

http://www.notlsd.net/xprobe/

Ofir Arkin <ofir@sys-security.com>
Fyodor Yarochkin <fygrave@tigerteam.net>

|=[ EOF ]=---------------------------------------------------------------=|