Sécurité TCP IP 4

4. Finger printing

1. 1. Principe

Le finger printing recouvre toutes les méthodes classiques pour déterminer l’OS d’un serveur par “la prise d’empreinte de pile”.

1. 2. Objectifs

L’utilité de déterminer l’OS qui tourne sur un système est assez évidente.

Un des exemples les plus fort de cette utilité, est que beaucoup de failles de sécurité sont dépendantes d’une version d’OS.

Supposons que nous fassions un test de pénétration et que nous trouvions le port 53 ouvert.

Si c’est une version vulnérable de bind, il n’y aura qu’une seule chance de l’exploiter, car un essai infructueux crashera le démon.

Avec un bon Identificateur TCP/IP, nous trouverons rapidement que cette machine fait tourner Solaris 2.51 ou Linux 2.0.35 et nous pourrons ajuster notre scriptshell en conséquence.

Encore plus fort : il est possible de scanner 500 000 machine par avance pour voir quel OS tourne et quels ports sont ouverts. Ensuite notre petit cracker pourrait faire un grep sur la liste en cherchant ‘UDP/512’ et ‘Solaris 2.6’ et il trouvera immédiatement des pages et des pages de sites où il pourra être root.

Il est à noter que ce comportement ne demande aucun talent, c’est de l’exploitation pure et simple de scripts.

Autre usage possible : l’enginierie social.

Exemple : un Hacker scanne une société cible et NMAP lui rapporte un ‘Datavoice TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06’.

Il peut alors appeler en se faisant passer pour quelqu’un du support Datavoice et discuter des particularités de leur PRISM 3000.

“Nous allons annoncer une faille de sécurité bientôt, mais nous voudrions avant que nos clients installent le patch — Je viens juste de vous l’envoyer par email…”

Certains administrateurs (pas assez paranos) pourraient croire que seul un ingénieur de Datavoice en connaît autant sur son CSU/DSU.

Un autre usage possible est l’utilisation de cette capacité pour une forme d’espionnage industriel.

Bref, avant de choisir un nouveau fournisseur de service Internet, scannez le et voyez quel équipement il utilise. Ses promotions à 100€/an ne sembleront plus aussi intéressantes si cela signifie qu’ils utilisent des routeurs qui offrent des services PPP à partir d’un matériel Micro$oft.

1. 3. Techniques « classiques »

Le problème, quand on compte sur ce genre de techniques, est qu’un nombre croissant de personnes désactivent les bannières informatives (et c’est heureux). De plus beaucoup de systèmes fournissent que très peu d’information et il est facile de mentir dans ses bannières.

Néanmoins, la lecture des bannières est tout ce que nous avons pour vérifier l’OS et sa version, sauf si nous dépensons des dizaines de milliers d’Euros pour un ISS scanner commercial.

En réalité, nous avons avantage à télécharger Queso ou NMAP à la place.

Même si on désactive les bannières, beaucoup d’applications donneront gentiment ce genre d’information, pour peu que la demande soit faite intelligemment.

Par exemple regardons un serveur FTP :

payfonez telnet ftp.netscape.com 21 Trying 207.200.74.26… Connected to ftp.netscape.com. Escape character is ‘^]’. 220 ftp29 FTP server (UNIX(r) System V Release 4.0) ready. SYST 215 UNIX Type: L8 Version: SUNOS

Premièrement, cela nous donne le détail du système dans sa bannière par défaut.

Ensuite si on tape la commande ‘SYST’ cela nous donnera encore plus d’informations.

Si le FTP anonyme est supporté, nous pourrons souvent télécharger le /bin/ls ou un autre fichier binaire et déterminer pour quelle architecture il a été compilé et lié.

Beaucoup d’autres applications sont trop généreuses avec les informations. Prenez les serveurs Web par exemple :

playground echo ‘GET / HTTP/1.0\n’ | nc hotbot.com 80 | egrep ‘^Server:’ Server: Microsoft-IIS/4.0 playground

1. 4. Procédures de détections plus évoluées

