--------------------------------------------------------------------
--------------------------------------------------------------------
1.0. Introduction

2.0. Etude de faisabilité.
    2.1. Génération d'ISN de différents systèmes d'exploitation.
        2.1.1. Développement du programme Analysor.
        2.1.2. Acquisition des données.
    2.2. Analyse des données.
        2.2.1. Graphiques.
        2.2.2. Régressions linéaires.

3.0. Description de l'attaque.
    3.1. Premier type d'attaque: prédiction par régression linéaire.
        3.1.1. Tests contre Windows 98.
        3.1.2. Résultats, remarques.
    3.2. Attaque plus évoluée: méthode statistique d'étude des générateurs aléatoires.
        3.2.1. Spacial Phase Analysis.
        3.2.2. Dévellopement de l'utilitaire Blindy.

4.0. Modification du générateur de nombre pseudo aléatoires du noyeau Linux.

5.0. Bibliographie.

6.0. Remerciements.
--------------------------------------------------------------------
--------------------------------------------------------------------
 
 
 

1.0. Introduction.

    L'Ip spoofing est une attaque bien connue dans son principe de nos jours, c'est pourquoi je ne reviendrai pas sur une explication qui a déja été faite de nombreuses fois. Je m'atarderai ici dans une explication plus applicative en m'appuyant sur mes recherches personnelles dans ce domaine.
    La première partie de cette attaque consiste en une étude de la génération des ISN de différents systèmes d'exploitations. Dans un premier temps j'ai réalisé un utililitaire destiné à étudier la génération d'ISN par différents systèmes d'exploitation. A partir des résultats obtenus j'ai pu juger de la difficulté de l'attaque suivant les systèmes d'exploitation et ainsi pouvoir déterminer une méthode grossière de prédiction des ISNs qui m'a permis de réussir l'attaque sur des systèmes d'exploitation de type Win98. Enfin, j'ai amélioré ce code en utilisant une méthode mathématique beaucoups plus évoluée qui m'a permis d'attaquer d'autres systèmes d'exploitation.
 
 
 
 

2.0. Etude de faisabilité.
    2.1. Génération d'ISN de différents systèmes d'exploitation.
       2.1.1. Développement du programme Analysor.

    A l'époque de la parution de l'article "IP Spoofing Demystified" [1] les générateurs d'ISN des systèmes d'exploitaion étaient dépendants de seulement deux variables qui sont le temps et le nombre de connexion. Ceci permettait de prévoir trés facilement par un simple calcul mathématique la valeur d'un ISN à partir de celle d'un ISN précédemment acquis. L'ISN augmentait de 128000 chaque seconde et de 64000 à chaque nouvelle connexion. En réalisant l'attaque rapidement on pouvait considérer qu'aucune connexion ne serai établie et cela rendait donc la prédiction d'ISN assez triviale.
    Une première phase d'étude consistait donc a étudier la génération d'ISN de plusieurs systèmes d'exploitation de manière à établir des corrélation entre le temps et l'évolution des ISN. Pour cela j'ai dévellopé un utilitaire nommé Analysor [2] dont un des modes de fonctionnement permet de créer des listes de valeurs d'ISNs en fonction du temps.
 
 

    Dans l'état actuel Analysor possède 3 modes de fonctionnement symbolisés par les options -j, -k et -m. La première des options à avoir été implémentée est l'option -j qui permet d'obtenir 2 colonnes de nombres qui représentent d'une part le temps écoulé depuis le début de l'expérience, et d'autre part la valeur de l'ISN de la cible. Ce formatage permet de tracer des graphiques a l'aide de l'utilitaire Gnuplot. Le schéma de fonctionnement de l'option -j est le suivant:

1/ Analysor:    A------>B
                           Syn

2/ Analysor:    A<------B
                         Syn/Ack

