1 - Hijacking et réseaux locaux par CynaBS

A - Les réseaux locaux

Les réseaux locaux, ou LANs (Local Area Network), tendent à s’imposer au sein des entreprises et des écoles comme un moyen de communication fiable, peu coûteux et réputé relativement sécurisé : les switchs assurent le transfert privé des données et permettent même de contrôler que la connexion réseau est utilisée par une seule carte réseau. Pourtant en pratique, ces réseaux se révèlent infiniment plus vulnérables qu’Internet.

Avant de parler de hijacking, voici un petit rappel d’architecture réseau Ethernet :

- Chaque carte réseau est identifiée par un numéro MAC unique (ou presque)

- Les ordinateurs connectés à un même hub forment un segment Ethernet

- Sur un même segment, toutes les cartes réseau reçoivent les mêmes données

- Les segments sont interconnectés soit par des switchs, soit par des routeurs

On en déduit déjà une vulnérabilité de taille, que tout utilisateur est capable d’exploiter : sur un même segment, les ordinateurs peuvent s’espionner les uns les autres en toute impunité en activant le mode « promiscuous » de leur carte réseau : les données du segment ne sont plus filtrées et la carte réseau envoie tout en vrac au système ; derrière, un programme de sniffing décode les informations. Cela permet par exemple d’espionner des sessions Telnet et de découvrir les mots de passe des ordinateurs sur le même segment.

Contrairement à Internet, les données ne sont pas acheminées en fonction de l’adresse IP de l’ordinateur de destination, mais en fonction de son adresse MAC. C’est pourquoi il existe un protocole spécialement conçu pour faire le lien entre l’adresse IP d’un ordinateur et l’adresse MAC de sa carte réseau : le protocole ARP permet de déterminer, à partir d’une adresse IP quelconque, l’adresse MAC correspondante. Pour cela, une requête ARP est envoyée en broadcast, et l’ordinateur possédant l’adresse IP demandée répond avec son adresse MAC.

C’est pourquoi on distinguera deux processus de routage des informations :

- Le routage matériel assuré par les switchs, en fonction de l’adresse MAC

- Le routage logique assuré par les routeurs, en fonction de l’adresse IP

Les switchs propagent de manière transparente les données vers l’ordinateur possédant l’adresse MAC de destination, sans se soucier de la cohérence de l’adresse IP de destination : les switchs n’effectuent aucun contrôle sur les protocoles de couche supérieure (IP) ; ainsi on peut très bien envoyer des données à un ordinateur sans que l’adresse IP de destination des paquets soit la sienne.

Les routeurs au contraire ignorent la couche matérielle des paquets de données ; ils n’examinent que les couches supérieures (IP, TCP, UDP) pour déterminer le chemin que doit prendre le paquet. Pour que le packet soit transmis, il faut qu’il soit adressé à l’adresse matérielle du routeur, et non à celle de l’ordinateur qui se trouve derrière le routeur. Le routeur modifie le paquet transmis en remplaçant l’adresse MAC de destination par l’adresse MAC réelle de destination de la cible, et l’adresse MAC source par sa propre adresse MAC.

 

B - Et le hijacking dans tout ça ?

Le hijacking est une technique qui tire parti des caractéristiques des réseaux locaux : elle permet d’intercepter une connexion déjà établie et de se l’approprier complètement ; par exemple, intercepter une session Telnet peut être intéressant pour installer des backdoors à l’insu de l’utilisateur. On distingue plusieurs types de hijacking :

- Le hijacking sauvage, qui permet de kidnapper une connexion purement et simplement en déconnectant au passage la victime.

- Le hijacking transparent, dont l’avantage est de faire croire à la victime qu’elle est toujours maîtresse de sa connexion.

Concrètement, dans quelles conditions peut-on hijacker une connexion ? On distingue là encore deux cas :

- L’un des deux ordinateurs qui communiquent entre eux, ou même les deux, sont sur le même segment Ethernet que nous : on a accès à la totalité de la connexion.

- Les deux ordinateurs sont sur un segment différent du notre ; on n’a alors pas accès aux données qu’ils échangent.

Le premier cas a été largement documenté depuis quelques années, nous n’étudierons ici que le dernier cas ; il sera nécessaire de d’abord détourner le trafic vers notre ordinateur avant de procéder à la désynchronisation de la connexion.

 

C - La technique

a - Détournement du trafic TCP/IP

Cette technique est basée sur la stupidité pure et simple de l’implémentation du protocole ARP dans la plupart des kernels. En interne, le kernel possède une table de correspondance adresse IP / adresse MAC. Supposons qu’un ordinateur A se connecte à un ordinateur B :

- Ordinateur A - ----------- - SWITCH - ----------- - Ordinateur B -

|     

NOUS

A envoie une requête ARP pour déterminer l’adresse MAC de B ; B répond, et A met son cache ARP à jour.

