Voici les risques auxquels vous vous exposez si vous n’empêchez pas l’usurpation d’adresse IP :

– INTERCEPTION INTERNE : Rediriger le trafic vers une machine pirate qui enregistre tout
Le pirate substitue l’adresse légitime de la passerelle réseau par celle d’une machine pirate configurée pour tout retransmettre à la vraie passerelle, mais en enregistrant au passage tout le trafic (mots de passe, communautés SNMP, etc.).

– DENI DE SERVICE : Empêcher le trafic d’aboutir
Le pirate substitue l’adresse légitime de la passerelle réseau par celle d’une machine qui « drop » tous les paquets (sauf éventuellement ceux qui lui sont destinés). Plus aucun échange n’est alors possible sur le réseau.

–  DENI DE SERVICE : Rediriger le trafic vers une machine en vue de la saturer
Le pirate substitue l’adresse légitime de la passerelle réseau par celle d’un serveur qui va alors recevoir tout le trafic destiné à la passerelle et qui est susceptible de saturer sous l’importance du flux.

–  INTERCEPTION EXTERNE : Rediriger les requêtes DNS vers un serveur pirate revoyant vers des sites d’hameçonnage
Le pirate substitue l’adresse légitime du DNS par celle d’un serveur pirate. Quand un client demande l’adresse IP de www.unsite.fr, le DNS pirate lui donne l’adresse d’un site de hameçonnage imitant le site www.unsite.fr et enregistrant les identifiants de connexion de la victime (login, mot de passe, numéros de carte bancaire, etc.).

Il existe, entre autres, deux méthodes permettant de réaliser cette usurpation qui sont bien connues mais malheureusement pas assez souvent prises en compte : le DHCP spoofing et l’ARP spoofing.

Celles-ci sont assez anciennes pour que des contre-mesures existent. Néanmoins, nous n’observons que trop peu souvent, lors de nos audits, la présence de ces protections.
Elles peuvent être déployées sur des commutateurs (switches) ou des routeurs/pare-feu, mais ne sont que rarement activées dans la configuration par défaut des principaux fabricants. C’est donc de la responsabilité de l’administrateur du réseau de s’assurer de leur mise en place.

1.1. Dynamic Host Configuration Protocol (DHCP)
1.1.1. Protocle
Le DHCP est chargé de fournir une adresse IP à une machine cliente se connectant au réseau. Inutile de s’étendre en détail sur le fonctionnement de ce protocole mais ce simple résumé donne suffisamment de clés pour comprendre les attaques explicitées plus loin :

1. Le client envoie un paquet UDP DHCP Dicovery en broadcast (donc tout le segment réseau peut le capter). Il peut éventuellement contenir son ancienne adresse IP. Si le serveur DHCP se trouve dans un autre sous-réseau, en général le routeur est alors configuré pour transmettre les requêtes DHCP broadcast à ce serveur.

2. Tous les serveurs DHCP qui reçoivent ce message, réservent une adresse IP et font une proposition en envoyant un DHCP Offer (paquet UDP en broadcast également). Ce paquet contient l’adresse IP attribuée, l’adresse de la passerelle, du DNS et de tout ce qui est utile.

3. Le client choisi la réponse qui lui convient le mieux, en général la première, et renvoie un paquet DHCP Request (UDP broadcast) stipulant l’adresse IP du serveur DHCP dont il a retenu l’offre. Les autres serveurs libèrent alors l’adresse IP qu’ils avaient réservée pour ce client.

4. Enfin le serveur DHCP qui a été choisi envoie un dernier paquet : DHCP Ack (UDP broadcast) qui contient toutes les informations nécessaires à la configuration de l’interface : la durée du bail de l’adresse allouée, la passerelle, le serveur DNS, etc.

