Ghosts from the past: Authentication bypass and OEM backdoors in WiMAX routers

Update 2017-06-09: Huawei has released a Security Notice. They recommend "that users replace old Huawei routers with those of later products".

SEC Consult has found a vulnerability in several WiMAX routers, distributed by WiMAX ISPs to subscribers. The vulnerability allows an attacker to change the password of the admin user. An attacker can gain access to the device, access the network behind it and launch further attacks, add devices into a Mirai-like botnet or just simply spy on user. This vulnerability affects devices from GreenPacket, Huawei, MADA, ZTE, ZyXEL, and others. Some of the devices are accessible from the web (estimate is from 50.000 to 100.000). Affected vendors were informed by CERT/CC who released a vulnerability note (VU#350135, CVE-2017-3216).

Further information about the disclosure timeline and affected devices can be found in our advisory. This blog post has some highlights from the vulnerability analysis.

While doing research on HTTPS Certificate and SSH Key Reuse we stumbled upon a group of 80.000 devices that are using a certificate issued to "MatrixSSL Sample Server Cert" for the HTTPS web interface. The devices in question are WiMAX gateways likely developed by ZyXEL or its sister company MitraStar. We managed to get our hands on one device and did a bit of analysis.

WiMAX is a technology similar to LTE. Altough LTE is more popular nowadays, still many WiMAX networks exist all over the world.

Based on the information we got from internet-wide scan data, we know that a lot of devices expose a web server on the WAN interface. This is caused by a misconfiguration, or more likely carelessness by the ISPs that provide WiMAX gateways to customers. Web interfaces are usually a good place to hunt for vulnerabilities.

Like in all IoT pentests we grabbed a copy of the firmware (luckily available on ZyXEL's website, no hardware hacking via UART, JTAG and desoldering this time!) and uploaded it into our cloud based firmware analysis system IoT Inspector. After a few minutes the analysis results were available.

We start by looking at the file system structure. There are a bunch of HTML files in the /var/www/ directory, but usually these files are just HTML templates and do not contain any further logic.

excerpt from IoT Inspector file system browser

There are no traditional CGIs as well, so the web interface logic is likely embedded in the web server itself. The web server is implemented in /bin/mini_httpd.elf. The name mini_httpd would indicate that this is somehow related to the mini_httpd open source project, but either we are dealing with something completely different or a heavily modified version of the open source project. On first sight the web server does not contain the web interface logic as well, but there is a function that loads libraries located in the /lib/web_plugin/ directory using dlopen() and resolves several symbols.

Looking at /lib/web_plugin/ there is only one library called libmtk_httpd_plugin.so. At the location of the symbol mime_handlers there is an array of structures that describe how different URI patterns are handled. This library also contains the implementation of the request handlers.

For each incoming request the web server tries to find a matching pattern in the mime handlers array and if a matching pattern is found, a function pointer to the function that handles the request will be called. Because we are in a good mood, we tell IDA Pro how we think how such structure looks like and convert the entries in the mime_handlers list.

We now have a pretty good understanding which URIs exist and how they are processed. The structure even contains an enum that specifies if the user has to be authenticated or not (we called it AUTH_REQUIRED/UNAUTHENTICATED). There are lots of URIs that do not require any authentication and are worth having a closer look, but we will focus on commit2.cgi.

The handler of this function just stores the arguments and values of an URL-encoded HTTP POST request into the internal database (key-value store, probably persisted in NVRAM). The simplest exploit for this vulnerability is to change the administrator password (argument ADMIN_PASSWD). Afterwards one can log in via the web interface and do some post-exploitation.

So what can we do from here on? Depends on the goal of the attacker. The web interface has a ton of functionality that could be of interest. This functionality allows changing the DNS servers (banking fraud, ad fraud), uploading malicious firmware that for example contains a botnet client or monitors the WiMAX customers internet activity. The SSH/Telnet daemon is quite interesting too...

OEM Backdoors in practice

The SSH/Telnet daemon can be enabled via the web interface. One can login using the same credentials as for the web interface and get a simple Cisco-style CLI. There are various commands that likely allow an attacker to escape it and get a regular Linux shell. But there is more:

While we focused on manual analysis of the web server for now, the results from IoT Inspector's automated analysis are quite interesting as well. One of the IoT Inspector plugins collects hardcoded Unix-style password hashes and submits them to our GPU-Server for cracking.

excerpt from IoT Inspector results

Some of the password hashes seem to be default password or placeholder files. The hashes in the file minihttpd.trans are quite interesting.

Despite its name, minihttpd.trans sets up the Linux /etc/passwd and /etc/shadow files at system boot. Below is an excerpt from the script.

This part of the script adds two backdoor users to the /etc/passwd and /etc/shadow files. The user mfgroot always has the same password hash $1$.3r0/KnH$eR.mFSJKIiY.y2QsJVsYK. (%TGBnhy6m), the password of the user root depends on the system variable ZY_CUSTOMER. The list contains the hashes we found in various firmware files.

Greenpacket:
$1$38HlpaTA$bVNplU36JnUr.Xt1IHDCV/

Huawei:

$1$k2I9hJe4$Vg4Qw0w5IwMWb8GlfYhoi1

$1$7cHnPpHF$GbYUst3uAh0sFix3fz7B21

Mitrastar:

$1$k2I9hJe4$VibREr.QRvL4HUkaUAyDr1

ZyXEL:

$1$T6ecjm0M$EzKDcv0pezh9OItLRG8hY/

ZTE:

$1$k2I9hJe4$VibREr.QRvL4HUkaUAyDr1

Cracking the password hashes in the list an exercise left to the reader. Regardless of which OEM customer credentials are set, one can login using the credentials mfgroot:%TGBnhy6m and get a root shell.

Down the IoT supply chain...

The supply chain for IoT devices is often complex. The "commit2.cgi vulnerability" is located in libmtk_httpd_plugin.so. libMTK hints that this library is part of MediaTek software, possibly an SDK that MediaTek provides for customers who build their products on MediaTek SoCs. This makes sense because the affected devices are all based on MediaTek hardware. These SDKs often come with everything that is required to use the hardware and even contain with a working web interface. Vendors can choose to use the whole SDK to build their product or just use some drivers/middleware and build the rest themselves.

CERT/CC contacted MediaTek regarding the vulnerability. They responded that their SDK code is not vulnerable and stated that they suspect that ZyXEL likely added the vulnerable code. Based on the information we suspect it went down like this:

1. MediaTek manufactures a SoC for WiMAX products, provides SDK with sample web interface code to vendors.
2. ZyXEL and their sister company MitraStar develops firmware based on the MediaTek SDK, introduces the "commit2.cgi vulnerability" and the "OEM backdoors".
3. ZyXEL sells the products to ISPs.
4. MitraStar works as an OEM for GreenPacket, Huawei, ZTE... who also sell the products to ISPs.
5. ISPs sell/lease the devices to their subscribers as customer premises equipment (CPE).

Usually OEM customers will not even admit that there is an OEM. We specifically asked Huawei and got this response:

Long supply chains and OEMs make it hard to determine which products are affected by a vulnerability. This is one of the reasons why we developed IoT Inspector. One of the use cases is to see if a specific vulnerability exists in firmware loaded into IoT Inspector. We have used this approach successfully in the past, e.g. for the KCodes NetUSB and the AMX vulnerabilities.

excerpt from IoT Inspector results 

So we created a simple IoT Inspector plugin that detects the "commit2.cgi vulnerability" and used it on a firmware data set that contains the firmware of a few thousand products including all WiMAX CPE firmware we could find on the web. Using this approach we could determine which products from GreenPacket, Huawei, MADA, ZyXEL and ZTE are affected. For a list of affected devices see our advisory.

IoT device life cycle

The affected products are quite old, likely manufactured in the early 2010s. According to Huawei, all of their affected products are end-of-service since 2014, and will not receive any updates. Researcher Pierre Kim has found vulnerabilities in another set of Huawei WiMAX CPEs back in 2015 that suffer the same fate. We reported this vulnerability to CERT/CC who coordinated the vulnerability and released a vulnerability note (VU#350135), thanks! They unfortunately did not get a response from ZyXEL .
It's unlikely that any of the affected devices will receive updates, so the only solution is to replace the them.

ISPs should limit the attack surface on CPEs as much as possible. This is not just limited to the web interface and SSH/Telnet but also to the TR-069 Connection Request Server.

For further information regarding affected devices see our advisory. IoT Inspector now comes with a plugin that detects this vulnerability.

*****

This research was done by Stefan Viehböck (@sviehb) on behalf of SEC Consult Vulnerability Lab. SEC Consult is always searching for talented security professionals to work in our team. More information can be found at: https://www.sec-consult.com/en/Career.htm

TO STAY UPDATED FOLLOW US ON TWITTER.