A l’usage, on se rend vite compte que tous les programmes évoqués plus haut (Nmap, Checkos, SS, etc) sont très limités dans le nombre de tests d’empreinte.

Comment en savoir plus que le fait que cette machine est sous OpenBSD, FeeBSD, ou NetBSD ?

Comment savoir quel est le système parmi ceux-là ainsi qu’avoir une idée des numéros de version ?

Il est préférable de savoir que les système est ‘Solaris 2.6’ plutôt que simplement ‘Solaris’.

Pour obtenir ces détails, nous devons aller plus avant dans l’utilisation de NMAP.

1. 5. Méthodologie de la prise d’empreinte

Il y a de nombreuses techniques qui peuvent être utilisées pour prendre une empreinte des piles réseau. A la base, on cherche juste des choses qui diffèrent parmi les OS et on écrit un test pour déterminer la différence.

Si l’on combine ces techniques, on peut déduire les OS d’une manière très satisfaisante.

NMAP peut distinguer d’une manière fiable Solaris 2.4 de Solaris 2.5-2.51 ou Solaris 2.6.

Il peut aussi dire Linux kernel 2.0.30 plutôt que 2.0.31-34 ou 2.0.35.

Voici quelques exemples de techniques:

Le test FIN : Nous envoyons un paquet FIN (ou n’importe quel paquet sans flag ACK ou SYN) a un port ouvert et attendons la réponse. Le comportement (conforme à la RFC793) est de ne pas répondre, mais beaucoup d’implémentations incorrectes comme MS Windows, BSDI, CISCO, HP/UX, MVS et IRIX répondent par un RST.

Le test du flag BUG : Queso est le premier scanner à utiliser ce test astucieux. L’idée est de positionner un flag “TCP” indéfini (64 ou 128) dans l’en-tête TCP d’un paquet SYN.

Les systèmes Linux antérieur à 2.0.35 conservent ce flag positionné dans leur réponse.

Aucun autre OS n’a ce bug.

Cependant, certains systèmes semblent relancer la connexion quand ils reçoivent un paquet SYN+BUG. Ce comportement peut être utile pour les identifier.

Echantillonnage TCP ISN : L’idée est de trouver les types de nombres de séquence initial (Initial Séquence Number) choisis par les implémentations TCP quand ils répondent à une demande de connexion. Ils peuvent être ranger dans plusieurs groupes comme le traditionnel 64K (beaucoup de vieux Unix), incréments aléatoires (dernier Solaris, IRIX, FreeBSD, Digital UNIX, Cray, et beaucoup d’autres), vraiment aléatoires (Linux 2.0.*, OpenVMS, derniers AIX, etc.).

Les systèmes Windows (et quelques autres) utilisent un modèle “dépendant du temps” ou l’ISN est incrémenté d’un petit montant d’une manière périodique. Inutile de dire que c’est aussi facilement “cassable” que la vieille méthode des 64K.

Bien sur la technique favorite soit la “constante”, la machine utilise TOUJOURS le même ISN.

On le trouve sur quelques hubs 3com (utilisent 0x803) et des imprimantes Apple LaserWriter (utilisent 0xC7001).

On peut aussi sous-classer les groupes tels qu’incrémentation de variable par les variantes de calcul, PGCD, et autres fonctions sur l’ensemble des numéros de séquence et les différences entre ces numéros.

Il faut noter que la génération d’ISN a d’importantes implications sur la sécurité.

Nmap est le premier programme à utiliser cette technique pour identifier les OS.

Bit “ne pas fragmenter” : Beaucoup de systèmes d’exploitation commencent par positionner le flag IP “Ne pas fragmenter” sur certains des paquet qu’ils envoient. Cela permet des gains de performance (Mais cela peut aussi être ennuyeux ; c’est pourquoi le scan de la fragmentation de Nmap ne marche pas à partir de systèmes Solaris). Dans tous les cas, tous les OS ne le font pas et certains le font dans d’autres situations. On peut donc, en prêtant attention a ce bit, glaner encore plus d’information sur l’OS cible.