C’est là que nous intervenons : nous envoyons nous-mêmes des réponses ARP à A pour lui faire croire que l’adresse IP de l’ordinateur B correspond à notre propre adresse MAC. Le résultat est que la plupart des systèmes « oublient » la première réponse ARP qui était la bonne, et mettent à jour leur cache avec notre adresse MAC ; le trafic provenant de A est donc envoyé par le switch vers notre ordinateur, que nous relayons vers B en insérant notre adresse MAC en source, et la véritable adresse MAC de l’ordinateur B en destination.

A ce stade, les informations du cache ARP de B sont correctes : B connaît l’adresse MAC de l’ordinateur A, ce qui conduit à une interception à sens unique (de A vers B). Mais lorsque le cache aura expiré (ou immédiatement selon les systèmes), B mettra à jour ses données à la réception des packets que nous avons relayés, et croira aussi que l’ordinateur B possède notre adresse MAC.

A et B croient alors communiquer entre eux. C’est gagné.

IMPORTANT : lorsque le switch est remplacé par un routeur, cette technique n’est plus valable car les packets ARP ne sont plus relayés ; si les deux ordinateurs A et B appartiennent à un sous-réseau différent du notre, il n’y a rien à faire. Si par contre A est sur le même sous-réseau que nous, on adapte cette technique en déviant vers nous le trafic entre le routeur et A.

b - Désynchronisation de la connexion

La technique de programmation est assez simple. Du point de vue de la couche TCP, tout se passe comme si notre ordinateur constituait un pont entre A et B. Il suffit donc d’utiliser deux interfaces : une pour la communication avec A et l’autre pour la communication avec B. Ces interfaces contiennent deux champs :

le champ SEQ en cours, et le champ ACK en cours.

- Ordi A - Seq - ----------> - Ack - * Nous * - Seq - -----------> - Ack - Ordi B -

- Ordi A - Ack - <---------- - Seq - * Nous * - Ack - <----------- - Seq - Ordi B -

Lorsque nous recevons un paquet émis par A, nous mettons à jour les interfaces A et B ; puis nous remplaçons les champs SEQ et ACK par ceux de l’interface B ; à cette étape, il est possible de modifier les données contenues dans les paquets suivant un jeu de filtres. Enfin, nous envoyons le paquet à B. Il est vital que l’interface B soit mise à jour correctement, sous peine de perte définitive de la connexion.

Lorsque les données sont relayées de manière transparentes et sans modification, la connexion est toujours synchronisée et les numéros SEQ/ACK des interfaces sont égaux aux numéros SEQ/ACK des packets relayés.

Pour comprendre les détails de la mise à jour des interfaces, lisez un tutorial sur les connexions TCP.

 

D - Injection de données dans la connexion

Cette technique permet d’intervenir dans la connexion en cours de manière complètement transparente pour les deux hôtes en communication. Pour injecter des données vers B à l’insu de A, la procédure est la suivante :

- On forge de toutes pièces un packet incluant les données à envoyer à B

- On attend un moment d’inactivité dans la connexion (en Telnet ça ne pose pas de problème)

- On stoppe le relais de A vers B et on stocke les paquets provenant de A dans une file d’attente

- On émet le paquet forgé et on enregistre sans la relayer la réponse de B

- On traite les paquets dans la file d’attente et on réactive le relais

La connexion est alors désynchronisée : les champs SEQ/ACK de l’interface B sont supérieurs à ceux de l’interface A.

 

E - Quitter une connexion désynchronisée

En régime désynchronisé, l’ordinateur A émet des paquets présentant des champs SEQ/ACK différents de ceux attendus et émis par B ; le but de cette manœuvre est donc de faire coïncider ces numéros de la manière la plus naturelle possible, puis de rétablir le trafic des données entre A et B pour pouvoir terminer le hijacking. Cette manœuvre est quelque peu délicate, puisqu’il n’existe pas de méthode sûre et infaillible pour re synchroniser la connexion. C’est le seul moment où A et B peuvent se rendre compte qu’ils ont été victime de hijacking.

Prenons l’exemple où nous aurions envoyé 20 octets de données à B à l’insu de A ; sur l’interface B, le champ SEQ est incrémenté de 20, tandis que sur l’interface A il est resté identique. Pour que l’égalité soit rétablie, il est nécessaire que l’ordinateur A émette 20 octets qui ne seront pas relayés vers B. Une technique couramment utilisée lors du hijack de sessions Telnet est l’envoi à A de faux messages d’erreur du style : « segmentation fault - type 20 chars to resume » ou « I/O failure detected. 20 chars will solve it ». Ces messages sont destinés à faire taper à l’utilisateur de l’ordinateur A le nombre d’octets désiré pour re synchroniser la connexion.

A l’inverse, si nous avions envoyé 20 octets de données à l’ordinateur A, il serait nécessaire de faire comprendre à l’ordinateur B qu’il doit imprimer 20 caractères pour se synchroniser la connexion. Dans le cas d’une session Telnet, si B est le serveur, il suffirait d’exécuter à l’insu de A une commande qui afficherait le nombre de caractères voulu, par exemple en Perl : perl -e ‘print ‘x’ x 45’. Ici, 45 octets seront affichés : il ne faut pas oublier le nombre d’octets nécessaires à envoyer la commande Perl, ni le caractère de fin de ligne associé…

Par Cynabs