Targeted ARP packets getting forward to broadcast
Hi all,
I've been working on a project that attempts to use ARP spoofing / poisoning for less nefarious purposes in the home security world (e.g. Circle and Firewalla). I've been observing a behavior that I can't seem to pin down and was hoping someone might be able to help me understand better what is going on.
I produce ARP packets that target specific devices on the network to spoof, and can observe expected packets in Wireshark like this from my laptop:
b8:27:eb:19:f1:1f b8:27:eb:19:f1:1f f0:18:98:14:2a:51 ARP 42 192.168.11.1 is at b8:27:eb:19:f1:1f
These packets are produced using ScaPy, and we do sometimes produce multiple of them at a time and send them out serially. However, eventually (there is always a time delay between it working as expected initially and then acting up), I start to identify packets produced by the spoofing machine that are ending up not at the target but instead broadcast to the entire network:
b8:27:eb:19:f1:1f b8:27:eb:19:f1:1f ff:ff:ff:ff:ff:ff ARP 60 192.168.11.1 is at b8:27:eb:19:f1:1f
These packets that end up at broadcast will still list the ARP layer with the correct sender and destination information:
Address Resolution Protocol (reply)
Hardware type: Ethernet (1)
Hardware size: 6
Protocol size: 4
Opcode: reply (2)
Sender MAC address: b8:27:eb:19:f1:1f
Sender IP address: DD-WRT (192.168.11.1)
Target MAC address: a6:17:db:5a:05:64
Target IP address:iPhone.home (192.168.11.115)
But at the Ethernet layer I'm seeing broadcast as the Destination instead of the MAC of the true target:
Ethernet II, Src: b8:27:eb:19:f1:1f, Dst: ff:ff:ff:ff:ff:ff
Destination: ff:ff:ff:ff:ff:ff
Source: b8:27:eb:19:f1:1f
Type: ARP (0x0806)
Padding: 000000000000000000000000000000000000
I'm hoping someone can help me understand how these broadcasts that aren't explicitly sent to broadcast are ending up there anyway - is this an expected behavior, maybe for devices that aren't available to successfully receive the packet that was sent out? Is this behavior different by router model / manufacturer or expected based on the protocol and is otherwise universal? The current setup is running through a DD-WRT-based router. What's more, is there any way to prevent this from happening automatically?
Thanks in advance!
~Michael
Could this be an issue in your networking stack?
Are they flagged as Gratuitous ARP in Wireshark?
Do you explicitly set the destination MAC in scapy and it is getting overwritten?
Couple quick answers:
(more)@hugo.vanderkooij - by networking stack do you mean on the machine sending the ARPs (rather than the networking stack on the router)? It's certainly possible, but it isn't a hard problem - as in, it starts by acting correctly and then devolves. The device sending the ARPs is an embedded Linux device run on a Raspberry Pi 3 for the time being.
@Chuckc they are not flagged as such, though that's effectively what they are. They're type-2 ARP replies that haven't been requested.
@Bob Jones That's correct, the destination MAC is explicitly set in scapy and is overwritten eventually. We get minutes of proper, targeted ARPs sent before they devolve and are forwarded to broadcast. I've been suspicious that this might be particularly true for devices that don't always respond to pings and ARPs (like mobile devices that turn wifi ...
Did you isolate the source of these? Is your RaspberryPI sending them? Or is another entity on the network sending them? Sniffing in various locations should narrow down the source.
@Bob Jones - so yes, the source of these ARPs is very clearly the Raspberry Pi, especially since they happen at a regular interval (every second).
Sniffing in various locations reveals the same thing, particularly because these are broadcast ARPs. For instance, sniffing from my laptop initially shows no ARP packets because they aren't being targeted to this MAC. Within 10 minutes though, I'll start to see these ARPs when running Wireshark on my laptop, because they start to "leak" to broadcast instead of their intended targets.
What OS is the Pi running?
@Chuckc - the Pi's running an embedded, Yocto-based distribution (BalenaOS for reference). Inside the OS is a Debian-based container that that's actually running Python to send out the ScaPy-based packets