Fenêtre initiale TCP : Il s’agit de vérifier la taille de la fenêtre sur les paquets retournes. Certains vieux scanners utilisent une taille non nulle de fenêtre dans un paquet RST comme identificateur pour un système “Dérivant de BSD 4.4”. Les scanners plus récents comme Queso et Nmap conservent une trace de la taille exacte de la fenêtre car elle est relativement constante suivant les types d’OS. Ce test donne beaucoup d’informations, car certains OS peuvent être identifiés par cette fenêtre seulement (par exemple, AIX est le seul OS utilisant 0x3F25). Dans leur pile TCP/IP “complètement réécrite” pour NT5, Microsoft utilise 0x402E. Il est intéressant de noter que c’est le même nombre que celui utilise par OpenBSD et FreeBSD.

Valeur ACK : Dans certains, les implémentations diffèrent par la valeur utilisée pour le champ ACK.

Par exemple, si on envoie un FIN|PSH|URG à un port TCP fermé. La plupart des implémentations affecteront au champ ACK la même valeur que votre ISN.

Cependant, Windows et quelques imprimantes stupides renverront SEQ+1. Si on envoie FIN|PSH|URG à un port ouvert, Windows est totalement dépassé. Il renvoi parfois SEQ d’autres fois il renvoi S++, et d’autres fois il renvoi une valeur visiblement aléatoire.

On peut se demander quel type de code Microsoft écrit pour changer son comportement comme ça.

Extinction des messages erreurs ICMP : Certains OS (astucieux) suivent la suggestion de la RFC 1812 limitant la vitesse a laquelle divers messages erreurs sont envoyés. Par exemple, le noyau Linux (dans net/ipv4/icmp.h) limite la génération des messages destination inaccessible a 80 par 4 secondes, avec 1/4 de seconde de pénalité en cas de dépassement.

Un moyen de tester ceci est d’envoyer un lot de paquet a un port haut UDP (choisi aléatoirement) et de compter le nombre de “destination inaccessible” reçus.

Ce test rendrait la détection d’OS un peu plus longue comme on doit envoyer un lot de paquets et attendre leur retour. De plus, gérer la possibilité que certains paquets n’arrivent pas serait difficile.

Citation de message ICMP : Les RFC spécifient qu’un message d’erreur ICMP cite une partie du message ICMP ayant cause les erreurs.

Pour un message ‘port inaccessible’, presque toutes les implémentations renvoient seulement l’en-tête IP + 8 octets. Cependant, Solaris renvoi un peu plus et Linux encore un peu plus. La beauté de la chose est que cela autorise Nmap à reconnaître Linux et Solaris, mais seulement s’ils n’ont pas de ports à l’écoute.

Intégrité des messages d’erreur ICMP émis : Les machines doivent renvoyer une partie du message original avec un message ‘port inaccessible’. Certaines machines utilisent les en-têtes comme espace de travail pendant le traitement initial. De ce fait, ces en-têtes sont un peu altérés quand ils les renvoient.

Par exemple AIX et BSDI renvoient un champ IP ‘taille totale’ trop grand de 20 octets. Certains OS, comme BSDI, FreeBSD, OpenBSD, ULTRIX et VAX détruisent l’ID IP qu’on leur envoi. Alors que la somme de contrôle va changer à cause de la modification du champ TTL (champ Time To Live), il y a certaines machines (AIX, FreeBSD, etc.) qui renvoient une somme de contrôle inconsistante ou nulle. On constate la même chose avec les sommes de contrôles UDP.

En fin de compte, Nmap fait 9 tests différents sur les erreurs ICMP pour détecter les subtiles différences de ce type.

Type de service : Pour les messages ‘ICMP port inaccessible’ la valeur du Type de Service (TOS) du paquet retourne. Presque toutes les implémentations utilisent 0 pour les erreurs ICMP cependant Linux utilise 0xC0. Cela n’indique pas une des valeurs standards du TOS, mais est plutôt une partie du champ de préséance inutilisé. S’il change cette valeur en 0, nous serons capables d’identifier les vieilles versions ET de distinguer l’ancienne de la nouvelle.

