Attaque de Mitnick

L'attaque de Mitnick est le nom donné à l'attaque informatique faite par Kevin Mitnick le 25 décembre 1994 sur le réseau de l'expert en sécurité informatique Tsutomu Shimomura. Elle fait partie des cas d'intrusion les plus connus dans la sécurité informatique^[1]. Elle était connue en théorie dans le milieu universitaire depuis le milieu des années 1980, mais elle n'avait jamais encore été mise en pratique. Son côté inédit a donc fortement contribué à sa diffusion. Elle utilisait deux techniques distinctes : l'inondation de requêtes SYN et le vol de session TCP.

Cadre théorique

Identification d'une liaison de confiance

Pour mettre en œuvre l'attaque, il est nécessaire que la machine cible entretienne une liaison de confiance avec une autre machine, autrement dit, qu'il existe un hôte qui peut se connecter à la machine cible sans besoin d'authentification. L'IP spoofing consiste alors à abuser la machine cible en se faisant passer pour cet hôte de confiance en usurpant son adresse IP.

Dans la pratique, sur les stations de travail UNIX, cette liaison de confiance se fait à l'aide des fichiers /etc/hosts.equiv et .rhosts dans le répertoire principal de l'utilisateur. La syntaxe du fichier /etc/hosts.equiv édité par l'utilisateur root est la suivante :

site.equivalent.1
site.equivalent.2
site.equivalent.3

Dans ce cas, si quelqu'un tente de se connecter sur le site par rlogin, rsh ou rcp, le système vérifie si le message provient d'un site figurant dans /etc/hosts.equiv. Si c'est le cas, il inspecte alors le fichier /etc/passwd pour vérifier s'il possède un compte ayant le même nom d'utilisateur que l'utilisateur du système distant. Si la réponse est positive, l'accès distant est autorisé sans besoin de fournir le mot de passe du compte. Si l'utilisateur distant tente de se connecter sous un autre nom d'utilisateur, le fichier /etc/hosts.equiv ne sera pas consulté. Ce fichier n'est pas suffisant pour se connecter directement en tant que root.

La syntaxe du fichier .rhosts dans le répertoire principal d'un utilisateur est la suivante :

site.autorise.1 tux
site.autorise.2

Dans cet exemple, l'utilisateur tux a le droit de se connecter au compte à partir du site site.autorise.1. La deuxième ligne signifie que seul le même nom d'utilisateur que le propriétaire du fichier .rhosts aura le droit de se connecter à partir de site.autorise.2.

Prévoir le numéro de séquence

La partie la plus délicate de l'attaque réside sans doute dans la prédiction du numéro de séquence lors d'une demande de connexion TCP. L'établissement d'une connexion TCP se fait en trois temps :

le client envoie au serveur un paquet avec un drapeau SYN et un numéro de séquence initial $syn_{c}\,$ (ISN : Initial Sequence Number)
le serveur renvoie alors au client un paquet avec un drapeau SYN|ACK de numéro de séquence $syn_{s}\,$ et un numéro d'acquittement égal à $syn_{c}+1\,$
le client répond par un paquet avec un drapeau ACK de numéro de séquence $syn_{c}+1\,$ et un numéro d'acquittement égal à $syn_{s}+1\,$

La connexion est alors établie. Le client et le serveur peuvent commencer à échanger des données.

Quand l'attaquant effectue la première étape de ce procédé, il va mettre l'adresse IP de l'hôte de confiance de la cible comme adresse source dans l'en-tête IP du paquet SYN. Mais quand la cible répond par un paquet SYN|ACK, ce dernier va être envoyé au véritable propriétaire de l'adresse à savoir l'hôte de confiance. L'attaquant ignore donc le numéro de séquence $syn_{s}\,$ envoyé par la cible, or il en a besoin pour établir la connexion. En effet, s'il se trompe de numéro d'acquittement, la cible va envoyer un paquet RST qui met fin à la procédure. C'est pour cette raison que cette attaque est qualifiée d'« attaque à l'aveugle ».

L'attaquant a donc besoin de prédire le numéro de séquence envoyé par la cible en fonction du numéro de séquence initiale du paquet qu'il a envoyé. Mais s'il arrive à deviner une plage de valeurs possibles, il peut éventuellement « inonder » la cible avec des paquets ACK et espérer que l'un des paquets aura le bon numéro d'acquittement. Si l'attaquant a déjà compromis une machine se trouvant sur le même réseau local que sa cible, il peut aussi par exemple effectuer un sniffing pour intercepter ce paquet et obtenir le bon numéro de séquence.

Rendre silencieux l'hôte de confiance

