- Attaque de mitnick
-
Attaque de Mitnick
L'attaque de Mitnick sur le réseau de Tsutomu Shimomura fait sûrement 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 la moitié des années 1980, mais jamais encore mise en pratique. Son côté inédit a donc fortement contribué à sa diffusion. Elle utilisait en réalité deux techniques distinctes: l'inondation de requêtes SYN et le vol de session TCP.
Sommaire
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
ourcp
, 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 queroot
.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 sitesite.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 desite.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 (ISN : Initial Sequence Number) - le serveur renvoie alors au client un paquet avec un drapeau
SYN|ACK
de numéro de séquence et un numéro d'acquittement égal à - le client répond par un paquet avec un drapeau
ACK
de numéro de séquence et un numéro d'acquittement égal à
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 paquetSYN|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 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 paquetRESET
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 paquetRESET
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@RIMMONIl 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@OSIRISLa 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 commanderpcinfo
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 commandersh
. En se renseignant enfin avecfinger
, 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 dOSIRIS. 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 dOSIRIS, ce qui le mettrait hors service, un paquetRESET
est envoyé en réponse à chaque paquetSYN/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 paquetsSYN/ACK
envoyés par OSIRIS est de 128 000. Si est donc le numéro de séquence du dernier paquetSYN
du groupe de paquet envoyé précédemment et celui du paquetSYN/ACK
correspondant, sera le numéro de séquence du paquetSYN/ACK
en réponse à un paquetSYN
de numéro de séquence .(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 paquetSYN
de demande de connexion de numéro de séquence , mais dont l'adresse source de l'en-tête IP est celle de RIMMON. Il établit ensuite la connexion en envoyant un paquetACK
dont le numéro d'acquittement est . 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 paquetsRESET
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 unRESET
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.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
- (en) Courrier posté par Tsutomu Shimomura dans le forum comp.security.misc le 25 janvier 1995 décrivant l'attaque de Mitnick
- (fr) Les failles du Firewall humain selon Kevin Mitnick
- Portail de la sécurité informatique
Catégorie : Sécurité du réseau informatique - le client envoie au serveur un paquet avec un drapeau
Wikimedia Foundation. 2010.