1.1.2. Attaques
Le protocole DHCP ne prévoit pas d’authentification. Si une machine du réseau décide de se comporter comme un serveur DCHP, rien ne l’en empêche a priori.
Or les machines effectuant des requêtes DHCP prendront en compte, le plus souvent, la première réponse obtenue (celle du serveur légitime ou celle de ce nouveau DHCP). Si le DHCP légitime se trouve après plusieurs routeurs, il mettra plus de temps à répondre qu’un attaquant se faisant passer pour un serveur DHCP dans le même sous-réseau.
Or le DHCP ne fournit pas seulement une adresse IP à une machine, il indique aussi la passerelle, le DNS, etc.

Il est donc possible de reproduire toutes les nuisances de l’usurpation d’IP. Mais l’ont peut également s’attaquer à l’adressage IP de machines tierces, les nuisances suivantes sont donc aussi à prendre en compte :

– DENI DE SERVICE : Envoyer une mauvaise adresse IP à une machine du réseau pour l’empêcher de s’y connecter
Le pirate se fait passer pour le serveur DHCP et donne des IP incorrectes (par exemple 192.168.0.2 dans un réseau en 10.0.0.0/24) de sorte que la machine cliente ne sera pas routée correctement et n’arrivera pas à joindre et à être jointe.

– DENIS DE SERVICE : Consommer toutes les adresses IP disponibles pour empêcher les autres utilisateurs de se connecter
Le pirate simule des paquets DHCP Discover avec un identifiant changeant à chaque fois, le serveur DHCP réserve donc une IP à chaque requête. Lorsque la réserve d’adresses IP est épuisée, plus aucune nouvelle machine ne pourra se connecter au réseau, ni celle dont le bail IP a expiré.

1.2. Address Resolution Protocol (ARP)
1.2.1. Protocole
Le protocole ARP permet de faire la liaison entre la couche 2 (adresse MAC) et la couche 3 (adresse IP) du modèle OSI. Le comportement attendu est le suivant :

1. Une machine cliente veut joindre une adresse IP spécifique, mais elle ne possède pas son adresse MAC dans son cache ARP. Elle émet alors une requête en broadcast (donc tout le segment réseau peut la capter) stipulant l’adresse IP recherchée et sa propre adresse MAC (pour que l’on puisse lui répondre).

2. La machine ayant l’adresse IP recherchée effectue deux actions :
a. Pour être sûre de répondre à la bonne machine, elle met à jour son propre cache ARP avec l’adresse MAC et l’IP de la machine qui a fait la demande.
b. Elle envoie une réponse ARP stipulant son adresse IP et son adresse MAC à destination de la machine qui a fait la demande.

3. La première machine reçoit la réponse et met son cache ARP à jour avec la nouvelle association reçue. Elle connait alors l’adresse MAC de l’IP qu’elle voulait joindre.

Le protocole ARP peut s’utiliser de plusieurs façon différentes, celle-ci n’est qu’une parmi d’autres. Une autre très intéressante concerne les paquets « ARP announcements » (ou gratuitous ARP).

Ils sont utilisés lorsqu’une machine A vient de changer d’adresse IP. Plutôt que d’attendre que les autres machines fassent une requête ARP ou se trompent en envoyant des paquets à l’ancienne adresse IP, A envoie une « annonce » stipulant sa nouvelle association adresse MAC/adresse IP. Toutes les autres machines mettent donc leurs tables ARP à jour.

1.2.2. Attaques
Un des problèmes principaux du protocole ARP est qu’il est sans état (stateless). Une machine mettra donc toujours son cache ARP à jour lorsqu’elle reçoit une réponse ARP même si elle n’a pas initiée de requête.
La mise à jour écrase systématiquement l’entrée précédente associée à une IP si elle existe et il n’y a pas de mécanisme d’authentification possible pour ARP.

Le principe d’une attaque est donc simple : si l’on a une adresse MAC A et que l’on veut se faire passer pour une autre machine qui a une adresse MAC B et une adresse IP C, il suffit d’envoyer à tout le monde une réponse ARP contenant l’association A/C.
Les machines vont alors écraser l’ancienne association B/C de leur table ARP et la remplacer par la nouvelle. Le trafic adressé à l’adresse IP C sera donc acheminé à la machine ayant l’adresse MAC A.