Arrivé à ce stade, il reste quand même un petit problème d'ordre pratique. Étant donné que la cible renvoie le paquet SYN/ACK à l'hôte de confiance et que ce dernier n'a pas fait de demande de connexion, il va envoyer à la cible un paquet RST avortant la demande de connexion. L'attaquant doit donc répondre avant que ce paquet n'arrive à la cible. Or un problème se pose par exemple si ces deux sites se trouvent sur le même réseau local, mais pas l'attaquant, le temps de réponse de ce dernier sera probablement supérieur à celui de l'hôte de confiance. L'attaquant doit donc s'arranger pour que l'hôte de confiance ne puisse pas répondre au paquet envoyé par la cible.

L'attaquant va donc mettre hors service l'hôte de confiance pendant la durée de sa procédure de connexion à la cible. Il peut par exemple envoyer une grande quantité de paquets SYN à ce dernier, mais ne pas effectuer la dernière étape de la procédure de demande de connexion. L'hôte ne pourra plus alors traiter d'autres demandes de connexion pendant un certain temps, car toutes les ressources disponibles sont déjà occupées^[2]. Cette attaque est appelée SYN flooding. À noter que l'attaquant n'est pas obligé de mettre sa véritable adresse IP dans les paquets envoyés pour pouvoir masquer ses traces.

                                      (hors service)
                                      ┌────────────┐
     ┌────────────┐       SYN/ACK     │    HOTE    │
     │   CIBLE    ╞════════>>═════════╡     de     │
     └─────┬──────┘                   │ CONFIANCE  │
           │                          └────────────┘
           │                                 │
           │                                 │
           │                        inondation de SYN
           │                                 │
           │                                 │
           │             SYN          ┌────────────┐
           └─────────────<<───────────┤ ATTAQUANT  │
                                      └────────────┘

Description de l'attaque

La date de l'attaque choisie par Mitnick à savoir le jour de Noël 1994 n'est pas anodine. Il peut ainsi être à peu près sûr que personne ne sera connecté au réseau cible lui donnant plus de latitude dans sa tentative d'intrusion. Il va d'abord se livrer à une collecte d'informations sur le réseau sur lequel il cherche à s'introduire. Il commence par sonder la machine ARIEL à l'aide de la commande UNIX finger à partir du site toad.com :

14:09:32 toad.com# finger -l @ARIEL

La commande finger permet de savoir qui est connecté au système, l'instant de connexion de la personne, l'instant de sa précédente connexion, l'endroit d'où elle se connecte, le temps durant lequel elle a été au repos, si la personne a un courrier. Il découvre alors qu'ARIEL est actuellement connecté à ASTARTE, RIMMON et OSIRIS.

Il sonde alors à son tour RIMMON et se renseigne en particulier sur le super-utilisateur root du système :

14:10:21 toad.com# finger -l @RIMMON

14:10:50 toad.com# finger -l root@RIMMON

Il inspecte enfin OSIRIS qui est la station de travail de Tsutomu Shimomura :

14:11:07 toad.com# finger -l @OSIRIS

14:11:38 toad.com# showmount -e OSIRIS

14:11:49 toad.com# rpcinfo -p OSIRIS

14:12:05 toad.com# finger -l root@OSIRIS

La commande showmount -e permet de savoir les systèmes de fichiers exportés avec Network File System sur le site. Les crackers s'intéressent surtout à ceux qui peuvent être lus et écrits par tout le monde. Tandis que la commande rpcinfo renseigne sur les services d'appel de procédures à distance (RPC) disponibles sur le système. Mitnick découvre en particulier qu'OSIRIS autorise la commande rsh. En se renseignant enfin avec finger, sur le super-utilisateur root, il découvre une connexion en provenance de RIMMON. Il suppose donc l'existence d'une liaison de confiance entre OSIRIS et RIMMON pour l'utilisateur root^[3].

Mitnick va maintenant essayer de connaître le comportement du générateur de numéros de séquence TCP d'OSIRIS. Pour cela il va lui envoyer vingt tentatives de connexion à partir du site apollo.it.luc.edu. Les numéros de séquence initiaux (Initial Sequence Number) étant incrémentés à chaque tentative de connexion. Afin de ne pas saturer le fil de connexions d'OSIRIS, ce qui le mettrait hors service, un paquet RST est envoyé en réponse à chaque paquet SYN/ACK envoyé par ce dernier. Il découvre ainsi que pour deux tentatives de connexion successives, la différence entre les numéros de séquence des paquets SYN/ACK envoyés par OSIRIS est de 128 000. Si $Nsyn\,$ est donc le numéro de séquence du dernier paquet SYN du groupe de paquet envoyé précédemment et $Nack\,$ celui du paquet SYN/ACK correspondant, $Nack+128000\,$ sera le numéro de séquence du paquet SYN/ACK en réponse à un paquet SYN de numéro de séquence $Nsyn+1\,$ .

                                      (hors service)
                       (Nack+128 000)
     ┌────────────┐       SYN/ACK     ┌────────────┐
     │  OSIRIS    ╞════════>>═════════╡   RIMMON   │
     └─────┬──────┘                   │            │
           │                          │┌────┐┌────┐│
           │                          ││    ││    ││
           │                        inondation de SYN
           │                          ││    ││    ││
           │                          │└────┘└────┘│
           │          (Nsyn+1)        │            │
           │            SYN           │   APOLLO   │
           └────────────<<────────────┤  (Mitnick) │
                                      └────────────┘