Gestion de la fragmentation : C’est la technique favorite de Thomas H. Ptacek de Secure Networks, Inc (maintenant détenue par un groupe d’utilisateurs de Windows au NAI). Elle prend avantage du fait que différentes implémentations gèrent souvent différemment les fragments IP se recouvrant. Certains recouvrent la vieille partie avec la nouvelle dans d’autres cas c’est la vieille partie qui prédomine.

Il y a beaucoup de tests différents qu’on peut utiliser pour déterminer comment le paquet a été ré-assemblé.

Pour plus d’information sur les fragments voir documentation sur www.secnet.com.

Options TCP : Elles sont vraiment une mine d’or en terme de source d’information.

1. Elles sont en général optionnelles : ce qui fait que toutes les machines ne les implémentent pas.

2. On sait si une machine les implémente en envoyant une demande aec une option positionnée. La cible montre généralement qu’elle supporte l’option en la positionnant dans sa réponse.

3. On peut positionner tout un tas d’options dans un paquet pour tout tester en une seule fois.

Nmap envoi ces options avec quasiment tous les paquets de test:

Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops;

Quand on obtient une réponse, on regarde quelles options sont retournées et donc supportées. Certains OS, comme les machines BSD récentes, supportent toutes celles positionnées plus haut, alors que d’autres comme Linux 2.0.x en supportent très peu.

Les derniers noyaux Linux 2.1.x supportent tous ceux définis plus haut. En contrepartie ils sont plus vulnérables a la prédiction du numéro de séquence TCP.

Même si plusieurs OS supportent le même ensemble d’options, on peut parfois les distinguer par la VALEUR de ces options. Par exemple, si on envoi une petite valeur MSS à une machine Linux, elle répondra généralement par cette même valeur. D’autres machines retourneront des valeurs différentes.

Et même si on obtient le même ensemble d’options supportées ET les mêmes valeurs, on peut encore faire une différence via l’ORDRE dans lequel les options sont données.

Chronologie des exploits : Même avec tous les tests vus plus haut, Nmap est incapable de distinguer les piles TCP de Win95, WinNT ou Win98.

C’est plutôt surprenant, particulièrement quand on sait que Win98 est sorti 4 ans après Win95. On pourrait penser que MiniDoux de serait soucié d’améliorer un peu sa pile (comme par exemple en supportant plus d’options TCP) et cela nous aurais permis de détecter les changements et donc de distinguer les OS.

Malheureusement ce n’est pas le cas. La pile NT ressemble étrangement à celle présente sur ’95’. Et ils ne sont même pas soucier de l’améliorer pour ’98’.

Pourtant, il existe tout de même une solution.

On peut simplement commencer avec les premières attaques de Privations de Services ( ‘DOS attack’=’Denial Of Services”) contre Windows et évoluer vers des attaques plus avancées. Après chaque attaque, on les teste pour voir s’ils ont plantés.

Quand ils le seront, nous serons capable de déterminer ce qu’ils utilisent comme service pack et quel patch lui a été appliqué.

Petite restriction : cette fonctionnalité n’est pas présente dans Nmap.

Résistance au SYN flood : Certains systèmes d’exploitation arrêterons d’accepter de nouvelles connections si on leur envoi trop de paquets SYN contrefait ( les paquets contrefaits évitent les ennuis tel que le noyau ré-initialisant les connections).

Beaucoup de systèmes d’exploitation géreront uniquement 8 paquets.

Les noyaux Linux récents (parmi d’autres OS) autorisent plusieurs méthodes comme les cookies SYN empêchant cela de devenir un problème sérieux. Ce qui signifie que l’on peut apprendre quelque chose sur l’OS cible en envoyant 8 paquets d’une source modifiée (‘forged packet’ = ‘paquet contrefait’ = paquet bricolé à la main avec une IP source modifiée) à un port ouvert et tester ensuite si on peut établir une connexion sur ce port.

Cela n’a pas été implémenté dans Nmap, car certaines personnes n’apprécient pas de subir un SYN flood, même si on explique qu’on essaye seulement de déterminer quel OS ils utilisent afin de mieux administrer le parc informatique.