Common Misconceptions About ARP Cache Poisoning
In this article I comment on a few misconceptions about ARP cache poisoning that I come across from time to time, even from people who know what ARP cache poisoning is and (more or less) how it works.
If you don't know what ARP cache poisoning is, this article won't help you. A good place to start may be this article by Steve Gibson or this other article by Yuri Volobuev , more advanced and which includes the source code for send_arp (send_arp.c), a tool I'll be naming below.
*** DISCLAIMER ***
If you perform an attack based on the information contained in this article it will be your sole responsibility. Make sure you have appropriate authorization before doing anything that might get you into trouble and please understand that manipulating network traffic is something that can get you into trouble. You've been warned.
*** END OF DISCLAIMER ***
So, on to the misconceptions:
1.- You need very advanced and complicated tools to perform ARP cache poisoning
It depends on what you mean by advanced and complicated. All you need is a simple tool capable of sending ARP replies that let you choose the source and destination IP addresses and MAC addresses. My favorite is "send_arp", the source code of which you can find in this article by Yuri Volobuev . You invoke send_arp like this:
send_arp IP1 MAC1 IP2 MAC2
That command will send a single ARP reply stating "IP1 is at MAC1" targeted at system with IP address IP2 and MAC address MAC2.
The rest will depend on what you want to do. If you want the traffic to flow through your box you will need to enable IP forwarding in it. In Linux this can be done with the following command:
echo "1" > /proc/sys/net/ipv4/ip_forward
If you want to sniff the redirected traffic you will obviously need a sniffer (e.g. WireShark or tcpdump), and so on for the different things you want to do, but strictly speaking, for the "ARP cache poisoning" part, you really don't need anything other than send_arp.
2.- ARP cache poisoning only works against hosts of specific operating systems (OS).
Maybe, but I still have to find one OS which it doesn't work against :-). Per the ARP protocol specification itself a host must accept ARP replies at some point or another. The only exception is hosts where ARP is deactivated and static MAC-to-IP translations are used. Those hosts are protected against ARP cache poisoning, but of course they are a pain in the neck to manage, so not many people use it in the real world.
A palliative solution implemented on some OS (I believe this is the case at least in Solaris) is ignoring gratuitious ARP replies, meaning that the host will only accept ARP replies for queries it previously sent. That certainly makes the life of the attacker harder, but just a little bit. It's a race condition: when the system sends an ARP request it will accept the first reply to come back. If the reply from the attacker comes faster than that from the real host it will be accepted. Of course the attacker may improve his/her chances by continuously sending replies till one gets lucky. Once the "poisoned" translation is in the ARP cache it will stay there, undisturbed :-), until it times out and a new ARP query is sent (default is 10 min in Solaris, IIRC).
3.- You can use ARP cache poisoning against hosts on the same LAN only, therefore you can only sniff on connections where the two endpoints of the communication are sitting in the same LAN as you.
Well, yes and no. It's true that ARP cache poisoning is a LAN only thing, so only hosts on the same LAN of the attacker can be poisoned, but routers are also "hosts" in this context: they too can be ARP-cache-poisoned. In general, any traffic exchanged between two MAC addresses in the LAN can be redirected through the attacker's system. The case of two local hosts talking to each other is the most obvious, but an attacker can also sniff traffic going from HOST1 to some system outside the LAN by convincing HOST1 that the MAC address of its default router is that of the attacker's system and convincing the default router that the MAC address of HOST1 is that of the attacker's.
4.- An ARP cache poisoning attack would immediately be detected because it would disrupt all or at least some communications in the LAN.
Not true. If the attacker disrupts any communication it will be their own fault (or intent), not the technique's per se.
Quite often the problem is that people performing the attack forget to turn on IP forwarding on their system and then all traffic that should go _through_ their system ends up being _absorbed_ by it and yes, all communication between the poisoned systems becomes impossible and people won't appreciate it (been there, done that :-/). Worse, if you choose to poison every system on the LAN and you make a mistake like this forgetting to enable IP forwarding you will get nothing less than total chaos (again, not proud of it, but been there, done that :-/ ).
A final word of caution about automated tools, if you let me. If you're going to use them, make sure you know them well. Some automated tools may poison all systems in the LAN by default and then forget to turn on IP forwarding, or do the forwarding themselves just fine at the beginning but then die miserably half way through... and it's not pretty. I've been burnt before and thus I prefer to use good old send_arp to send just the few ARP packets I need and good old Linux kernel for IP forwarding. Call me chicken...
5.- Some switches hung when you send one of those fake ARP replies through.
Well, I can't say I've tried every switch out there so maybe there's some switch that will die if you try to do ARP cache poisoning through it. Yet, chances are that if that happens the reason be that the ARP reply being sent wasn't the right one.
Here is the thing. As long as all the fake ARP replies the attacker sends always say "whatever_IP is at my_real_MAC" (my_real_MAC being the real MAC address of the attacker's system) the switch should never complain. As far as he is concerned those replies match what he knows about the attacker's system: its MAC address (my_real_MAC) is connected to the port it is really connected to. Note that the switch doesn't care about IP addresses so the IP addresses in the ARP reply are simply ignored by it.
However, the attacker may get into trouble if he/she tries to revert the wrongdoing after being finished with the attack by sending a gratuitious ARP reply to the target system containing this time the real IP-to-MAC translation instead of the poisoned one. That will confuse the switch because this packet will mean to it that the MAC address of the spoofed system is connected to your port, but that MAC was already connected to some other port!. That will leave the switch with a duplicate entry on its MAC-to-port translation table (one MAC in two different ports). Different switches will react differently to this anomaly, but none will be "happy" with it, if you know what I mean ;-).
David.
If you don't know what ARP cache poisoning is, this article won't help you. A good place to start may be this article by Steve Gibson or this other article by Yuri Volobuev , more advanced and which includes the source code for send_arp (send_arp.c), a tool I'll be naming below.
*** DISCLAIMER ***
If you perform an attack based on the information contained in this article it will be your sole responsibility. Make sure you have appropriate authorization before doing anything that might get you into trouble and please understand that manipulating network traffic is something that can get you into trouble. You've been warned.
*** END OF DISCLAIMER ***
So, on to the misconceptions:
- You need very advanced and complicated tools to perform ARP cache poisoning
- ARP cache poisoning only works against hosts of specific operating systems (OS)
- You can use ARP cache poisoning against hosts on the same LAN only, therefore you can only sniff on connections where the two endpoints of the communication are sitting in the same LAN as you.
- An ARP cache poisoning attack would immediately be detected because it would disrupt all or at least some communications in the LAN
- Some switches hung when you send one of those fake ARP replies through
1.- You need very advanced and complicated tools to perform ARP cache poisoning
It depends on what you mean by advanced and complicated. All you need is a simple tool capable of sending ARP replies that let you choose the source and destination IP addresses and MAC addresses. My favorite is "send_arp", the source code of which you can find in this article by Yuri Volobuev . You invoke send_arp like this:
send_arp IP1 MAC1 IP2 MAC2
That command will send a single ARP reply stating "IP1 is at MAC1" targeted at system with IP address IP2 and MAC address MAC2.
The rest will depend on what you want to do. If you want the traffic to flow through your box you will need to enable IP forwarding in it. In Linux this can be done with the following command:
echo "1" > /proc/sys/net/ipv4/ip_forward
If you want to sniff the redirected traffic you will obviously need a sniffer (e.g. WireShark or tcpdump), and so on for the different things you want to do, but strictly speaking, for the "ARP cache poisoning" part, you really don't need anything other than send_arp.
2.- ARP cache poisoning only works against hosts of specific operating systems (OS).
Maybe, but I still have to find one OS which it doesn't work against :-). Per the ARP protocol specification itself a host must accept ARP replies at some point or another. The only exception is hosts where ARP is deactivated and static MAC-to-IP translations are used. Those hosts are protected against ARP cache poisoning, but of course they are a pain in the neck to manage, so not many people use it in the real world.
A palliative solution implemented on some OS (I believe this is the case at least in Solaris) is ignoring gratuitious ARP replies, meaning that the host will only accept ARP replies for queries it previously sent. That certainly makes the life of the attacker harder, but just a little bit. It's a race condition: when the system sends an ARP request it will accept the first reply to come back. If the reply from the attacker comes faster than that from the real host it will be accepted. Of course the attacker may improve his/her chances by continuously sending replies till one gets lucky. Once the "poisoned" translation is in the ARP cache it will stay there, undisturbed :-), until it times out and a new ARP query is sent (default is 10 min in Solaris, IIRC).
3.- You can use ARP cache poisoning against hosts on the same LAN only, therefore you can only sniff on connections where the two endpoints of the communication are sitting in the same LAN as you.
Well, yes and no. It's true that ARP cache poisoning is a LAN only thing, so only hosts on the same LAN of the attacker can be poisoned, but routers are also "hosts" in this context: they too can be ARP-cache-poisoned. In general, any traffic exchanged between two MAC addresses in the LAN can be redirected through the attacker's system. The case of two local hosts talking to each other is the most obvious, but an attacker can also sniff traffic going from HOST1 to some system outside the LAN by convincing HOST1 that the MAC address of its default router is that of the attacker's system and convincing the default router that the MAC address of HOST1 is that of the attacker's.
4.- An ARP cache poisoning attack would immediately be detected because it would disrupt all or at least some communications in the LAN.
Not true. If the attacker disrupts any communication it will be their own fault (or intent), not the technique's per se.
Quite often the problem is that people performing the attack forget to turn on IP forwarding on their system and then all traffic that should go _through_ their system ends up being _absorbed_ by it and yes, all communication between the poisoned systems becomes impossible and people won't appreciate it (been there, done that :-/). Worse, if you choose to poison every system on the LAN and you make a mistake like this forgetting to enable IP forwarding you will get nothing less than total chaos (again, not proud of it, but been there, done that :-/ ).
A final word of caution about automated tools, if you let me. If you're going to use them, make sure you know them well. Some automated tools may poison all systems in the LAN by default and then forget to turn on IP forwarding, or do the forwarding themselves just fine at the beginning but then die miserably half way through... and it's not pretty. I've been burnt before and thus I prefer to use good old send_arp to send just the few ARP packets I need and good old Linux kernel for IP forwarding. Call me chicken...
5.- Some switches hung when you send one of those fake ARP replies through.
Well, I can't say I've tried every switch out there so maybe there's some switch that will die if you try to do ARP cache poisoning through it. Yet, chances are that if that happens the reason be that the ARP reply being sent wasn't the right one.
Here is the thing. As long as all the fake ARP replies the attacker sends always say "whatever_IP is at my_real_MAC" (my_real_MAC being the real MAC address of the attacker's system) the switch should never complain. As far as he is concerned those replies match what he knows about the attacker's system: its MAC address (my_real_MAC) is connected to the port it is really connected to. Note that the switch doesn't care about IP addresses so the IP addresses in the ARP reply are simply ignored by it.
However, the attacker may get into trouble if he/she tries to revert the wrongdoing after being finished with the attack by sending a gratuitious ARP reply to the target system containing this time the real IP-to-MAC translation instead of the poisoned one. That will confuse the switch because this packet will mean to it that the MAC address of the spoofed system is connected to your port, but that MAC was already connected to some other port!. That will leave the switch with a duplicate entry on its MAC-to-port translation table (one MAC in two different ports). Different switches will react differently to this anomaly, but none will be "happy" with it, if you know what I mean ;-).
David.
Labels: Pentest
posted by David Perez at 6:28 PM
8
comments
