Attaque de Mitnick - Définition
La liste des auteurs de cet article est disponible ici.
Introduction
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. 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.
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
SYNet un numéro de séquence initial
- le serveur renvoie alors au client un paquet avec un drapeau
SYN|ACKde numéro de séquence
- le client répond par un paquet avec un drapeau
ACKde numéro de séquence
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
RESET 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 RESET 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. 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 | |____________|