En plus de l’usurpation, il est également possible de s’en prendre à des machines tierces. Toute les nuisances de l’IP spoofing sont donc réalisable, plus :

–  DENI DE SERVICE : Intercepter le trafic destiné à une machine tierce
Le pirate inonde le réseau de réponse ARP associant son adresse MAC à l’adresse IP de sa victime. Tout le trafic destiné à cette dernière ne lui parviendra donc pas, elle ne pourra pas initier de connexion avec d’autres services (elle peut émettre des requêtes mais ne recevra pas les réponses).

Ce type d’attaque demeure réalisable seulement dans le champ des adresses du broadcast, les paquets ARP n’étant pas routés, il n’est pas donc pas possible d’infecter d’autres segments du réseau.

1.3. Contre-mesures
1.3.1. DHCP snooping
Le DHCP snooping est en ensemble de techniques, agissant au niveau 2 du modèle OSI, visant à contrecarrer les serveurs DHCP « voyous » (Rogue DHCP).
La principale contre-mesure consiste à introduire la notion de confiance au niveau des interfaces des routeurs/pare-feux/commutateurs. L’équipement sera configuré pour autoriser les DHCP Offer et DHCP Ack uniquement depuis les interfaces de confiance (trusted).
L’efficacité de ce dispositif nécessite également une bonne hygiène d’architecture réseau : les postes utilisateurs (d’où il est plus probable de voir une attaque émerger) ne doivent pas être dans le même segment que le serveur DHCP.
Ainsi les requêtes d’un poste utilisateur tentant de se faire passer pour un serveur DHCP ne proviendront pas de l’interface de confiance (et seront donc supprimées).

Une autre fonctionnalité importante consiste à établir une base, au niveau des commutateurs (switches), des adresses IP attribuées ainsi que de leur adresse MAC et leur port. Les commutateurs observent et enregistrent simplement les réponses DHCP afin de construire cette liste.

Il s’agit d’une très forte plus value contre l’IP spoofing en général. En effet, d’autres contre-mesures utilisent cette base pour interdire les trames circulant sur le réseau avec une certaine IP de destination (ou de source), non associées à la même adresse MAC que celle de la dernière attribution du vrai serveur DHCP (telle qu’enregistrée dans la base du DHCP snooping).

1.3.2. Dynamic ARP Inspection (DAI)
L’inspection dynamique des parquets ARP utilise la base du DHCP snooping pour vérifier la conformité des réponses ARP envoyées.
Le commutateur disposant de la base d’associations [Adresse IP / Adresse MAC / Port], il est à même d’inspecter tous les paquets ARP qui transitent par lui ou qui lui sont adressé.

Il lui suffit de lire l’association IP/MAC proposé dans le paquet ARP et de s’assurer qu’elle correspond bien à celle attribuée par le serveur DHCP (via la base de DHCP snooping). Le cas échéant le paquet est supprimé (il peut également être journalisé et un administrateur contacté), sauf s’il provient d’un port de confiance (trusted) pour permettre par exemple au serveur DHCP de propager sa nouvelle adresse IP s’il en a changé.
Si l’adresse IP concernée n’a jamais été attribuée, elle ne se trouvera pas dans la base de DHCP snooping, il ne s’agit donc pas d’une mauvaise correspondance mais d’une absence de correspondance. Il demeure préférable de supprimer le paquet.

Suivant les constructeurs, quelques subtilités peuvent apparaitre dans le comportement du DAI, notamment concernant des tests supplémentaires sur le port de provenance du paquet ARP ou sur le comportement à adopter en cas d’adresse absente de la base du DHCP snooping.

1.3.3. DHCP filtering
Cette contre-mesure est proposée par plusieurs constructeurs et se base également sur la base du DHCP snooping.
Cela consiste à vérifier, au niveau du commutateur, le port de provenance de chaque paquet. En consultant la base d’associations IP/MAC/port du DHCP snooping, on compare l’IP émettrice du paquet à celle, légitime, attribuée par le serveur DHCP. S’il y a divergence, le paquet est supprimé.

