Why Ethernet Broadcast Escape Tests Matter

We recently implemented a network escape to SensorFu Beacon that uses Ethernet broadcasts. Why? First of all you can test all the hosts in the LAN (Local Area Network) with one packet. Second, with broadcast frames, all the devices in the LAN think the frame is for them. Once we get past that point, we get to play with the funny ways how network stacks work. In the last 10 years of network security auditing, we’ve seen devices act in interesting and sometimes exploitable ways when presented with specific types of broadcast frames.

How it works

On a local network, your data travels inside Ethernet frames. Every network device typically has a manufacturer assigned unique address (MAC address), which is used to identify a frame’s sender and recipient. Other protocols can be encapsulated within these frames, that’s how your computer sends an IPv4 or IPv6 packet to the network.

Broadcast

Broadcast frames are special frames that are delivered to every device on the LAN. They’re sent to a specific address, FF:FF:FF:FF:FF:FF. Broadcast frames are commonly used for service discovery and DHCP.

What about IP?

Ethernet is the protocol used to deliver IP packets in a local network. Anything you send to a specific host is sent to that host’s MAC address. If you need to send something outside the local network, you send it to the gateway’s MAC address.

With IPv4 and IPv6, there’s a similar concept of broadcast packets, but that’s not what this blog post and test is about.

Escape with broadcast

In our years of auditing, we’ve found multihomed (=connected to multiple networks) hosts to be a common sight in isolated environments. A router/firewall is probably the most common example. Sometimes you also see multihomed servers, maybe even a workstation or two. Multihomed servers might be used to provide services to multiple networks, when network isolation would otherwise make it difficult. The NTP server below is one example.

So what’s the difference between a router/firewall and multihomed server? Not much, depending on how you look at it. Both are connected to multiple networks, have a functioning network stack, and multiple IP addresses. They might even be running the same operating system and local firewall. For example, OpenBSD with PF.

Our Broadcast Beacon take advantage of this similarity.

What makes broadcast frames useful is that hosts won’t immediately drop them upon receiving. Instead, they’re de-encapsulated and the contained IP packet (or other content) is passed further up the system’s network stack. This is where things get interesting.

If the network stack’s firewall doesn’t drop the packet for whatever reason, and the host has IP forwarding enabled, then it will say “I’m not the recipient of this packet, but I can send it forward towards the appropriate network”. Now your server has become a router.

Luckily, most operating systems have IP forwarding disabled by default. And firewalls should usually drop packets not intended for their host systems. But these are all configurable things, so there’s always a chance for failure. All it takes is one system with the right (wrong) settings, to open up a hole to the outside world.