Attaque de Mitnick
720776
31753419
2008-07-21T10:14:19Z
207.45.248.18
/* Rendre silencieux l'hôte de confiance */
L''''attaque de [[Kevin Mitnick|Mitnick]]''' sur le réseau de [[Tsutomu Shimomura]] fait sûrement partie des cas d'intrusion les plus connus dans la [[sécurité informatique]]<ref>Voir le courrier tsutomu@ariel.sdsc.edu posté par [[Tsutomu Shimomura]] dans le [[Usenet|forum]] [news://comp.security.misc comp.security.misc] datant du 25 janvier 1995</ref>. Elle était connue en théorie dans le milieu universitaire depuis la moitié des années 80, 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'[[SYN flood|inondation de requêtes SYN]] et le vol de session [[Transmission Control Protocol|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'[[Usurpation d'adresse IP|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 <code>/etc/hosts.equiv</code> et <code>.rhosts</code> dans le répertoire principal de l'utilisateur. La syntaxe du fichier <code>/etc/hosts.equiv</code> é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 <code>[[rlogin]]</code>, <code>[[rsh]]</code> ou <code>[[rcp]]</code>, le système vérifie si le message provient d'un site figurant dans <code>/etc/hosts.equiv</code>. Si c'est le cas, il inspecte alors le fichier <code>/etc/passwd</code> 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 <code>/etc/hosts.equiv</code> ne sera pas consulté. À noter que ce fichier n'est pas suffisant pour se connecter directement en tant que <code>[[Utilisateur root|root]]</code>.
La syntaxe du fichier <code>.rhosts</code> dans le répertoire principal d'un utilisateur est la suivante :
site.autorise.1 tux
site.autorise.2
Dans cet exemple, l'utilisateur <code>tux</code> a le droit de se connecter au compte à partir du site <code>site.autorise.1</code>. La deuxième ligne signifie que seul le même nom d'utilisateur que le propriétaire du fichier <code>.rhosts</code> aura le droit de se connecter à partir de <code>site.autorise.2</code>.
===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 [[Transmission Control Protocol|TCP]]. L'établissement d'une connexion [[Transmission Control Protocol|TCP]] se fait en trois temps :
*le client envoie au serveur un paquet avec un drapeau <code>SYN</code> et un numéro de séquence initial <math>syn_c\,</math> (ISN : Initial Sequence Number)
*le serveur renvoie alors au client un paquet avec un drapeau <code>SYN|ACK</code> de numéro de séquence <math>syn_s\,</math> et un numéro d'acquittement égal à <math>syn_c+1\,</math>
*le client répond par un paquet avec un drapeau <code>ACK</code> de ''numéro de séquence'' <math>syn_c+1\,</math> et un numéro d'acquittement égal à <math>syn_s+1\,</math>
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 [[Protocole Internet|IP]] du paquet <code>SYN</code>. Mais quand la cible répond par un paquet <code>SYN|ACK</code>, 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 <math>syn_s\,</math> 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 <code>RESET</code> 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 <code>ACK</code> 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 [[packet sniffer|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 <code>SYN/ACK</code> à l'hôte de confiance et que ce dernier n'a pas fait de demande de connexion, il va envoyer à la cible un paquet <code>RESET</code> 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 <tt>SYN</tt> à 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<ref>Voir également [[Ddos]]</ref>. 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 '''<tt>ARIEL</tt>''' à l'aide de la commande [[UNIX]] <code>[[finger]]</code> à partir du site toad.com :
14:09:32 toad.com# finger -l @ARIEL
La commande <code>[[finger]]</code> 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 [[utilisateur root|super-utilisateur root]] du système :
14:10:21 toad.com# finger -l @RIMMON<br>
14:10:50 toad.com# finger -l root@RIMMON<br>
Il inspecte enfin ''OSIRIS'' qui est la station de travail de [[Tsutomu Shimomura]] :
14:11:07 toad.com# finger -l @OSIRIS<br>
14:11:38 toad.com# showmount -e OSIRIS<br>
14:11:49 toad.com# rpcinfo -p OSIRIS<br>
14:12:05 toad.com# finger -l root@OSIRIS<br>
La commande <code>showmount -e</code> permet de savoir les systèmes de fichiers exportés avec [[Network File System]] sur le site. Les [[Pirate informatique|crackers]] s'intéressent surtout à ceux qui peuvent être lus et écrits par tout le monde. Tandis que la commande <code>rpcinfo</code> renseigne sur les services d'appel de procédures à distance ([[Remote Procedure Call|RPC]]) disponibles sur le système. [[Mitnick]] découvre en particulier qu'''OSIRIS'' autorise la commande <code>[[rsh]]</code>. En se renseignant enfin avec <code>[[finger]]</code>, sur le [[Utilisateur root|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]]<ref>''RIMMON'' est plus précisément un [[X Window System|serveur X]] pour ''OSIRIS'' qui est une station de travail sans disque. Les deux machines sont des [[SPARC]] tournant sous [[Solaris (informatique)|Solaris 1]].</ref>.
[[Mitnick]] va maintenant essayer de connaître le comportement du générateur de numéros de séquence [[Transmission Control Protocol|TCP]] d'<i>OSIRIS</i>. Pour cela il va lui envoyer vingt tentatives de connexion à partir du site <code>apollo.it.luc.edu</code>. 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 <code>RESET</code> est envoyé en réponse à chaque paquet <code>SYN/ACK</code> 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 <code>SYN/ACK</code> envoyés par ''OSIRIS'' est de 128 000. Si <math>Nsyn\,</math> est donc le numéro de séquence du dernier paquet <code>SYN</code> du groupe de paquet envoyé précédemment et <math>Nack\,</math> celui du paquet <code>SYN/ACK</code> correspondant, <math>Nack + 128 000\,</math> sera le ''numéro de séquence'' du paquet <code>SYN/ACK</code> en réponse à un paquet <code>SYN</code> de numéro de séquence <math>Nsyn+1\,</math>.
(hors service)
____________ (Nack+128000) ____________
| | 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 [[Usurpation d'adresse IP|spoofing]]. [[Mitnick]] commence par inonder de <code>SYN</code> 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 <code>SYN</code> de demande de connexion de numéro de séquence <math>Nsyn+1\,</math>, mais dont l'adresse source de l'en-tête [[Protocole Internet|IP]] est celle de ''RIMMON''. Il établit ensuite la connexion en envoyant un paquet <code>ACK</code> dont le numéro d'acquittement est <math>Nack+128000+1\,</math>. 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 [[Transmission Control Protocol|TCP]] censée s'établir entre ''OSIRIS'' et ''RIMMON''<ref>La connexion se fait en fait de manière unilatérale, car [[Kevin Mitnick|Mitnick]] ne peut pas recevoir de paquets envoyés par ''OSIRIS''.</ref>. 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 <code>+ +</code> dans le fichier <code>/.rhosts</code> d'''OSIRIS''. Il en résulte que dorénavant ''OSIRIS'' accepte n'importe qui à se connecter en tant que [[utilisateur root|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 [[Tsutomu Shimomura|Shimomura]]. Il libère enfin le fil de connexions de ''RIMMON'' en envoyant des paquets <code>RESET</code> 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 [[Black hat|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 <code>SYN</code>. 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 <code>RESET</code> 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==
<references/>
==Voir aussi==
* [[Usurpation d'adresse IP]]
* [[Ddos]]
* [[SYN flood]]
* [[SYN cookie]]
* [[Transmission Control Protocol|TCP]]
==Liens externes==
* {{en}} [http://www.cs.berkeley.edu/~daw/security/shimo-post.txt Courrier posté par Tsutomu Shimomura dans le forum comp.security.misc le 25 janvier 1995 décrivant l'attaque de Mitnick]
* {{fr}} [http://www.vulnerabilite.com/actu/20060312235132social-engineering_kevin-mitnick.html Les failles du Firewall humain selon Kevin Mitnick]
{{Portail sécurité informatique}}
[[Catégorie:Sécurité du réseau informatique]]