Il s’agit dont d’une mesure à posteriori de l’usurpation d’adresse IP (l’attaquant a déjà pu forger une trame illégitime) mais permettant de prévenir son utilisation malveillante.

1.3.4. Unicast Reverse Path Forwarding (uRPF)
L’Unicast Reverse Path Forwarding est une mesure simple qui permet de limiter les risques d’usurpation brute d’IP.
Lorsqu’un routeur doit transmettre un paquet, il consulte sa table de routage pour s’assurer que le destinataire est bien joignable. Avec l’uRPF, il s’assurera toujours que l’IP de source du paquet, qui est donc sensée recevoir la réponse, est bien atteignable par l’interface dont il a reçu le paquet.
En effet, si cette adresse IP n’est pas atteignable par le chemin d’où elle est sensée avoir envoyé un paquet, c’est que ce n’est pas elle qui l’a envoyé.

Pour illustrer par un exemple, imaginons que la table de routage du routeur soit :
– 1.1.1.0/24 eth1
– 2.2.2.0/24 eth2
– 3.3.3.0/24 eth3

Et imaginons plusieurs types de paquets reçus :
– [source : 1.1.1.30 – destination : 2.2.2.4] provenant de l’interface eth1
L’adresse 1.1.1.30 est joignable sur l’interface eth1 (car elle appartient au réseau 1.1.1.0/24). Donc le paquet est accepté
– [source : 1.1.1.30 – destination : 2.2.2.4] provenant de l’interface eth2
L’adresse 1.1.1.30 est joignable mais pas par l’interface eth2, si c’est bien elle qui avait envoyé ce paquet, il serait venu de l’interface eth1. Donc le paquet est refusé
– [source : 4.4.4.30 – destination : 2.2.2.4] provenant de l’interface eth1

L’adresse 4.4.4.30 n’est pas joignable, donc elle n’aurait pas pu envoyer ce paquet. Donc le paquet est refusé.

Il existe une subtilité quant à dire que le paquet reçu « doit » provenir de l’interface où l’adresse émettrice est joignable. En effet certains réseaux ont un routage dit « asymétrique » où la réponse n’empreinte pas forcément le même chemin que la requête.

A ce moment là, on peut utiliser l’uRPF en « loose mode » (par opposition au « strict mode » décrit précédemment). Ce mode se contente seulement de vérifier que l’adresse source du paquet est joignable dans la table de routage, peu importe l’interface d’où il provient.
L’uRPF en loose mode, appliqué aux exemples précédents de paquets reçus, aurait accepté les deux premiers paquets et refusé le troisième.

Il ne s’agit pas d’une protection totale : un attaquant dans le même sous-réseau que l’adresse qu’il veut usurper ne serait pas détecté (si 1.1.1.10 essaye de se faire passer pour 1.1.1.20). Néanmoins cela permet de parer à des cas « grossiers » d’usurpation d’adresse IP.

Plusieurs types de routeurs permettent d’utiliser ce système.

Conclusion

L’usurpation d’adresse IP s’appuie généralement sur les faiblesses intrinsèques des deux protocoles DHCP et ARP qui n’ont pas été conçus à la base pour répondre à des problématiques de sécurité.

La sécurité a donc été déportée au niveau des nœuds du réseau (commutateurs, routeurs/pare-feu) qui surveillent et analyse les requêtes et les réponses pour y déceler les tentatives d’abus de DHCP ou d’ARP.
Seulement ces mécanismes sont trop peu souvent activés par défaut, l’administrateur réseau doit donc avoir la présence d’esprit de prendre en compte les menaces sur son réseau et d’activer les mécanismes adéquats en fonction.

Ce type d’attaque est pourtant très usité lors des audits de sécurité interne. Il permet généralement de récupérer tous les mots de passe circulant en clair (FTP, SNMP, messagerie, etc.) et éventuellement ceux qui sont chiffrés si l’utilisateur ignore l’alerte de mauvais certificat (ce qui arrive invariablement au moins une fois).

Les constructeurs comme Cisco, HP, Dell, Juniper, H3C ou encore Allied telesis embarquent ces contre-mesures.