Tous les ingrédients sont maintenant mis en place pour mettre en œuvre une attaque par spoofing. Mitnick commence par inonder de SYN le fil de connexions de RIMMON 14 secondes avant l'attaque principale mettant la machine dans l'incapacité de traiter d'autres connexions. À 14:18:36, il envoie ensuite à OSIRIS un paquet SYN de demande de connexion de numéro de séquence $Nsyn+1\,$ , mais dont l'adresse source de l'en-tête IP est celle de RIMMON. Il établit ensuite la connexion en envoyant un paquet ACK dont le numéro d'acquittement est $Nack+128000+1\,$ . Pour OSIRIS, tout se passe de manière transparente comme si c'était l'utilisateur root de RIMMON qui avait fait une demande de connexion. Mitnick vient donc de prendre le contrôle d'une session TCP censée s'établir entre OSIRIS et RIMMON^[4]. Ce dernier étant dans l'incapacité temporaire de répondre à des demandes de connexion.

Il ne reste plus alors à l'attaquant qu'à ouvrir une brèche sur OSIRIS lui permettant de l'explorer ultérieurement. Mitnick lui envoie alors la commande suivante :

14:18:37 [root@apollo /tmp]#rsh OSIRIS "echo + + >>/.rhosts"

Cette commande rajoute la ligne + + dans le fichier /.rhosts d'OSIRIS. Il en résulte que dorénavant OSIRIS accepte n'importe qui à se connecter en tant que root sur le système. Le système est maintenant compromis. Mitnick met alors fin à la connexion, car désormais il peut inspecter à sa guise la machine de Shimomura. Il libère enfin le fil de connexions de RIMMON en envoyant des paquets RESET pour ne pas éveiller le soupçon de quelqu'un qui essaierait de se connecter et qui ne pourrait pas.

Conclusion

Une fois la mise en œuvre pratique de cette technique exposée au grand public, elle a connu une large diffusion. D'autres hackers malveillants se sont alors chargés de coder des outils permettant d'automatiser l'attaque. L'utilisation de la technique s'est alors intensifiée. Seulement de nos jours, pour « inonder » le fil de connexions d'un serveur, il faut envoyer beaucoup plus de paquets SYN. De plus, le serveur peut bloquer le trafic provenant d'un hôte qui effectue de multiples demandes de connexion dans un laps de temps très court. Et enfin, un système de détection d'intrusion peut détecter de multiples demandes de sessions provenant d'un hôte qui renvoie systématiquement un RESET et avertir l'administrateur système sur le fait que quelqu'un essaie sûrement de deviner le comportement du générateur de numéro de séquence d'un site.

Par ailleurs, le service, fingerd, sur lequel se base une partie de la recherche d'informations, a presque disparu à l'heure actuelle ; les rares distributions l'intégrant toujours ne l'activent pas.

Notes

↑ Voir le courrier tsutomu@ariel.sdsc.edu posté par Tsutomu Shimomura dans le forum comp.security.misc datant du 25 janvier 1995
↑ Voir Attaque par déni de service
↑ RIMMON est plus précisément un serveur X pour OSIRIS qui est une station de travail sans disque. Les deux machines sont des SPARC tournant sous Solaris 1.
↑ La connexion se fait en fait de manière unilatérale, car Mitnick ne peut pas recevoir de paquets envoyés par OSIRIS.

Voir aussi

Articles connexes

Liens externes

Portail de la sécurité informatique

[1] Voir le courrier tsutomu@ariel.sdsc.edu posté par Tsutomu Shimomura dans le forum comp.security.misc datant du 25 janvier 1995

[2] Voir Attaque par déni de service

[3] RIMMON est plus précisément un serveur X pour OSIRIS qui est une station de travail sans disque. Les deux machines sont des SPARC tournant sous Solaris 1.

[4] La connexion se fait en fait de manière unilatérale, car Mitnick ne peut pas recevoir de paquets envoyés par OSIRIS.

[1]

[2]

[3]

[4]