Ghosts From The Past: Authentication Bypass And OEM Backdoors In WiMAX Routers

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.

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.

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 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.