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
How have you ensured that the broadcast ARP replies are comming from the PI and not from a other network component?
My thought is that a switch or router in your network makes a broadcast out of your spoofed reply, because his mac address list doesn't contains the destination mac anymore, and so he sends it out to all members. And what you've captured as broadcast reply from your Pi is the forwarded packet from that device.
Does it also happen when you run an endless ping or other traffic from the targeted device to your Pi or vice versa, so that the mac tables of all components are permanent up to date?
@JasMan, thanks for the thoughts, this is a really interesting idea.
(more)Define "ensured" that they're coming from the Pi and not another source - would another source show up in the Source field of the Ethernet packet? If that would get properly updated by another device, then yes, the bad broadcasts are actually coming from the MAC of the Pi. That being said, if another device is purely forwarding them and not touching the Source field, then I could be missing a device doing this. Any idea how I could detect which device is doing this? This is my suspicion too (that it may be the router doing this), but it's just a hunch to date.
Just so I'm clear - you think that if I keep a constant packet stream / ping to OR from the Pi, this might force the ARP tables to remain constantly updated and not ...