Au sommaire ARP Spoofing et ses utilisations MAC Flooding, MITM, DoS, RSTHijacking… Que des attaques délicates dans ce monde de brute-overflow !
ARP Poisoning
Description :
Le principe est d’envoyer des ARP Reply de soi-même. Pourquoi ? Parce que la MAC adresse sur un réseau switché a bien plus d’importance qu’on peut le penser. En effet, on parle souvent de IP, mais IP n’est qu’une surcouche à MAC, pour être précis, IP est en layer 3 et MAC en layer 2. Chaque machine sur le réseau a une adresse MAC et une cache. La cache est en fait une table de correspondances MAC->IP. Ainsi, quand on veut joindre l’ip 192.168.1.100, on ne la joint au final pas avec ip mais avec la MAC. Cette table est souvent dynamique, ainsi, on peut en changer les entrées et associer l’ip X avec une MAC sans aucun liens en envoyant à la victime des ARP Reply. Au final nous avons par exemple 3 machines, la nôtre, A, la passerelle, B, et la victime C. Nous allons donc dire à la victime que l’ip de B est à la MAC Adresse B, ainsi, quand C voudra joindre B il enverra en fait son paquet à A.
Le principe est d’envoyer des ARP Reply de soi-même. Pourquoi ? Parce que la MAC adresse sur un réseau switché a bien plus d’importance qu’on peut le penser. En effet, on parle souvent de IP, mais IP n’est qu’une surcouche à MAC, pour être précis, IP est en layer 3 et MAC en layer 2. Chaque machine sur le réseau a une adresse MAC et une cache. La cache est en fait une table de correspondances MAC->IP. Ainsi, quand on veut joindre l’ip 192.168.1.100, on ne la joint au final pas avec ip mais avec la MAC. Cette table est souvent dynamique, ainsi, on peut en changer les entrées et associer l’ip X avec une MAC sans aucun liens en envoyant à la victime des ARP Reply. Au final nous avons par exemple 3 machines, la nôtre, A, la passerelle, B, et la victime C. Nous allons donc dire à la victime que l’ip de B est à la MAC Adresse B, ainsi, quand C voudra joindre B il enverra en fait son paquet à A.
MAC Flooding:
Les attaques de type ARP Poisoning se retrouvent dans un réseau switché.
Il arrive que, quand certains switchs sont surchargés, ils passent en mode hub, ce qui leur évite de traiter beaucoup de données. Pour rappel, un hub envoie tous les paquets à tous les clients connectés, c’est au client de rejeter ou non le paquet, contrairement à un swtich qui n’envoie les paquets qu’au client avec la MAC de destination.
Il suffit donc de flooder le switch avec beaucoup de fausses réponses ARP spoofées, ce qui va causer la surcharge du cache ARP et le passage en mode hub.
Il arrive que, quand certains switchs sont surchargés, ils passent en mode hub, ce qui leur évite de traiter beaucoup de données. Pour rappel, un hub envoie tous les paquets à tous les clients connectés, c’est au client de rejeter ou non le paquet, contrairement à un swtich qui n’envoie les paquets qu’au client avec la MAC de destination.
Il suffit donc de flooder le switch avec beaucoup de fausses réponses ARP spoofées, ce qui va causer la surcharge du cache ARP et le passage en mode hub.
Denial of Service:
Si on empoisonne ses caches ARP en se faisant passer pour la passerelle du réseau et qu’on cause chez lui une fausse association entre l’IP de la passerelle et un MAC quelconque, dès qu’il voudra par exemple envoyer un paquet sortant du réseau vers Internet, il enverra ce paquet au MAC spécifié. Ce qui permet de rediriger par exemple tout le trafic du réseau vers un serveur et, si ce dernier n’a pas la puissance suffisante pour traiter toutes les demandes, alors il crashera tout simplement.
Man in the Middle:
Si on peut rediriger les flux réseaux, pourquoi ne pas se les envoyer ?
On va mettre en place exactement la même chose que pour une attaque de type DoS sauf que nous rerouterons ensuite les paquets vers la gateway du réseau. Ainsi l’opération sera transparente pour les clients sauf que nous, nous pourrons capturer tout le trafic du réseau, récupérer les mots de passe, injecter des données, casser les SSL très facilement, etc…
Si on peut rediriger les flux réseaux, pourquoi ne pas se les envoyer ?
On va mettre en place exactement la même chose que pour une attaque de type DoS sauf que nous rerouterons ensuite les paquets vers la gateway du réseau. Ainsi l’opération sera transparente pour les clients sauf que nous, nous pourrons capturer tout le trafic du réseau, récupérer les mots de passe, injecter des données, casser les SSL très facilement, etc…
Sécurisation:
- Fixer/Limiter les macs par port sur le switch (port security)
- Rendre statiques les tables ARP (aussi bien client que server)
- Fixer/Limiter les macs par port sur le switch (port security)
- Rendre statiques les tables ARP (aussi bien client que server)
RST Hijacking:
Le principe de RST Hijacking est très simple, il consiste en l’injection d’un
paquet RST spoofé de la machine trompée B à la victime A. Ainsi, la victime
pense que B lui a envoyé un paquet de réinitialisation de la connexion, ce
qu’il va faire. Une connexion réinitialisée n’est pas pour autant inactive. Ainsi, pour B, la connexion est toujours dans un état normal et pour A, la connexion a été réinitialisée, modifiant entre autre le numéro de reconnaissance de B. Ce principe est simple à mettre en œuvre. D’ailleurs, c’est la méthode utilisée dans le fameux firewall chinois, c’est-à-dire que si un pc essaie de contacter un site sur blacklist par exemple, des faux paquets RST sont envoyés et la connexion est réinitialisée. Cette technique a deux pendants : immédiatement, on pense à la possibilité de DoS dans l’éventualité où l’on RST toute connexion sniffée (a plus d’utilité dans un réseau type hub), ou l’utilisation que nous avons décrite pour l’IP Spoofing.
Nous prenons l’hypothèse la plus plausible, à savoir que nous nous trouvons dans un réseau switché. Tout d’abord, il nous faut sniffer un échange entre les deux systèmes. A l’aide d’un seul paquet, on est capable de connaître les numéros de séquence des deux côtés. La connaissance de ces nombres nous permet d’envoyer un paquet RST à A. A recevant un paquet RST, il réinitialise la connexion et incrémente le numéro ACK. On peut couper l’empoisonnement ARP de A pour éviter toute détection et faire revenir son cache ARP à la normale : de toute façon, tout paquet qu’il enverra sera ignoré si nous envoyons un paquet à B avant lui. Il ne nous reste plus qu’à envoyer des paquets spoofés de A à B, ce dernier croyant à un dialogue de A, il renverra les paquets à A qui, pour lui, se trouve à notre MAC. Le détournement et le spoof sont réussis. Cette technique est particulièrement intéressante pour toutes les connexions à identification unique (typiquement quand on saisit un mot de passe au début de la connexion, ce qui représente une bonne partie des connexions existantes).
paquet RST spoofé de la machine trompée B à la victime A. Ainsi, la victime
pense que B lui a envoyé un paquet de réinitialisation de la connexion, ce
qu’il va faire. Une connexion réinitialisée n’est pas pour autant inactive. Ainsi, pour B, la connexion est toujours dans un état normal et pour A, la connexion a été réinitialisée, modifiant entre autre le numéro de reconnaissance de B. Ce principe est simple à mettre en œuvre. D’ailleurs, c’est la méthode utilisée dans le fameux firewall chinois, c’est-à-dire que si un pc essaie de contacter un site sur blacklist par exemple, des faux paquets RST sont envoyés et la connexion est réinitialisée. Cette technique a deux pendants : immédiatement, on pense à la possibilité de DoS dans l’éventualité où l’on RST toute connexion sniffée (a plus d’utilité dans un réseau type hub), ou l’utilisation que nous avons décrite pour l’IP Spoofing.
Nous prenons l’hypothèse la plus plausible, à savoir que nous nous trouvons dans un réseau switché. Tout d’abord, il nous faut sniffer un échange entre les deux systèmes. A l’aide d’un seul paquet, on est capable de connaître les numéros de séquence des deux côtés. La connaissance de ces nombres nous permet d’envoyer un paquet RST à A. A recevant un paquet RST, il réinitialise la connexion et incrémente le numéro ACK. On peut couper l’empoisonnement ARP de A pour éviter toute détection et faire revenir son cache ARP à la normale : de toute façon, tout paquet qu’il enverra sera ignoré si nous envoyons un paquet à B avant lui. Il ne nous reste plus qu’à envoyer des paquets spoofés de A à B, ce dernier croyant à un dialogue de A, il renverra les paquets à A qui, pour lui, se trouve à notre MAC. Le détournement et le spoof sont réussis. Cette technique est particulièrement intéressante pour toutes les connexions à identification unique (typiquement quand on saisit un mot de passe au début de la connexion, ce qui représente une bonne partie des connexions existantes).
Articles
