Owning the Network with BadUSB

Jacob Baines
Tenable TechBlog
Published in
4 min readMar 26, 2019

Man-in-the-Middle with a Raspberry Pi

At the inaugural BSides Dublin last weekend, I gave a talk titled, BadUSB in Routers. The talk described various BadUSB attacks against Netgear, TP-Link, Linksys, Asus, and MikroTik routers. However, one router stuck out as being more susceptible to BadUSB.

Is this guy writing about MikroTik again?!

In the picture above, I have a Raspberry Pi Zero plugged into the USB port of a MikroTik hAP. The router has been convinced to route all internet-bound traffic through the Raspberry Pi, making the Pi the man-in-the-middle.

The PoC video that never seems to end

The obvious question is, “How?!”

How the Attack Works

The answer starts with MikroTik’s support of 3g and 4g USB dongles on a number of their routers. Not just their small routers like the hAP, but some bigger, rack-mounted models as well. The devices have been developed to support a secondary USB WAN interface by default.

The Raspberry Pi, as configured, shows up as an LTE interface

The Raspberry Pi, configured with P4wnP1’s default ethernet device descriptor and the VID/PID for an old Linksys ethernet adapter, is recognized as a new WAN interface. The router sends a DHCP request to obtain an IP address for the new lte1 interface. The Raspberry Pi’s DHCP response contains additional routing instructions in option 121. These additional instructions basically say, “route all internet-bound traffic to the lte1 interface.”

The router’s routing table after accepting the Raspberry Pi’s DHCP response

Samy Kamkar, Rob Fuller, P4wnP1, and I’m sure a host of others have used DHCP options in other BadUSB attacks. But because I’ve attacked a router, the scope of my attack is not limited to one host, but all LAN hosts.

However, we still have a problem. The Raspberry Pi isn’t an actual WAN interface. It’s only path to the internet is back through the router.

Stuck in a routing loop

My solution to this problem was to forward all of the traffic through a VPN server. The “trick” is to not include the VPN server’s address in the option 121 entries. That way, the Raspberry Pi can tunnel the packets to the remote VPN server and the VPN server can forward the data onto the internet.

Hooray for tunnels!

With this solution in place, requests and responses can go to and from the internet. In the following image you can see a traceroute from the LAN travels through the MikroTik router to the Raspberry Pi, then to the VPN server, and finally to the internet.

What’s the Damage?

It might not be clear to everyone, but this is a significant result. Both the Raspberry Pi and the VPN Server can observe or alter all of the internet traffic. In the following image, the client (on the left) browses to securitybsides.com and the VPN server captures the request and responses in Wireshark.

I hope the irony isn’t lost on anyone

Trust But Verify

If you want more technical details, or want to reproduce the attack yourself, then head over to our GitHub repository. There you’ll find additional details on the hardware and software used as well as payloads to use with the P4wnP1 framework.

Future Work

The potential for this attack doesn’t end here. The main attraction of the Raspberry Pi Zero is how cheap it is. But, while it’s fairly small, it’s larger than traditional USB devices. Which might make it impractical for real world attacks. For a bit more money, this attack should be easily ported to a more normal looking USB device like the USB Armory or Teensy.

A USB Armory, pictured above, was used in Rob Fuller’s write up

There are also many more routers with USB interfaces that should be analyzed. I’ve only looked at a small subset of devices. For example, Cisco’s RV series seems like a prime candidate.

Conclusion

This attack is fun but it isn’t anything you should lose sleep over. Just follow these simple guidelines:

  • Control physical access to your router.
  • Disable unused USB ports. On all devices! Not just routers.
  • Regularly inspect your devices for unusual attached hardware.
  • Use encryption wherever possible.
  • Use a VPN on unknown networks (e.g. public WiFi)

--

--