Stress Testing – DHCPig
Quand on découvre la distribution Kali Linux (anciennement Backtrack), la première chose que l’on regarde c’est la liste des outils disponibles ! Il est difficile d’être déçu, Kali met à notre disposition un quantité phénoménale d’outils ! Cette profusion est telle, qu’elle en deviendrait presque un frein pour le néophyte qui, face à cette impressionnante montagne de ressources, ne sait quelle voie emprunter pour arriver au sommet.
Je pense ne pas trop me mouiller en affirmant que très peux d’utilisateurs de ces distributions sont en mesure de définir l’utilité ne serait-ce que d’un tiers de ces outils; et d’utiliser même basiquement un sixième de cette panoplie (moi compris). Je vais tenter de faire la liste exhaustive de ces outils, en expliquant brièvement leur usage. Pour moi, le bénéfice est double : j’en apprend un peu plus sur le fonctionnement des outils que je connais, et j’en découvre un grand nombre d’autres… Sans parler des articles qui viendront enrichir 0x0ff.info !
Je commence donc cette longue, longue… LONGUE série, avec un outil de la catégorie (Network) Stress Testing, ce qui me permet d’ailleurs d’illustrer l’article avec un un petit crobar…
dhcpig
Le premier tool que je présente dans cette catégorie est DHCPig. C’est un outil qui a pour vocation l’épuisement du pool DHCP sur un réseau. L’idée derrière tout ça, est d’occuper toutes les adresses distribuées par le serveur DHCP afin d’empêcher toute nouvelle machine d’obtenir une adresse IP. Mais DHCPig fait plus que ça, il va carrément révoquer les baux DHCP des autres machines présentes sur le réseau, à la rue les pégus !
Vous pouvez trouver la dernière version en date sur le GitHub de l’application : DHCPig GitHub. Kali intègre bien évidemment l’outil, mais il s’agit une version antérieur un peu plus basique. Mais vu qu’il fait ce qu’on lui demande, on s’en fout pas mal !
La commande
0x0ff@kali:~# pig.py eth0 Sending DHCPDISCOVER on eth0 DHCPOFFER handing out IP: 192.168.7.22 sent DHCP Request for 192.168.7.22 waiting for first DHCP Server response on eth0 Sending DHCPDISCOVER on eth0 ..Begin emission: **Finished to send 256 packets. DHCPOFFER handing out IP: 192.168.7.23 sent DHCP Request for 192.168.7.23 Sending DHCPDISCOVER on eth0 DHCPOFFER handing out IP: 192.168.7.24 sent DHCP Request for 192.168.7.24
Comment ça marche ?
Pour répondre à cette question j’ai capturé l’intégralité de l’attaque. Même si le fonctionnement global est relativement simple à deviner, ces quelques screenshots sont une occasion de mettre en lumière les protocoles ARP et DHCP.
Comme je l’ai déjà expliqué dans VoIP-STFR, le protocole ARP (Address Resolution Protocol) permet de faire le lien entre la couche liaison de données (niveau 2) qui il utilise les adresses MAC (physiques) et la couche réseau (niveau 3) qui utilise les adresse IPv4. (A noter qu’en IPv6 ARP est remplacé par NDP Neighbor Discovery Protocol .)
Dans un premier temps, DHCPig va interroger le réseau en utilisant le protocole ARP afin de découvrir qui sont ses voisins sur le réseau. Cette première étape permet de récupérer les informations nécessaires à la création de requêtes DHCP visant à libérer l’ensemble des baux de ces machines.
Le petit script pig.py va ensuite générer les échanges DHCP permettant de réserver chaque adresse du pool. L’échange de paquets DHCP permettant à une machine d’obtenir une adresse se fait en quatre étapes. La machine en demande commence par émettre un DHCP Discover, paquet encapsulé par Ethernet qui contiendra donc l’information @MAC source ! Le serveur DHCP cette brave bêyte va s’empresser de répondre à l’émetteur en lui proposant (notamment) une adresse IP, grâce au paquet DHCP Offer ! Lorsque la machine cliente reçoit cette offre, elle accepte (ou non d’ailleurs) les conditions : DHCP Request (DHCP Decline). L’échange se termine par un DHCP ACK du serveur, qui notifie le client de la validation de cette transaction (ou par un DHCP NAK lorsque la transaction est refusée).
Chaque transaction est passée avec une adresse MAC aléatoire. L’adresse mac 00:0c:29:13:94:fa permet au serveur de d’identifier la machine et de lui envoyer son adresse IP. Cette adresse MAC (couche 2) constitue le liant entre ces différents paquets DHCP.
Lorsque le pool d’adresse est épuisé, le serveur cesse de répondre aux DHCP Discover.
Lorsque DHCPig détecte cette absence de réponse, il passe à l’étape suivante qui consiste à vérifier quels hôtes sont encore présent sur le réseau, ce qui permet d’évaluer le succès de l’attaque.
Knocking 192.168.7.1 offline, goodbye Knocking 192.168.7.2 offline, goodbye Knocking 192.168.7.3 offline, goodbye ... Knocking 192.168.7.253 offline, goodbye Knocking 192.168.7.254 offline, goodbye Knocking 192.168.7.255 offline, goodbye
dhcpd
Bon par contre, j’ai effectué ce test en utilisant le daemon dhcpd et c’est un petit enfoiré malin. Il vérifie régulièrement si les adresses qu’il a distribué sont utilisées. Lorsqu’il arrive à saturation de son pool, il redistribue les adresses qui ne sont apparemment pas en service (bien que les baux n’aient pas encore expiré).
Défenses
Il suffit d’un rien pour empêcher ce type d’attaque, ou pour au moins limiter leur portée.
- Activer le DHCP Snooping sur vos équipements,
- Limiter le nombre d’adresse MAC par port (switchport port-security maximum 1 chez Cisco) de vos switchs d’accès au réseau,
- Utiliser des adresses IP fixes pour vos serveurs.
