Saturday, December 28, 2013

Masscan does ARP

My portscanner, masscan, also does ARP scanning. Sure, there exists other ARP scanning tools (like arpscan), but I'm too lazy to learn how they work, so I just added the functionality to my tool.

Here's how you use it. Right now I'm plugged into the local wired Ethernet. When I do an ifconfig, I get the following result:
inet 10.59.36.10 netmask 0xffff0000 broadcast 10.59.255.255
That means there is an entire /16 of devices out there. I want to discover them, so I run masscan with the following parameters:
masscan 10.59.0.0/16 --arp --source-ip 10.59.36.200 --source-mac 66-55-44-33-22-11 --rate 1000
This produces results that look like:

Starting masscan 1.0 (http://bit.ly/14GZzcT) at 2013-12-28 04:39:52 GMT
 -- forced options: -sS -Pn -n --randomize-hosts -v --send-eth
Initiating SYN Stealth Scan
Scanning 65536 hosts [1 port/host]
Discovered open port 0/arp on 10.59.1.1 
Discovered open port 0/arp on 10.59.30.11
Discovered open port 0/arp on 10.59.30.4
Discovered open port 0/arp on 10.59.33.187
Discovered open port 0/arp on 10.59.31.46
Discovered open port 0/arp on 10.59.33.151
...

There's some weirdness in the how it displays the results. It claims things are "ports" because masscan is port scanner, even though ARP has no ports. I should probably fix this.

In the above example I spoof the source IP and MAC address. This isn't strictly necessary, because if you don't specify it, masscan will use use the IP/MAC of your current configuration. But in general, masscan should always be used in spoofing mode, so I include it on general principles.

The reason I added it is because on the flight back from BruCon (a Belgian cybsec convention), I was upgraded to business class, which had an Ethernet port. Attaching a cable to the Ethernet gave me link status, but no DHCP results. Also, tcpdump revealed no packets at all coming from the port. Therefore, I needed to scan the port to see if anything was listening, so I quickly added the ARP scanning code to masscan, then blasted the port. I first scanned the private address ranges, then the rest of the Internet address ranges. Despite being a 100-mbps, I can just about scan the entire 32-bit address space in the 10 hours of the flight. I didn't find anything, but that could be because transmitting at 150,000 ARP requests per second can overwhelm whatever device they have on the other end that might respond.

That last point is pretty important: transmitting ARP packets are sent to the broadcast address (ff-ff-ff-ff-ff-ff), and thus, are received by every machine on the local link. Masscan is very fast, usually faster than the receiving machines can handle. You can easily go too fast, causing receiving machines to drop packets. They cannot respond to a request if they drop it. Thus, you'll miss results at high speeds that you'd otherwise get at a slow speed. And, you might DoS machines on the local segment, which will anger people.

One issue is the right IP address to use. As far as I can tell, testing with Windows, Mac OS X, and Linux, any IP address can be used. Let's say a target machine has an IP address of 10.2.4.6, with a subnet mask of 255.255.255.0. In my tests, you can still use an IP address like 192.168.1.2 that is outside the target's subnet, and it'll still respond to the ARP.


Anyway, if you use masscan, just remember that instead of port numbers, you can specify --arp, and it'll do pretty much what you'd expect it to do.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.