playground~ telnet hpux.u-aizu.ac.jp

Trying 163.143.103.12...

Connected to hpux.u-aizu.ac.jp.

Escape character is '^]'.

HP-UX hpux B.10.01 A 9000/715 (ttyp2)

login:

  Il n'y a aucun intérêt à s'embarquer dans les complexités de la prise d'empreinte de pile si la machine annonce d'une manière aussi flagrante et précise quel OS tourne.
Malheureusement, beaucoup de vendeurs vendent les systèmes actuels avec ce genre de bannière et beaucoup d'administrateurs ne les désactivent pas.
Ce n'est pas parce que d'autres moyens existent pour deviner quel OS tourne (comme l'empreinte de pile par exemple), qu'il faut annoncer son OS et son architecture à chaque personne essayant de se connecter.

  Le problème quand on compte sur ce genre de techniques est qu'un nombre croissant de personnes désactivent ces bannières, de plus beaucoup de systèmes fournissent peu d'information et il est facile de "mentir" dans ses bannières.
Néanmoins, la lecture des bannières est tout ce que vous avez pour vérifier l'OS et sa version si vous dépensez des dizaines de milliers de francs pour un ISS scanner commercial.
Telechargez queso ou nmap a la place et économisez votre argent. :)

  Même si vous désactivez les bannières, beaucoup d'applications donneront gentiment ce genre d'information si on le leur demande. 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, ca 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 /bin/ls ou un autre fichier binaire et déterminer pour quelle architecture il a été compilé/lié.

  Beaucoup d'autres applications sont trop laxistes 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

Hmmm ... Je me demande quel OS ces lamers utilisent.

  D'autres techniques classiques incluent l'enregistrement d'info DNS (rarement efficace) et l'enginierie sociale.
Si la machine écoute sur le port 161/udp (snmp), vous êtes presque sur d'obtenir un paquet d'info détaillées en utilisant 'snmpwalk' de la distribution d'outils CMU SNMP et le nom de communauté 'public'.

