Today I encountered an interesting anomaly. I was seeing ARP requests on a DMZ network for IP addresses that were clearly not part of that subnet, coming from a firewall appliance.

This struck me as a vulnerability and was simple enough to prove. I configured one of the other hosts on the DMZ to have an IP address of 208.77.188.166 (www.example.com) and from behind the firewall appliance I made a request for the www.example.com web site. As expected, the firewall appliance did an ARP request for 208.77.188.166 on the DMZ, my other host replied and the firewall happily sent the HTTP request to my test host, even though the IP address is not on the same subnet as the appliance's public IP address. It's worth pointing out that all other web sites could be browsed correctly from behind the firewall appliance at this time.

I examined the firewall appliance's configuration and the cause became apparent: the default gateway had been set to its own public IP address! It had been configured with the correct subnet mask and IP address. So, it was seeing its own IP addresses were not part of the subnet that the target 208.77.188.166 might belong to, so it correctly sent the packets via the default gateway. But, this being configured to itself must have some infinite loop prevention and simply resorted to checking the DMZ for the existence of that IP address, which it found.

This is where I think the vulnerability is. The routing seemed to be matching the routing table's default gateway route entry (0.0.0.0 netmask 0.0.0.0) instead of doing a failed match on the public interface's configuration (x.y.z.a netmask 255.255.255.0) which should have returned a "no route to host" error when trying to reach 208.77.188.166. What's even stranger is that the other traffic somehow made it upstream via the correct gateway!

The configuration was corrected and the problem vanished of course. But are there situations where a host would need to configure itself as its own default gateway in the real world? I'm guessing not - unless it's a controlled test environment - but if a user does misconfigure their Linux-based router in this way it would be trivial to pose man-in-the-middle attacks in a similar environment. I guess the same would go for an unethical cable ISP which could allocate the default gateway IP address and host IP address via DHCP and then allocate IP addresses of all your favourite sites to a host they control near you (as long as your ARP requests can reach it) and inspect your packets. But ISPs could intercept your traffic anyway, regardless of this, and so it's not really an issue because we trust our ISPs... right?

My guess is, impact:high and probability:low.

So, routing bug or by design? Comments and feedback welcome.

Update: The same behaviour can be observed in Windows. Testing OpenBSD next.

Update 2: Some people do see ligitimate uses for this, also known as Proxy ARP. The one person commenting on that page even said you'd want to use this for security reasons. Um, no. Using this would allow other hosts to pose as any host you're actually trying to reach, how is this secure?

It's been demonstrated that a script can run as a ghost in Internet Explorer and follow you whereever you surf and even capture your key presses. Heise security blog as an overview of what it does.