Blog: Hardware Hacking

Reverse Engineering 4G Hotspots for fun, bugs and net financial loss

G Richter 10 Aug 2019

a.k.a. 4G hotspots and their Discontents

You might be here because you saw our talk at Defcon 27. You might want to watch that for the full rundown!

TL;DR

We found multiple vulnerabilities in several well known vendors Mi-Fi devices, including pre- and post-auth command injection and code execution

The vendors involved were generally poor at responding to disclosure attempts

One vendor (ZTE) tried to tell us that the product was end of life, so wouldn’t be fixed… yet they were still selling it from their own online store!

The Storyline

This year we’ve been looking at quite a few consumer-grade (non-phone) cellular devices – in particular cellular dongles and routers. Most major networking device manufacturers sell them, and they’re usually (relatively) low-cost, since they’re more for personal, sporadic use than for ongoing large-scale Internet access.

But, since “5G is coming” (as I’m sure it will be for quite a while), devices like this are probably going to pick up in popularity. Data costs are continuing to go down. In increasing numbers, lots of less-bandwidth-demanding consumers are inevitably going to start using cellular for their full-time Internet access.

Those manufacturers who are going to be selling 5G routers are currently selling 3G and 4G routers. Which – and I really cannot stress this enough – are mainly bad.

Why Routers?

There’s quite a lot going on in a router. Most of them are running some flavour of embedded Linux. In cellular routers, there’s also a baseband to worry about. There’s the IP interface (TCP/UDP IP) you’d expect from any “traditional” router, but there’s also a cellular interface (SMS, MMS, voice, etc) – and sometimes even Bluetooth or another “surprise” protocol strapped on.

In our little research project, we focused mainly on attacking services on the IP layer. We’ve reported everything we found to vendors, who have mainly fixed the issues (except when they haven’t – and by now they’ve had more than long enough!).

We’ve also put together a series of blog posts about some of the more interesting things we found, and how easy they were to find. Hopefully this will give others a nice easy introduction to cellular devices, and the kinds of strategies you can use to start reverse-engineering and poking at them.

Here’s a TL;DR for each of the devices, including a rundown of how the disclosure went (spoiler: it was usually bad), a few of the “fun” things we found, the bugs we found, plus a link to more detailed posts we wrote for each:

ZTE

The disclosure process

We had a look at a few different ZTE hotspots. Initially we looked at the MF910, and tried to disclose. The process went a lot like this:

  • We disclosed some issues to ZTE, who told us that this product is end of life, so these issues will not be fixed.
  • This is despite the fact that the product is still readily available, and still listed on official ZTE websites, without any indication that it is no longer supported.
  • We had a suspicion that these issues would affect other products in the MF* line, since a lot of code appeared to be shared between them, and asked ZTE to confirm that these issues did not also affect other devices.
  • ZTE brushed this off.
  • We asked ZTE for a list of supported devices, which we never received.
  • We ordered a device we guessed was “supported” (MF920), and found (almost) the exact same issues.
  • ZTE have subsequently fixed the issues in the MF920.
  • ZTE appear to triage vulnerabilities on a per-device basis, despite the fact that they share a codebase. Either that, or they have fixed issue in other versions of the MF*series without telling us, and without making this clear in their public vulnerability disclosure.

Fun stuff

  • There are several debug functions hidden in the MF910 web server firmware.
  • One example is a remote syslog mode, which returns a lot of debug information about the ZTE custom binaries out to the requesting IP address on port 514.
  • There are also several ways of enabling adb (Android Debug Bridge) over USB – which allows someone with a USB connection to get a root shell without any further authentication.

Bugs

In the MF910, none of these are going to get fixed. We found a few really similar issues in the MF920, but those have apparently been fixed since we reported them.

  • The administrator password can be leaked (pre-authentication).
  • One of the (post-authentication) debug endpoints is vulnerable to command injection.
  • There’s also a Cross-Site Scripting point in a totally unused “test” page.
  • These issues could be chained together to allow arbitrary code to be executed on the router, just by a user visiting a malicious webpage.

For the ZTE MF910, we’ve written up a short post detailing some of the more “interesting” endpoints we found.

Two CVEs were assigned by ZTE for issues we found in the MF920:

  • CVE-2019-3411 – Information Leak
  • CVE-2019-3412 – Arbitrary Command Execution

Netgear

The disclosure process

  • Netgear run a bug bounty through Bugcrowd.
  • They pay out rewards based on CVSSv3 scores. But they require absolute public silence about the issues that are found.
  • From looking at the vague disclosures on the Netgear website, there’s also an argument that they artificially deflate CVSSv3 scores so that the payout threshold is lowered (e.g. $300 instead of $600). Since we don’t have any public visibility into the actual bugs, it’s very hard to say this categorically.
  • We reported issues to them in February, outside of the Bugcrowd process, because we wanted to write and speak about issues publicly.
  • By the time we speak about this at Defcon, it will have been over 5 months since we first disclosed.

Fun stuff

  • There’s an operational JTAG interface on the device.
  • The firmware is encrypted using XOR and AES. The XOR key can be derived by statistical analysis, and the AES key can then be extracted from the data that’s been XOR decrypted.
  • This means that with a bit of work and analysis, every firmware file for the M1 can be easily decrypted.

Bugs

  • Post-authentication command injection. This allows any connected authenticated user to execute arbitrary commands over the web interface.
  • Cross-site request forgery bypass. The CSRF tokens are returned in dynamically-generated JavaScript file called NetgearStrings.js. Since JavaScript files can be included from external domains, this means that any website could easily include the NetgearStrings.js file and read the CSRF token out, thereby breaking the CSRF protection.
  • If the user hasn’t set a strong password on the web interface, these bugs can be chained to execute arbitrary code on device, if a user visits a malicious page.

We wrote two posts about this – one covering the firmware decryption journey, and another about how simple the CSRF protection bypass is:

Two CVEs were assigned for the issues we found in the Nighthawk M1:

  • CVE-2019-14526 – Cross-Site Request Forgery Protection Bypass
  • CVE-2019-14527 – Post-Authentication Command Injection

Others

We don’t talk about quite a few other issues we found in other devices in this particular talk. We found things like a post-authentication DoS in a Huawei dongle, and a few command injections in a TP-Link router. There’s also quite a few more devices more on the backburner – so you may well see some more content in the coming months.

Anyway, we wrote up the TP-Link command injection here, along with enough steps to help budding reverse engineering get used to Ghidra:

Two CVEs were assigned for the issues we found in the TP-Link:

  • CVE-2019-12103 – Pre-Authentication Command Execution
  • CVE-2019-12104 – Post-Authentication Command Execution