3/ Kernel:        A------>B
                            Rst

    Le fonctionnement est donc assez simple: on envoie un Syn, le serveur nous Ack/Syn en nous donnant une valeur d'ISN puis notre Kernel émet tout seul un Rst car il n'a pas été averti de l'ouverture d'une connexion et il pense donc que ce Ack/Syn n'a pas à être recu. Le fait que le Kernel envoye tout seul ce Rst est assez pratique car il permet de fermer automatiquement la demande de connexion engendrée pas le Syn. Si ce Rst ne partait pas, la connexion se retrouverai dans un état 'semi-établi', ce qui entrainerai en cas de nombreuses réitération du schéma précedent une forte consommation des resources du côté de l'host B. Le phénomène précédent est utilisé dans un des type d'attaque DoS nommé le Syn Flood. Cependant l'effet recherché ici n'est pas le DoS et de plus mieux vaut rester discret durant la phase d'étude.
 
 

       2.1.2. Acquisition des données.
 
 

    J'ai testé Analysor sur les différents systèmes d'exploitation que j'avais sous la main de manière à déterminer le plus vulnérable à l'Ip Spoofing. Le test consiste en l'envoie de 1000 paquets à intervalles réguliers de 20000 µs. A l'aide de ces 1000 ISNs récoltés pour chaque système d'exploitation il est possible de tracer des graphiques donnant une allure générale de l'évolution des ISNs en fonction de temps.
    On redirige la sortie standart d'Analysor afin de récupérer les infos dans des fichiers.
 
 

    2.2. Analyse des données.
     2.2.1. Graphiques.
 
 
 

    A l'aide de l'utilitaire Gnuplot il est possible de se donner une représentation plus explicite des résultats obtenus à l'aide de Analysor. On trace tout d'abord des graphiques distincts pour chaque système d'exploitation de manière à se donner une idée générale de l'évolution des ISNs sur ces systèmes d'exploitation. Enfin, on représente toutes les courbes sur un même graphique ce qui nous permet de constater les lacunes et les aventages qu'ont chaque système d'exploitation par rapport aux autres.

    Les tests on été réalisés sur un réseau ethernet 100 Mb/s avec 2 machines reliées par cable RJ45 croisé.
 
 

    Analyse:
        - Amplitude = 4.25e+09 - 2.2e+09
                          = 2.05e+09

            Cette valeur de l'amplitude représente la moitié de la plage dans laquelle peut se situer un ISN. Le générateur aléatoire d'OpenBSD 2.9 utilise donc assez bien les 32 bits attribués à un ISN.

        - Les ISNs sont stoqués sur 32 bits et sont des nombres non signés, un calcul rapide nous donne la valeur maximale que peut avoir un ISN: 2^32 = 42949667296. OpenBSD 2.9 génère donc des valeurs d'ISN qui atteignent le maximum.

        - On vois que la valeur des ISNs passe d'une valeur minimale a une valeur maximale très rapidement. L'évolution générale n'étant pas monotone cette dernière remarque assure avec les deux précédentes une robustesse assez acrue pour le générateur aléatoire d'OpenBSD 2.9.
 

    Commetaire:

         OpenBSD 2.9 démontre ici toutes sa puissance dans le domaine de la sécurité. Ce système puise sa robustesse à l'aide de l'audit du code source, mais aussi à l'aide d'une très bonne gestion de la cryptographie [4]. Les algorithmes cryptographiques nécessitent des nombres aléatoires, on ne s'étonne donc pas de voir que le générateur aléatoire d'OpenBSD 2.9 soit trés fiable. Ce dernier utilise plusieurs sources d'entropie :
    - délais entre les interruption de la souris
    - délais entre les packets réseaux échangés,
    - délais entre l'appuie sur les touches du clavier
    - accés au périphériques de bloc comme les disque durs
 
 

    Analyse:
            - Amplitude = 3.629e+09 - 3.614e+09
                           = 15e+06

            Les ISNs évoluent rapidement sur une plage de 15 millions de valeurs ce qui reste tout à fait acceptable. De plus cette évolution pas à pas n'est pas monotone: la valeur augmente puis elle décroit.

        - L'allure générale de l'évolution de la génération d'ISN est ici monotone croissante ce qui permet de renforcer (très légèrement) la robustesse du générateur aléatoire de Linux.
 

    Commetaire:

    Linux possède un générateur de nombre pseudo aléatoires de bonne qualité. Bien qu'il n'atteigne pas le niveau de celui d'OpenBSD 2.9, il permet de rendre trés difficile, voir presque impraticable les attaques de type Bliind Ip Spoofing. Cependant la team Teso a publié une advisorie en 1999 qui semble prouver la possibilité d'une telle attaque sur des noyeaux 2.2.x [5]. Les noyeaux 2.2.x en étaient à leurs premières releases à cette époque et je pense que la version 2.2.16 ne possède pas le même générateur pseudo-aléatoire. Nous reviendrons sur ce fait un peu plus en étudiant une autre des fonctionnalitées d'Analysor.
    Lorsque l'on regarde la source du générateur aléatoire qui se situe dans /usr/src/linux/drivers/char/random.c on peut se rendre compte compte de l'effort qui à été fait pour qu'il soit robuste. Voici une petit description qui se situe dans l'entête de ce fichier:

       "Les évènements aléatoire qui sont puisés dans l'environnement incluent les délais entre l'appuie sur les touches du clavier, les délais entre le déclenchement de diverses intéruptions et d'autres évènements qui sont (a) non-déterministes et (b) difficiles à observer par un observateur extérieur. Ces différentes données sont mixées a l'aide d'un algorithme du style CRC de manière à obtenir un pool d'entropie.
        ...............
        Quand le système nécessite des octets générés aléatoirement, le générateur aléatoire les lui fournit en prenant un hash SHA du contenu du pool d'entropie obtenu précédemment. L'utilisation du hash SHA permet de ne pas exposer l'état interne du pool d'entropie. Il est de nos jours impossible de retrouver l'antécédent d'un hash SHA.
        ...............
        Même si le pool d'entropie devien nul, le générateur aléatoire produira toujours des nombres; toutefois, un attaquand pourrai (du moins en théorie) déduire les futurs nombres qui seront générés à partir de nombres générés précédemment. Ceci nécessite un casage du SHA, qui est censé être infaisable, mais il subsite une possibilité. Néanmoins, ces nombres devraient être utiles dans la plupart des applications."

        Ce texte prouve bien que Linux possède un bon générateur de nombre pseudo aléatoires même si on sais bien que le risque 0 n'existe jamais en sécurité informatique.
 
 

    Analyse:
            - Amplitude = 0  (c'est une ligne droite)

            - Les ISNs évoluent linéairement (et lentement) avec le temps. De plus, les valeurs d'ISNs sont peu élevées

    Commentaire:

        Le générateur n'est pas aléatoire, il dépend implicitement du temps et évolue lentement avec ce dernier. Ceci engendre la possibilité d'une attaque de Blind Spoofing. Comme chacun sait, les sources de Windows ne sont pas libre, mais à la vue de cette courbe on imagine facilement l'allure de la fonction et surtout l'incompétence des développeurs qui l'ont codé.
 
 

        Ce dernier graphique permet de comparer les différents générateurs de nombres pseudo-aléatoire entre eux. On vois bien qu'OpenBSD possède le plus robuste. Linux bien que possédant un bon générateur aléatoire lui permettant de se mettre a l'abris de la plupart des attaques est quand même bien loin d'OpenBSD. Enfin, Windows 98 est ridicule avec un générateur qui ne décolle même pas et dont on a du mal à différencier la courbe avec l'axe des absices.
 
 
 

        2.2.2. Régressions linéaires.

        Cette méthode mathématique permet de remonter a l'équation d'une droite à partir d'un ensemble de coordonnées. Dans le cas de la génération d'ISNs de Windows 98 cette méthode peut permettre de trouver le coefficient directeur de la droite et donc de rendre ainsi complètement prévisible les valeurs des ISNs futurs.
        A partir de deux liste de nombres {xi} et {yi} (i=1..n) on obtient une équation de droite de la forme y = b0 + b1 * x  avec :
 
 

         n           n               n        n
        ---    2    ---             ---      ---
        \   x       \     y     -   \   x    \    x  y
        /    i      /       i       /    i   /     i  i
        ---         ---             ---      ---
        i=1         i=1             i=1      i=1

b0 =   -------------------------------------------------

                    n                   n
                   ---    2            ---       2
               n   \    x       -    ( \     x )
                   /     i             /      i
                   ---                 ---
                   i=1                 i=1
 
 

                         n                          n               n
                       ---                      ---          ---
                  n    \      x   y       -     \      x        \       y
                        /        i    i             /        i       /         i
                       ---                      ---          ---
                         i=1                       i=1            i=1

b1 =     ----------------------------------------

                                  n                          n
                                ---     2               ---       2
                            n   \      x         -     (  \     x   )
                                 /        i                  /       i
                                ---                      ---
                                 i=1                        i=1
 

        On peut évaluer l'erreur qu'il existe entre les valeurs expérimentales et la droite déterminée par régression à l'aide d'un nombre appelé coefficient de corrélation. Ce nombre est compris entre 0 et 1 et il est égal a 1 lorsque toutes les valeurs expérimentales apartiennent à la droite dont l'équation a été déterminée par régression. On calcule ce nombre à l'aide de la formule suivante:
                                                                        _______________________________________________________________
     \                        /                 n                                    \
      \                      /                 ---    ^       _   2
       \                    /                  \    ( y   -   y )
        \                  /                   /       i       i
         \                /                    ---
          \              /                     i=1
r  =       \            /       -----------------------------------------------------
            \          /          n                              n
             \        /          ---    ^       _   2           ---             ^   2
              \      /           \    ( y   -   y )       +     \     ( y   -   y )
               \    /            /       i      i               /        i       i
                \  /             ---                            ---
                 \/              i=1                            i=1
 

Où:  {yi} = valeurs expérimentales
        _
        yi  = moyenne des valeurs expérimentales
        ^                                                                                                           ^
        yi = valeurs calculée avec l'équation de la droite determinée par régression:  yi = b0 + b1 * xi
 

        Aprés cette petite parenthèse mathématique, nous allons appliquer cette technique aux valeurs obtenues précédemment avec Analysor pour Windows 98. J'ai dévelopé pour cela un petit script Tcl  qui donne l'équation de la droite ainsi que son coefficient de corrélation.
 
 
 

        On obtient donc une droite de pente environs égale à 1000 ce qui signifie dans notre cas (étude de la génération des ISNs en fonction du temps: ISN = f(t) ) que la valeur de l'ISN augmente de 1000 à chaque seconde qui s'écoule. On peut donc prédire très précisément la valeur d'ISNs futurs à partir d'un seul ISN récupérer.
 
 

3.0. Description de l'attaque.
    3.1. Premier type d'attaque: prédiction par regression linéaire.
    3.1.1. Tests contre Windows 98.

    Aprés les remarques des paragraphes précédents, une première série de tests va être réalisée contre un Windows 98. Pour cela j'ai coder un petit serveur en Tcl [6] qui écoute sur un port et affiche l'IP de l'host distant qui s'y connecte. Ceci permettra de vérifier la réussite de l'attaque.
    D'aprés le paragraphe 2.2.2 nous avons :

        i = b0 + b1 * t    avec b0 et b1 constantes, i l'ISN et t le temps
      di = b1 * dt          en différenciant l'équation

    On en déduis donc que pour une variation de temps donnée dt on obtient toujours une même variation de valeur d'ISN. Ceci nous conduit a utiliser l'option -m d'Autoroute qui permet de calculer une valeur moyenne de l'augmentation d'ISNs obtenus après l'envoie de deux Syn consécutifs.
Voici les différentes étapes de l'attaque:

1/ Calcul de l'augmentation de la valeur d'ISNs entre deux Syns consécutifs: m

2/ Envoie d'un Syn non spoofé de manière à récupérer la valeur du premier ISN: isn1

3/ On attend pendant un temps t (le même que celui passé en paramètre a Analysor)

4/ Envoie d'un Syn spoofé.

5/ Calcul d'une valeur possible pour isn2
    isn2 = isn1 + m + perturbations
    les perturabations sont dues à plusieurs facteurs comme par exemple la rapidité d'échange sur le réseau sui n'est pas toujours parfaitement constante. De manière à ne pas se soucier de ces perturbations, nous allons réaliser plusieurs tentatives en prenant des valeurs comprises entre + ou - une valeur que l'on précisera.

6/ On réalise le brute force de Ack avec toutes les valeurs comprises dans la plage prédite:
    brute force sur toutes le valeurs d'isn telles que isn1 + m - plage <= isn <= isn1 + m +plage
 

    J'ai codé un script Tcl spoof.tcl [7] qui permet d'automatiser ce processus. La moyenne sera calculée avec l'option -m de Analysor et les paquets seront envoyés avec l'utilitaire nemesis [8] qui permet d'envoyer des paquets forgés en ligne de commande.
    Spoof.tcl prend 7 paramètres qui sont dans l'ordre: l'ip spoofée, votre ip réelle, le port source, l'ip de destination, le port de destination, l'interface réseau à utiliser et enfin la plage de valeurs pour le bruteforce.
 
 

        Et du côté Windows 98 ......
 

       3.1.2. Résultats, remarques.

    Lors de l'attaque précédente, nous tentons d'établir une connexion spoofée (avec une adresse source 192.168.0.18 qui n'existe pas sur le réseau local et un port source 1500) vers le port 2000 du serveur qui tourne sur le Windows 98 qui a pour IP 192.168.0.1 . L'attaque se fait via l'interface réseau eth0 et la plage de valeurs pour le bruteforce est de 2. J'ai réalisé plusieurs tests en commençant avec une valeur de 100 et en la diminuant jusqu'à ce que l'attaque ne réussisse plus. Cette valeur de 2 démontre que spoof.tcl prédit la valeur de l'ISN + ou - 1. Bien entendu le test à été réalisé sur un reseau 100 Mbit/s donc les conditions sont parfaites, dans le cas d'attaques sur des réseaux plus lents il faudra augmenter la valeur de la plage de manière à ce que l'attaque réussisse.
 

3.2. Attaque plus évoluée: méthode statistique d'étude des générateurs aléatoires.
    3.2.1. Spacial Phase Analysis.

    L'esemble de ce paragraphe s'appuie sur les recherche qu'à effectuer Michal Zalewski et qu'il présente dans son texte Strange Attractors and TCP/IP Sequence Number Analysis [9].
    L'analyse de phase spaciale est utilisée dans l'étude des systèmes dynamiques et notamment des systémes non-linéaires.Elle permet de représenter l'évolution d'un système de n variables dans un espace de dimension n. Le choix de la dimension n ne peut être prédit que par tests successif et vérification de la validité des résultats obtenus. Michal Zalewski semble avoir adopté une dimension de 3, nous allons donc lui faire confiance dans son choix et garder cette dimension. Le lecteur intéressé pourra réaliser des tests avec des dimensions supérieures à 3.
    Nous allons donc utiliser cette technique pour représenter en 3D l'évolution des ISN en fontion du temps. Pour cela nous allons utiliser des points de l'espace qui caractérisentent 4 ISNs générés conécutivement et à intervalle régulier. Ainsi le systéme est régi par les équations suivantes:

     x (t) = isn (t-2) - isn (t-3)
     y (t) = isn (t-1) - isn (t-2)
     z (t) = isn (t)     - isn (t-1)

    A partir de l'ensemble des valeurs d'ISNs que nous avon récupérés dans un fichier à l'aide Analysor (option -k), nous pouvons déterminer l'ensemble des coordonnées des points et ainsi les représenter dans l'espace.
    Si la représentation graphique présente de fortes concentration de points dans des parties bien détermninées de l'espace on pourra dire que le systéme présente les caractéristique d'un attracteur puissant.

    Toute notre stratégie va s'appuyer sur le fait que si une séquence présente des caractéristiques d'attracteur puissant, les valeurs qui seront générées dans le futur seront proche des valeurs utilisées pour construire les points précédents de l'attracteur.
 

    3.2.2. Dévellopement de l'utilitaire Blindy.

    Ce paragraphe détaille le fonctionnement interne de l'utilitaire Blindy [10].

    Supposons que l'on récupère 3 ISNs consécutifs à intervalle de temps régulier, nous aurons donc isn (t-3), isn (t-2) et isn (t-1). A l'aide de ces 3 valeurs nous obtenons les coordonnées x (t) et y (t). Si nous pouvons déterminer z (t) alors nous aurons par la même occasion la valeur isn (t) qui est celle qui nous intéresse puisqu'elle correspond a l'isn qui va être généré au prochain intervalle de temps par le générateur de nombre pseudo aléatoires. Nous allons donc chercher dans notre liste d'ISN des points qui possèdent les mêmes coordonnée x et y que le point dont nous essayons de déterminer z. Ainsi, d'aprés la constatation précédente sur les attracteurs, nous pourrons dire que la valeur z de notre point est proche de celle trouvées dans notre list. Bien entendu, il sera trés rare de trouver des points de la liste qui ont exactement les mêmes x et y, il faudra donc fixer une valeur de tolérence qui sera représentée dans Blindy pas la valeur R1.

    Une fois que l'on a parcouru toute la liste et que l'on a récupérer l'ensemble des valeurs de z (donc de isn(t)) acceptables, on va pouvoir les essayer une par une pack Acquiter notre Syn et établir la connexion. De manière a ce que l'attaque ai plus de chances de réussite on réalisera un brute force sur des plages de valeurs isn_predit - R2 < isn < isn_prédit + R2. Cette valeur R2 sera a déterminer par l'utilisateur selons l'OS attaqué.
 
 

     No Comment .....
 
 

4.0. Modification du générateur de nombre pseudo aléatoires du noyeau Linux.

    Nous avons vu dans la partie 2.2.1 que le générateur du noyeau Linux est assez fiable car il s'appuyait sur des évènements déclenchés aléatoirement par le matériel. Ce sont les interruptions matérielles qui sont les plus utilisées pour ce genre de chose.
    Lorsque l'on réserve une ligne d'interruption dans le code d'un driver il faut utiliser la fontion suivante:

    int request_irq(unsigned int irq,
               void (*handler)(int, void *, struct pt_regs *),
               unsigned long flags,
               const char *dev_name,
               void *dev_id);

    Le paramètre flags peut prendre la valeur SA_SAMPLE_RANDOM qui indique que le matériel déclenche des interruption aléatoirement et que celles-ci peuvent être ajoutées au pool d'entropie qui permet de générer des nombres pseudo aléatoires. Un grep -r SA_SAMPLE_RANDOM * dans les sources du noyeau nous montrera son utilisation dans des drivers tels que les cartes réseau.
 

    Nous avons adopté une méthode différente de manière à enrichir le pool d'entropie. En effet, nous avons émis l'hypothèse que les valeurs contenues dans la mémoire (stack ou proche de la stack) pouvaient être considérées comme aléatoires. Bien entendu tout ce qui va suivre va s'appuyer sur cette hypothèse qui n'est pas confirmée, nous somme donc ouverts a toute remarque.
    Nous avons ajouter une fonction au fichier random.c du noyeau. Cette fonction permet de renvoyer la valeur contenue a un emplacement mémoire (stack ou proche de la stack) qui a lui même été déterminer aléatoirement grâce au générateur d'origine du noyeau. La valeur obtenue avec cette fonction est ajoutée a la valeur qui aurai été générée par le générateur d'origine du noyeau.
    Le seul test de fiabilité que nous avons réalisé est celui de nmap. Nous obtenons une difficulté maximale au test d'attaque par ip spoofing, tout comme lorsque l'on teste un OpenBsd 2.9, de plus le patch [11] est très stable et à été longuement testé sans aucun problème. Je vous invite donc à l'essayer et à nous commenter votre expérience personnelle.
 
 

5.0 Bibliographie et Codes.

[1]   IP-spoofing Demystified, by daemon9 / route / infinity.
[2]   Analysor by truff.
[3]   Gunplot by Thomas Williams, by Colin Kelley and many others.
[4]  OpenBSD Cryptography.
[5]   Linux 2.2.x ISN Vulnerability, by Teso.
[6]   Server.tcl  by truff.
[7]   Spoof.tcl  by truff.
[8]   Nemesis  by obecian.
[9]   Strange Attractors and TCP/IP Sequence Number Analysis  by Michal Zalewski.
[10]  Blindy  by truff.
[11]  isnpatch  by truff & climax.
 
 
 

6.0 Remerciements.

    Tout d'abord un grand merci a tous les membres de projet7 qui m'ont aider tout au long de la réalisation de ce projet. Merci aussi à toutes les personnes que j'ai _légèrement_ dérangées pour effectuer des tests en remote: Caps, Quoi, RLV, lawine, Crying .... et j'en oublie surement. Merci aussi a Michal Zalewski pour m'avoir éclairer avec son magnifique article sur les attracteurs. Et enfin, un gros bisou à la ravissante et adorable blonde qui m'a tenu compagnie en /query pendant l'écriture de ce texte.
 
 

7.0 Copyright.

    Ce texte peut être redistribué librement du moment qu'il reste dans son intégralité et que le nom des auteur du texte et des codes aparait.