Dans ce chapitre, nous allons parler d’une attaque réseau parmi les plus connues. Des livres ont été écrits sur celle-ci, et plusieurs films ont été tournés pour relater l’histoire de celui qui l’a popularisée, Kevin Mitnick. Il n’a pourtant que mis en pratique une attaque élaborée des années auparavant par un génie des réseaux, M. Robert Tappan Morris, aussi connu pour son célèbre ver qui paralysa accidentellement une bonne partie d’Internet en 1988.
Nous allons donc dans ce chapitre à la fois suivre une histoire et une attaque très technique de sécurité.
L’attaque de Noël
Kevin Mitnick adorait pénétrer les systèmes informatiques et au début des années 1990, il a déjà fait quelques mois de prison et est un fugitif recherché par la police et le FBI pour plusieurs actes informatiques et téléphoniques illégaux.
En 1994, alors qu’il est encore en fuite, il décide de s’en prendre à un autre hacker reconnu qu’est Tsutomu Shimomura, et essaye de pénétrer un de ses ordinateurs.
Le problème est le suivant :
Mitnick sait qu’un certain serveur appartenant à Shimomura, sur lequel il y a des informations intéressantes à récupérer, peut être joint directement par une autre machine sur Internet sans fournir de mot de passe en fonction de son adresse IP.
Mitnick sait alors que s’il arrive à se faire passer pour la machine avec une certaine adresse IP, il pourra se connecter au serveur et récupérer les documents dont il a besoin. Il doit alors mettre en place une attaque de spoofing de l’adresse IP (ou usurpation de l’adresse IP en français).
Seulement, ce genre d’attaque n’existe pas. Ou plus exactement, il en existe une, mais celle-ci n’a été expliquée que théoriquement et n’a jamais été mise en pratique. C’est Robert Morris qui l’a décrite en 1985, soit quasiment 10 ans avant !
Maintenant que Mitnick possède l’attaque, il ne lui reste plus qu’à la mettre en œuvre. Sachant que Shimomura n’est pas le premier venu au niveau des compétences informatiques, Mitnick se méfie et décide d’effectuer son attaque un jour où il y a de grandes chances que Shimomura ne soit pas présent devant son ordinateur, soit le soir de Noël 1994...
La théorie de l’attaque
L’idée est donc de se faire passer pour une autre machine vis-à-vis du serveur.
Voici le schéma qui représente le réseau :
La machine qui est autorisée peut donc accéder au serveur sans avoir à fournir de mot de passe, l’authentification se faisant par son adresse IP.
Mitnick doit donc se faire passer pour cette machine qui a l’adresse @IP A s’il veut pouvoir se connecter au serveur. Pour initialiser sa connexion, il doit envoyer un SYN en se faisant passer pour A.
Que va-t-il se passer ensuite ?
Le serveur va recevoir un segment SYN de la seule machine autorisée à lui parler.
Il va donc lui répondre avec un segment SYN+ACK.
Il ne reste plus à Mitnick qu’à renvoyer un segment avec ACK pour finaliser le three way handshake !
En fait, Mitnick ne peut pas renvoyer un segment ACK correct aussi simplement. Et cela est dû à un mécanisme qui n’a rien à voir avec la sécurité, mais qui pourtant rend très difficile une attaque par blind spoofing, le suivi de connexion TCP...
En effet, quand le premier SYN est envoyé, Mitnick ou sa machine choisit le numéro de séquence et met le numéro d’acquittement à 0.
Le serveur répond à la machine A en mettant son propre numéro de séquence, et ça, Mitnick ne peut pas le connaître, puisque le segment est allé à la machine A.
Mitnick doit donc envoyer un segment ACK pour finir le three way handshake, mais il ne sait pas quel numéro d’acquittement positionner, vu qu’il n’a pas connaissance du numéro de séquence envoyé par le serveur. Il devrait indiquer le numéro de séquence reçu+1, mais il ne l’a jamais reçu...
Il a quand même le choix entre valeurs possibles... Autant jouer au loto.
Et pourtant, il va réussir cette attaque grâce à une faille du protocole TCP.
La faille de l’ISN et le non-respect de la RFC
Comme je vous l’ai dit dans le chapitre précédent, l’ISN est choisi aléatoirement. Cependant, cela n’a pas toujours été le cas...
À l’origine, l’ISN était dépendant d’un compteur calculé en permanence par un ordinateur. En gros, quand l’ordinateur démarrait, un compteur démarrait à 0 et la RFC 793 qui définit TCP disait que ce compteur devait être incrémenté de 1 toutes les 4 microsecondes. Les constructeurs qui voulaient une solution plus simple ont incrémenté ce compteur de 128 000 toutes les secondes, ce qui n’est pas tout à fait équivalent, mais du même ordre de grandeur.
Par ailleurs, ce compteur était aussi augmenté de 64 000 ou 128 000 pour chaque connexion TCP qui était créée.
Ainsi, quand une connexion TCP commençait ou qu’une machine recevait un premier SYN et devait y répondre en indiquant son ISN, elle allait regarder la valeur du compteur à cet instant et prenait cette valeur comme ISN.
Notamment, si l’on connaissait l’ISN d’une machine à un instant t, on pouvait en déduire la valeur du compteur. En fonction du temps qui s’était écoulé, on pouvait imaginer la valeur du compteur et donc potentiellement celui de l’ISN d’une nouvelle connexion !
Vous pouvez déjà commencer à imaginer comment Mitnick a pu s’y prendre.
Comment connaître le compteur du serveur ?
Pour pouvoir trouver l’ISN qu’envoie le serveur, il faut que Mitnick connaisse cet ISN à un instant t, puis il pourra déterminer le temps qui s’écoule depuis cet instant pour trouver l’ISN à un autre moment. Si jamais le serveur réalise une nouvelle connexion TCP pendant ce temps, il faudra ajouter 64 000 ou 128 000 au résultat calculé. Cependant, le jour de Noël, on peut imaginer que le serveur n’est pas trop sollicité.
Si par exemple Mitnick connaît une valeur d’ISN correspondant à 22 h 42 et 32 secondes qui vaut 2 752 000, s’il veut lancer son attaque 30 secondes après, il sait que l’ISN vaudra :
2 752 000 + (30 * 64 000) = 4 672 000
Et hop ! il pourra envoyer le segment ACK avec le bon numéro d’acquittement.
Mais... il y a toujours un mais.
Comment Mitnick peut-il connaître l’ISN du serveur ?
C’est en fait assez simple : il suffit de lui envoyer un segment SYN sur un port TCP sur lequel il répondra. À l’époque, il y avait par exemple le port login qui était souvent activé et accessible.
Donc Mitnick envoie un segment SYN provenant de sa propre machine sur un port ouvert et accessible du serveur, il reçoit le segment SYN+ACK du serveur qui contient alors son ISN à cet instant. Il pourra alors ensuite lancer son attaque avec la connaissance de cet ISN en faisant le calcul précédent.
Tout est prêt pour récapituler l’attaque et la lancer... ou pas.
Faites-moi taire cette machine !
Nous avons a priori tout ce qu’il faut pour mener l’attaque. Pourtant, elle ne marchera pas telle quelle, car nous avons oublié quelque chose.
En effet, si Mitnick lance l’attaque, il enverra son premier SYN pour avoir la valeur du compteur à l’instant t. Il commencera ensuite son attaque en envoyant un segment SYN en se faisant passer pour A, et le serveur répondra avec un segment SYN + ACK à A.
Et là, badaboum !
La machine A, qui n’a rien demandé à personne, reçoit un segment SYN + ACK venu de nulle part. Comme vous maîtrisez parfaitement le comportement d’une connexion TCP, vous savez qu’elle doit répondre par un segment RST pour dire à la machine serveur : "Ça ne va pas, ou quoi ? Je ne t’ai rien demandé !"
Le serveur recevant le RST va fermer la connexion, et Mitnick aura beau envoyer un segment ACK avec le bon numéro d’acquittement, il tombera sur une connexion close. Tout ça pour ça...
Mais il y a encore une solution à cela !
Il faut faire taire la machine A pour qu’elle n’envoie pas le RST et que le serveur ne ferme pas sa connexion. À l’époque, on pouvait faire taire une machine en mettant en place ce que l’on appelle un flood (ou raz de marée en français), et notamment, en TCP, un SYN flood.
L’idée est d’envoyer énormément de segments SYN sur le port ouvert d’une machine pour que celle-ci ne puisse plus répondre.
Principe du SYN flood
Le déroulement normal du démarrage d’une connexion TCP est le three way handshake, SYN, SYN + ACK, ACK.
Par contre, si l’on se contente d’envoyer un SYN sans répondre au SYN + ACK qui va suivre, le serveur en face va allouer des ressources pour attendre notre réponse jusqu’au dépassement d’un délai d’expiration.
Si l’on envoie alors une multitude de paquets SYN, le serveur va allouer beaucoup de ressources en attente pour nous répondre, alors que notre réponse ne viendra jamais. Si l’on envoie assez de SYN pour saturer les ressources du serveur, notre SYN flood sera réussi et le serveur ne sera plus capable de répondre à de nouvelles demandes de connexions.
Retour à notre attaque
Donc Mitnick peut réaliser un SYN flood vers la machine A pour que celle-ci ne puisse pas répondre au segment SYN + ACK que le serveur va renvoyer. Nous avons maintenant tout ce qu’il faut pour mener à bien notre attaque !
Déroulement complet de l’attaque
Nous sommes donc prêts à réaliser l’attaque, ou plutôt, Mitnick l’était.
Nous allons donc la refaire pas à pas pour que vous compreniez bien le fonctionnement de celle-ci, ainsi que la complexité de la mettre en œuvre. Il faut savoir cependant que Mitnick a utilisé un programme pour que toutes ces commandes se réalisent les unes après les autres dans un temps record, notamment pour la prédiction des ISN du serveur.
1- On flood la machine A
Mitnick lance son attaque SYN flood vers la machine A afin de la rendre injoignable sur le réseau et de l’empêcher de répondre par la suite.
2- On récupère l’ISN du serveur à un instant t
Mitnick envoie simplement quelques segments SYN au serveur afin de voir de combien ils sont augmentés. Il pourra alors lire dans les segments SYN + ACK de réponse la valeur du numéro de séquence au moment où le serveur les aura émis. Et il se rendra compte que l’augmentation de l’ISN du serveur est de 128 000 entre chaque connexion.
Mitnick répète l’opération dans la même seconde pour connaître la différence entre les numéros de séquence du serveur. Je ne remets pas ici le schéma pour l’envoi du SYN.
3- On envoie un faux segment SYN au serveur en se faisant passer pour la machine A
Juste après l’étape précédente, le programme de Mitnick continue l’attaque à proprement parler en se faisant passer pour la machine A. Le serveur va recevoir cette demande d’ouverture de connexion et va logiquement répondre avec un segment SYN + ACK à la machine A, en ayant choisi un ISN qui sera augmenté de 128 000 par rapport à la précédente requête qui est arrivée dans la même seconde grâce au programme.
4- On envoie un segment ACK de réponse avec le bon numéro d’acquittement
Le programme n’a plus qu’à renvoyer le segment ACK avec le bon numéro de séquence, toujours en se faisant passer pour la machine A.
5- Le serveur valide la connexion
Le serveur ayant reçu un segment avec un numéro d’acquittement correct valide la mise en place de la connexion avec le three way handshake.
Nous avons donc réussi à nous faire passer pour la machine A et il y a désormais une connexion établie entre le serveur et la machine A, youpi !
Mais que peut-on réellement faire avec cette connexion ?
C’est une excellente question !
A priori, nous ne pourrons pas en faire grand-chose, car dès que le serveur va répondre avec un certain nombre d’octets à la machine A, nous n’en saurons rien et ne pourrons pas connaître l’évolution du numéro de séquence du serveur. Nous ne pourrons donc pas maintenir cette connexion active.
Tout ce travail pour rien ?
En fait non, Mitnick ne se serait pas donné tout ce mal si cela ne l’avait mené à rien.
Il va réaliser une attaque qui peut se réaliser avec l’envoi d’un seul et unique paquet. Une fois la connexion établie, il peut donc envoyer ce paquet, qui sera le seul, mais cela est suffisant.
Il a donc suffi a Mitnick d’envoyer la commande echo ++ >/.rhosts.
Cela écrase le fichier .rhosts et met ++ dedans. Cela revient à dire que n’importe quelle machine a le droit de se connecter au serveur, quelle que soit son adresse IP...
Mitnick s’est donc donné un accès complet au serveur depuis n’importe quelle adresse IP, et donc notamment la sienne. Il peut maintenant librement se connecter sur le serveur et récupérer tout ce qu’il veut.
Conclusion
Nous venons de voir une attaque assez complexe, notamment dans sa réalisation. Ne vous inquiétez pas, il en existe de plus complexes.
Mais il en existe surtout de plus simples.
Cependant, cette attaque n’est plus du tout d’actualité. Les ISN sont aujourd’hui aléatoires, donc ils ne sont plus prédictibles. De plus, faire un SYN flood est beaucoup plus complexe à réaliser du fait de l’évolution de la capacité des machines et des filtrages en place. Enfin, la mise en œuvre de firewalls sur les machines et les réseaux protège aussi souvent leurs accès.
Bref, vous venez de voir une belle attaque très complexe, mais n’espérez pas une seconde pouvoir la mettre en pratique. Ou alors il vous faudra remonter dans le temps, dans les années 90, là où les pirates avaient un terrain de jeu idéal !
Nous venons de voir en détail les en-têtes IP et TCP. Nous avons vu des mécanismes avancés de ces deux protocoles que sont la fragmentation et le suivi de connexion. Nous avons aussi vu des attaques réseau liées aux implémentations de ces protocoles.
Donc même si ce que vous venez d’apprendre ne vous servira quasiment jamais en tant que tel pour le réseau, vous pouvez comprendre que plus vous connaîtrez en détail ce que vous utilisez et plus vous serez apte à faire de la sécurité, ce qui veut dire attaquer ou défendre vos machines. En réseau comme dans tout domaine en informatique, il est essentiel de connaître en profondeur le fonctionnement des systèmes si l’on veut pouvoir les configurer et les utiliser correctement, ou les contourner...
Après cet approfondissement sur les protocoles réseau et la sécurité associée, nous allons maintenant apprendre à mettre en place un service complet de messagerie.
