-------------------------------------------------------------------------- Fuzzy fingerprint By Dozer[dg-sc] ----------------- Introduction Depuis quelques temps maintenant, je m'interessai aux différentes techniques de détection d'OS a distance. Une des techniques les plus populaires parmis celles ci est la prise d'empreinte de pile TCP/IP, popularisé par le célèbre nmap. Celui ci se contente de faire des tests assez "basique". Si l'une de ces conditions n'est pas remplies, le résultat du fingerprint sera alors "faussé". Par exemple, il suffit souvent de simplement modifier la valeur du TTL par défault pour renvoyer une réponse faussée. Il est ainsi necessaire de pousser nos tests un peu plus loin afin de récupéré une réponse juste, même si certaines options de la pile TCP/IP ont été modifiés ou bien si il y a présence d'un NIDS actif ou d'un firewall. Un autre probleme de nmap est qu'il utilise des paquets pathologiques (paquets malformés, XMAS, NULL) pour découvrir l'OS distant, ce qui à l'heure actuelle est très facile à repérer pour les différents NIDS. I Detection de systeme Windows ----------=[ 1/ Detection à distance de systeme windows Dans un premier temps, nous allons voir que le fameux nmap peut se reveler dans certain cas incapable de detecter pécisement un OS distant. Plusieurs raison peuvent-être a l'origine de cela: présence de firewall, ban d'IP après un portscan, ou encore modification d'un ou plusieurs champs (Par exemple, le TTL est une valeur que les utilisateurs cherchent souvent à modifier, cette modification seul peut perturber la prise d'empreinte de nmap). * [Dozer@Dozer Dozer]nmap -sS -sV -P0 -O -vv -p 1-100 81.53.35.64 * Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-02-03 20:39 CET * Host ANancy-107-1-32-64.w81-53.abo.wanadoo.fr (81.53.35.64) appears to be up ... * good. * * (The 98 ports scanned but not shown below are in state: filtered) * PORT STATE SERVICE VERSION * 21/tcp open ftp * 80/tcp open http Apache httpd * * Device type: general purpose|firewall|broadband router * Running: IBM AIX 4.X|3.X, Linux 1.X, Netscreen ScreenOS, Microsoft Windows 2003/ * .NET, Cayman embedded, Zyxel ZyNOS * Too many fingerprints match this host to give specific OS details * TCP/IP fingerprint: * SInfo(V=3.50%P=i386--netbsdelf%D=2/3%Time=401FF964%O=21%C=-1) * TSeq(Class=TR%IPID=RD%TS=0) * T1(Resp=N) * T2(Resp=N) * T3(Resp=N) * T4(Resp=N) * T5(Resp=N) * T6(Resp=N) * T7(Resp=N) * PU(Resp=N) * TCP Sequence Prediction: Class=truly random * Difficulty=9999999 (Good luck!) * TCP ISN Seq. Numbers: A6747C5B 7694CF11 2404BCD1 EFD802B7 * IPID Sequence Generation: Randomized * Nmap run completed -- 1 IP address (1 host up) scanned in 105.857 seconds Ici, on voit bien que Nmap n'est pas réellement capable de détecter mon systeme, un windows 2000. On remarque que deux ports sont ouverts : certains d'entre vous vont peut-être penser à faire une requète sur le port 80 (par exemple) afin d'apercevoir un ID +1, et donc de détecter le systeme windows... Certes, mais prenons un autre exemple .. [Dozer@Dozer Dozer]hping -c 4 -r -S 208.57.46.51 * HPING 208.57.46.51 (ppp0 208.57.46.51): S set, 40 headers + 0 data bytes * len=44 ip=208.57.46.51 ttl=45 id=20322 sport=80 flags=SA seq=0 win=16384 rtt=202.6 ms * len=44 ip=208.57.46.51 ttl=45 id=+1 sport=80 flags=SA seq=1 win=16384 rtt=201.8 ms * len=44 ip=208.57.46.51 ttl=45 id=+1 sport=80 flags=SA seq=2 win=16384 rtt=209.5 ms * len=44 ip=208.57.46.51 ttl=45 id=+1 sport=80 flags=SA seq=3 win=16384 rtt=201.5 ms Dans ce cas présent, on pourrait supposer qu'il s'agit d'un système Windows avec son TTL initial fixé a 64 et incrémentation de 1 du champ ID. On a, en effet, toujours tendance a associer Windows à un ID +1 ... Hors si j'envoie une requète avec tous un tas d'options TCP positionnées afin de voir quelles options supportent l'host distant, et que je sniffe la réponse: [Dozer@Dozer Dozer]tcpdump -i ppp0 -vve * 17:24:21.447331 00:00:01:00:00:00 > d6:b1:20:00:01:00, ethertype IPv4 * (0x0800), length 78: IP (tos 0x0, ttl 64, id 32092, offset 0, flags * [DF], length: 64) ANancy-110-1-10-115.w81-53.abo.wanadoo.fr.3668 > * ns1.benjammin.net.80: S [tcp sum ok] 2946956029:2946956029(0) win 5840 * * 17:24:22.839332 d6:b1:20:00:01:00 > 00:00:01:00:00:00, ethertype IPv4 * (0x0800), length 58: IP (tos 0x0, ttl 45, id 7817, offset 0, flags * [none], length: 44) ns1.benjammin.net.80 > * ANancy-110-1-10-115.w81-53.abo.wanadoo.fr.3669: S [tcp sum ok] * 3988597209:3988597209(0) ack 2947316287 win 16384 On constate que la longueur du paquet IP est de 44 (MSS supporté), contre 48 pour Windows (MSS, SackOK, et deux NOPs supporté). Le système en question était un AIX 4.3. Conclusion, il faut *TOUJOURS* examiner l'ensemble des champs (en manuel) du paquet pour être réellement sur que le système en face de nous est bien celui auquel on pense: __________________________________________________________________________________________________________________________________ | Os |TTL |WinSize |IP Paquet Lenght |ToS |ID incrementation| ISNs |MSS initial | Options TCP | |@@@@@@@@@@@@@@|@@@@@@@|@@@@@@@@|@@@@@@@@@@@@@@@@@|@@@@|@@@@@@@@@@@@@@@@@|@@@@@@@@@@@@@@@@@@@@@@|@@@@@@@@@@@@|@@@@@@@@@@@@@@@@@@@@| |Windows 95 | 32 | 8192 | 44 | / | +1 |evoluent avec le temp | 536 |Aucune sauf MSS | |Windows 98 | 128 | 8192 | 48 | / | +1 |evoluent avec le temp | 536 |MSS, SackOK, 2 NOPs | |Windows 2000 | 128 | 16384 | 48 | 0 | +1 |"pseudo aléatoire" | 1460 |MSS, SackOK, 2 NOPs | |Win XP pro | 128 | 16384 | 48 | 0 | +1 |"pseudo aléatoire" | 1360 |MSS, SackOK, 2 NOPs | |Win XP pro SP1| 128 | 65535 | 48 | 0 | +1 |"pseudo aléatoire" | 1420 |MSS, SackOK, 2 NOPs | |______________|_______|________|_________________|____|_________________|______________________|____________|____________________| Je vous laisse la peine d'examiner plus précisement les fichiers *.fp fournis avec p0f 2 pour en savoir plus sur les implémentations du protocole TCP/IP dans les différentes versions de windows :) ----------[ 2/ Masquer un systeme windows Il n'est donc pas possible, de "cacher" completement un système windows, car on ne peut modifier l'incrémentation du champ ID. Il nous faut donc modifier les autres champs de telle sorte que l'ensemble corresponde à un système qui incrémente son champ ID de 1. Pour cela, on a le choix de faire passer notre systeme Windows pour un systeme AIX 4.x, Solaris (qui sont deux système ressemblants à windows), FreeBSD, NetBSD, OpenBSD (jusqu'a la version 2.5), ou encore pour une autre version de Windows ;> Pour les différentes caractéristiques des divers unix, voir tableaux section II - 1 Il devient alors imaginable d'appliquer un .reg contenant les dites valeurs, à la maniere d'un patch a appliquer à l'OS. Par exemple: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] "TcpWindowSize"=dword:00008576 #on définit la WinSize "DefaultTTL"=dword:000000ff #on spécifie le TTL "DisableUserTOSSetting"=dword:00000001 #un programme ne spécifie pas son ToS "DefaultTOSValue"=dword:000000c0 #on spécifie le ToS "SackOpts"=dword:00000000 #Disable/Enable SackOK options "Tcp1323Opts"=dword:00000000 #Disable/Enable window scaling, nop flag, Timestamp options "DefaultMSS"=dword:000005a0 #On définit la valeur du champ MSS "TcpUseRFC1122UrgentPointer"=dword:00000000 #Utilisation de la RFC 1122 ou non pour le traitement des données urgentes [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\] "mtu"=dword: #On définit le MTU. On rapelle que MaxMSS = MTU - 40. ____ "TcpInitialRTT"=dword:00000002 #Delai initial pour la retransmission de données (SYN|ACK) | après une perte. Attention, le calcul est exponentiel --> Ces Valeurs nous permettent de "TcpMaxConnectResponseRetransmissions"=dword:00000002 #Définit le nombre de SYN|ACK à renvoyé après un timeout | de faire échouer les techniques de la part de l'host qui à fait la requete ____| de prise d'empreinte basé sur le RTT et le RTO ;P De plus, n'importe quel firewall personnel se chargera du renforcement des numéros de séquences. Malheureusement, contrairement à un système sous linux, on ne peut pas choisir de répondre à tel ou tel paquet pathologique sous windows, du moins pour le moment ;p Le .reg précédent permet de tromper tous les outils de fingerprint passif comme p0f et permet sous certaines conditions de mettre en déroute nmap. II Detection de systeme UNIX ----------=[ 1/ Remote detection de systeme UNIX Dans un premier temps, la détection de systeme UNIX tend a être plus facile que la distinction de différente version de Windows (avec leurs SP). Je ne vais pas résumer toutes les implémentations qui existent ! Toutefois, un petit tableau comportant quelques OS va vous montrer comme ces système sont facilement distinguable: - La partie ToS peut ne pas aider a identifier un OS. - Les Options TCP sont présenté selon leurs présence / ordres / nombre / valeur. - Le MSS est une option TCP mais nous la traiterons a part du fait qu'on peut dans certains cas se fier à sa valeur pour aider à l'identification. Ce n'est pas toujours le cas puisque sa valeur peut aussi dépendre du type de device avec laquel la connection PPP est initialisée. ________________________________________________________________________________________________________________________ | Os | TTL | WinSize | IP Paquet Lenght | ToS | ID incrementation | DF | MSS | Options TCP | |@@@@@@@@@@@@|@@@@@@@@|@@@@@@@@@|@@@@@@@@@@@@@@@@@@|@@@@@|@@@@@@@@@@@@@@@@@@@|@@@@@|@@@@@@|@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| |Linux 2.2.x | 64 | 32120 | 60 | / | +2 constant | oui | 1460 | SackOK,Timestamp,nop,Wscale | |Linux 2.4.x | 64 | 5840 | 60 | / | +0 | oui | 1460 | SackOK,Timestamp,nop,Wscale | |OBSD =< 2.5 | 64 | 16384 | 64 | / | +1 | oui | 1460 | 2NOP,SackOK,NOP,Wscale,2NOP | |Solaris 7 | 255 | 8760 | 44 | / | +1 | oui | 1460 | aucune (sauf MSS) | |AIX 4.3 | 64 | 16384 | 44 | 0x10| +1 | non | 1460 | aucune (sauf MSS) | |FreeBSD 4.4 | 64 | 16384 | 60 | / | +1 | oui | 1460 | nop,Wscale,2NOP,timestamp | |FreeBSD 5.2 | 64 | 65535 | 44 | / | +1 | oui | NA | nop,nop,timestamp | |Mandrake 10 | 64 |RA: 0 | 60 | / |(+0 on closed port)| oui | NA | SackOK,Timestamp,nop,Wscale | | | |SA: 5840 | | | (+1 on open port) | | | | |____________|________|_________|__________________|_____|___________________|_____|______|_____________________________| On peut, grâce à ces huit différents points, classer les OS de manière assez précise. Remarquez que des implémentations sont assez similaires, mais diffèrent toujours sur un ou deux points, d'ou l'importance comme je l'ai dit, de ne négliger aucun champ dans l'header TCP et IP. Il est ainsi souvent possible, en envoyant seulement un ou deux paquets sur un port ouvert, en positionnant un tas d'option TCP, de savoir en regardant les champs contenus dans la réponse SYN|ACK de connaitre l'OS auquel nous avons à faire. Hping est votre ami, p0f 2 aussi dans la mesure ou il peut faire de la détection d'OS "passive" à partir des réponses de l'host (SYN|ACK, RST, RST|ACK). ----------[ 2/ Masquer un systeme UNIX La détection de systeme unix peut s'averer beaucoup plus compliquée, puisque tous les paramètres cités plus haut peuvent etre modifiés. Des solutions commerciales ou non ont vu le jour proposant de "personnaliser" completement la pile TCP/IP de son système: un des produits gratuits le plus connu et le plus abouti a ce jour est IPpersonnality qui, en introduisant une cible nommée PERS dans la table mangle, permet à l'aide d'une database préconstruite de modifier à la volée pratiquement tous les champs des paquets sortants. Rappellons que la table mangle est utilisée à la base pour modifier certains champs à la volée, comme le TTL, le ToS. Il devient ainsi possible de personnaliser completement le comportement de la pile TCP/IP de sa machine. En l'occurence, les caractéristiques qui peuvent être changées sont: l'incrémentation de l'IP ID, renforcement de l'ISN (et donc réécriture à la volé des numéros de séquence et d'acquittement correspondant à la connexion dont on à modifier l'ISN), la Windows size initial, les options TCP (leurs valeurs, nombre, et ordre); et la possibilité de répondre à certains paquets TCP et UDP pathologiques, ce qui est très intéréssant pour contrer nmap et autres outil d'OS fingerprint :) Je ne vais pas décrire toute l'installation / le fonctionnement d'ippersonality, pour cela je vous recommande de lire la documentation officielle très complète. Toutefois, nous allons émuler un système pris au hasard dans la database de nmap (3.50), en l'occurence Windows XP SP1, dans le but de vous montrer la facilité à "masquer" son système. Nous allons créer ensemble notre propre fichier de configuration ;> /* -*-c-*- Fingerprint Microsoft Windows XP SP1 Class Microsoft | Windows | NT/2K/XP | general purpose TSeq(Class=RI%gcd=<6%SI=<28CC6&>4A2%IPID=I) T1(DF=N%W=402E%ACK=S++%Flags=AS%Ops=MNWNNT) T2(Resp=N) T3(Resp=N) 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(Resp=N) PU(DF=N%TOS=58%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=F%ULEN=134%DAT=E) */ id "Microsoft Windows XP SP1"; tcp { incoming yes; outgoing yes; /* Cela nous permettra d'échapper à des preneurs d'empreinte passif ;> */ max-window 16384; } tcp_isn { type random-inc 80000; initial-value random; } ip_id { type fixed-inc 1; initial-value random; } tcp_options { keep-unknown yes; keep-unused no; isolated-packets yes; code { if (flags(syn) && !flags(fin&urg&push)) { if (option(mss)) copy(mss); if (option(wscale)) { copy(nop); copy(wscale); } } if (option(timestamp)) { copy(nop); copy(nop); copy(timestamp); } } } tcp_decoy { code { if (option(mss)) { if (listen) { if (flags(syn&ece) { /* test 1 de nmap */ set(df,0); set(win,0x402E); set(ack,this + 1); set(flags,ack|syn); insert(mss, this+1); insert(timestamp); copy(wscale); reply; } if (flags(null)) { /* test 2 de nmap */ drop; } if (flags(syn&fin&urg&push)) { /* test 3 de nmap */ drop; } if (ack(0) && flags(ack) && !flags(syn|push|urg|rst)) { /* test 4 de nmap */ set(df,0); set(win,0); set(ack,2); set(flags,rst); reply; } if (flags(syn) && !flags(ack)) {/* test 5 de nmap */ set(ack, this + 1); set(flags, ack|rst); reply; } if (ack(0) && flags(ack) && !flags(syn|push|urg|rst)) { /* test 6 de nmap */ set(ack, 2); set(flags, rst); reply; } if (flags(fin&push&urg)) { /* test 7 de nmap */ drop; } } } } } udp_unreach { reply yes; df no; max-len 56; tos 0; mangle-original { ip-len 328; ip-id same; ip-csum same; udp-len 308; udp-csum same; udp-data same; } } /* -*-c-*- Pour ceux qui ne voudraient pas utiliser la solution ippersonality et répondre seulement a des paquets pathologiques pré-définis, on peut par l'intermédiaire de sysctl régler certains champs ainsi que leurs valeurs. Par exemple: net.ipv4.tcp_sack = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 1 net.ipv4.ip_default_ttl = 64 net.ipv4.tcp_syncookies = 1 Au passage, cet dernière option est intéréssante puisque lors d'un SYN flood le firewall se chargera de répondre au requetes (SYN|ACK) et l'OS ne subira pas le (D)Dos, n'utilisant ainsi aucune ressource de plus qu'en temp normal; le SYN floodeur n'y voyant que du feux ;p De plus, l'utilisation du patch noyau Grsecurity apporte des choses qui peuvent se réveler utiles : Nous pouvons en ce qui nous concerne randomizer completement le champ IP ID (CONFIG_GRKERNSEC_RANDID), à la manière des systèmeS BSD. Les utilisateurs de ce système pourront d'ailleurs utiliser "BSD FingerPrintFucker" (FPF), qui permet comme ippersonnality de changer le comportement de la pile TCP/IP du système dans le but d'émuler d'autre systèmes. III Conclusion & Greetz Voila c'est déja la fin ;p. J'espere que cet article vous aura éclairé un peu plus sur les possibilitées actuel en matière d'OS fingerprint, et vous aura fait prendre conscience que la meilleurs analyse reste celle effectuée non pas par l'outil, mais par la personne qui s'en sert ;> Dans un futur proche, des produits comme ippersonality qui réecrivent des champs à la volé se developperont pour d'autres plateformes, notament pour une question de performance de la pile réseau : modifier directement les champs de l'header TCP et IP à la base de l'OS peut avoir des effets négatifs sur celles-ci. Pour finir, outre le fait que ces manipulations empechent l'identification de notre système et donc freine l'utilisation d'exploits adéquats par une tierce personne, la personnalisation du comportement de la pile TCP/IP de son système peut être un élément constructif dans la mise en place de honeypots ou de honeynets. De plus, pour accentuer cette sécurité par obscuration, il est important de ne pas oublier de modifier les bannières (http, ftp par exemple) des services tournant sur votre système. Pour toute remarques / critiques / corrections (je suis souvent tête en l'air et donc pas a l'abrit d'erreurs) / -> jacob@dg-sc.org; on me transmettra ;p Greetz to degenere-science & phrack-fr crou, paparo0t, kUR1G3n, et ceux que j'oublie. ch. I love U References: http://ippersonality.sourceforge.net/doc/ippersonality-fr.html Home page d'ippersonality http://www.support.microsoft.com/default.aspx?scid=kb%3ben-us%3b224829 Description of Windows 2000 TCP Features http://ouah.kernsh.org/incosfingerp.htm Descriptions de divers champs dans l'header TCP et IP, dans différent OS. |-----------------------------------------------------------------------EOF|