----[ PROGRAMMES ACTUELS D'IDENTIFICATION

  Nmap n'est pas le premier programme de reconnaissance d'OS a utiliser l'identification TCP/IP. Le spoofer IRC sirc de Johan incluait des techniques très rudimentaires d'identification depuis la version 3(ou plus ancienne). Il essaye de placer la machine dans les classes "Linux", "4.4BSD", "Win95", ou "Unknown" en utilisant quelques tests simples sur les flags TCP.

  Un autre programme de ce type est checkos, rendu public en janvier de cette année par Shok du groupe CodeZero dans Confidence Remains High numéro 7. Les techniques d'identifications sont exactement les mêmes que dans SIRC, et même le code est identique en plusieurs point. Checkos est disponible en prive depuis un bon moment avant être rendu public, Je n'ai donc pas la moindre idée de qui a recopier le code de qui.
Mais aucun de semble reconnaître s'inspirer de l'autre.
Une chose que checkos ajoute, est la vérification de la bannière telnet, qui est utile mais qui possède les inconvénients décrits plus haut.

  Su1d a aussi écrit un programme de vérification d'OS. Son programme s'appelle SS et la version 3.11 peut identifier 12 types d'OS différents. Je suis un peu partial envers ce programme car il me cite pour l'utilisation d'une partie du code réseau :).
Ensuite il y a queso. Ce programme est le plus récent et marque une grande évolution par rapport aux autres programmes. Non seulement il introduit des tests nouveaux, mais il est aussi le premier (a ma connaissance) a déplacer les empreintes d'OS hors du code.
Les autres scanners incluent du code comme :

/* provenance ss */

if ((flagsfour & TH_RST) && (flagsfour & TH_ACK) && (winfour == 0) && 

   (flagsthree & TH_ACK))

       reportos(argv[2],argv[3],"Livingston Portmaster ComOS");	

  A la place, queso déplace ceci dans un fichier de configuration qui convient évidemment mieux et qui rend l'ajout d'un nouvel OS aussi facile qu'ajouter quelques lignes a un fichier d'empreinte.

  Queso a été écrit par Savage, qui est de ces gens biens d'Apostols.org.

  Un problème est que tous les programmes décrits plus haut sont très limites dans le nombre de tests d'empreinte, ce qui limite la granularité des réponses.
Je voudrais savoir plus que 'Cette machine est OpenBSD, FeeBSD, ou NetBSD', je voudrais savoir quel est le système parmi ceux-la ainsi qu'avoir une idée des numéros de release et de version.
De la même manière, je préférerais voir 'Solaris 2.6' plutôt que simplement 'Solaris'. Pour obtenir cette granularité des réponses, j'ai travaille sur un nombre de techniques de prise d'empreinte qui sont décrites dans la section suivante.

----[ 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 vous combinez assez de ces techniques, vous pouvez déduire les OS d'une manière très fine. Par exemple nmap peut distinguer d'une manière fiable Solaris 2.4 par opposition a 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 techniques:

   Le test FIN -- La 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. La plupart des outils courants utilisent cette technique.

   Le teste du flag BUG -- Queso est le premier scanner que j'ai vu utiliser ce test astucieux. 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 au 2.0.35 conservent ce flag positionne dans leur réponse.
Je n'ai trouve aucun autre OS ayant ce bug. Cependant, certains systèmes semblent reseter la connexion quand ils reçoivent un paquet SYN+BUG.
Ce comportement pourrait être utile pour les identifier.

   Echantillonnage TCP ISN -- L'idée est ici 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 ma technique favorite est la "constante". la machine utilise TOUJOURS le même ISN :). Je l'ai vu sur quelques hubs 3com (utilisent 0x803) et des imprimantes Apple LaserWriter (utilisent 0xC7001).

  On peut aussi sous-classer les groupes tels qu'incrément 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 doit être note que la génération d'ISN a d'importantes implications sur la sécurité. Pour plus de détail sur ce sujet, contactez l"Expert Sécurité" Tsutomu "Shimmy" Shimomura au SDSC et demandez-lui comment il s'est fait hacker.
(**NDT : Référence à l'intrusion de MITNICK par IP spoofing )
  Nmap est le premier programme de ma connaissance a 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 ennuyant -- 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. Je n'ai jamais vu ce test auparavant.

   Fenêtre initiale TCP -- Il s'agit juste 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 actuellement beaucoup d'informations, car certains OS peuvent être identifies par cette fenêtre seulement (par exemple, AIX est le seul OS de ma connaissance 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 -- Bien que vous puissiez penser que c'est complètement standard, les implémentations diffèrent par la valeur utilisée pour le champ ACK dans certains cas. Par exemple, supposons que vous envoyez un FIN|PSH|URG a un port TCP ferme. La plupart des implémentations affecteront au champ ACK la même valeur que votre ISN, cependant, Windows et quelques imprimantes stupides reverront seq+1. Si vous envoyez FIN|PSH|URG a un port ouvert, Windows est très inconsistant. 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 ca.

   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 envoyer un lot de paquet a un port haut UDP (choisi aléatoirement) et de compter le nombre de "destination inaccessible" reçus. Je n'ai jamais vu ce procédé utilise auparavant, et en fait je ne l'ai pas ajoute à nmap (excepter pour utilisation dans le scanning de port UDP ).
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 ca autorise Nmap a reconnaître Linux et Solaris mais s'ils n'ont pas de ports à l'écoute.

   Intégrité des messages d'erreur ICMP émis -- J'ai eu cette idée grâce à un message de Theo de Raadt (développeur majeur OpenBSD) poste au newsgroup comp.security.unix. Comme il a été dit précédemment, les machines doivent renvoyer une partie du message original avec un message port inaccessible. Actuellement certaines machines utilisent les en-têtes comme espace de travail pendant le traitement initial, et ces en-têtes sont donc 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 BSDI, FreeBSD, OpenBSD, ULTRIX et VAX bousillent l'ID IP qu'on leur envoi. Alors que la somme de contrôle va changer a cause de la modification du champ TTL (**NDT : 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. L'un dans l'autre, 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 j'ai regarde 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é (pour autant que je sache). Je ne sais pas pourquoi il est positionne, mais s'il change cette valeur en 0, nous serons capable d'identifier les vieilles versions ET nous serons capable de distinguer entre l'ancienne et 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é. Je n'ai pas ajoute cette capacité car je ne connais pas de manière portable d'envoyer des paquets fragmentes (C'est particulièrement dur sous Solaris). Pour plus d'information sur les fragments se recouvrant, vous pouvez lire leur article(www.secnet.com).

   Options TCP -- Elles sont vraiment une mine d'or en terme de source d'information. CE qu'il y a de bien avec les options est :
     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
    avec 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;

FingerPrint  IRIX 6.2 - 6.4 # Merci a Lamont Granquist

TSeq(Class=i800)

T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)

T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

T3(Resp=Y%DF=N%W=C000|EF2A%ACK=O%Flags=A%Ops=NNT)

T4(DF=N%W=0%ACK=O%Flags=R%Ops=)

T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)

T6(DF=N%W=0%ACK=O%Flags=R%Ops=)

T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)

PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

  Regardons la première ligne (J'ajoute '' comme marqueur de citation):

  FingerPrint  IRIX 6.2 - 6.3 # Merci a Lamont Granquist

  TSeq(Class=i800)

  T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)

 T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

  Le Test 2 implique un NULL avec les mêmes options sur un port ouvert. Resp=Y veut dire que l'on doit avoir une réponse. Ops= veut dire qu'il ne doit y avoir aucune option inclue dans le paquet de réponse. Si on enlevait '%Ops=' alors n'importe quelle(s) option(s) conviendrai(en)t.

  T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AS%Ops=M)

  T4(DF=N%W=0%ACK=O%Flags=R%Ops=)

 T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)

 T6(DF=N%W=0%ACK=O%Flags=R%Ops=)

 T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)

  Ces tests sont respectivement des paquets SYN, ACK, et FIN|PSH|URG sur un port ferme. Les mêmes options sont toujours positionnées. Bien sur c'est probablement évident étant donne les noms descriptifs 'T5', 'T6', et 'T7' :).

  PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

nmap -sS -F -o transmeta.log -v -O www.transmeta.com/24