What did Mirai Miss? Making a better, bigger botnet

We’ve been researching DVR security since February 2016, well before Mirai hit the scene. We knew there was more to be discovered after poking around at a QVIS DVR in October last year that was vulnerable to Mirai, but didn’t feature on the list of vulnerable devices found in the source code.

It’s worth a reminder here that the original Mirai was JUST about DVRs. Not printers, routers or anything else: https://www.pentestpartners.com/security-blog/filling-in-gaps-in-mirai-its-about-dvrs-not-cameras/

So, we spent several man months investigating hardware and software security of over 30 DVR brands and found a whole lot of vulnerabilities that Mirai didn’t use. These include:

• An exploitable buffer overflow over port 80, giving rise to a new DVR botnet of 1M or more devices
• Several DVR brands that were vulnerable to Mirai, but not known about previously
• New telnet credentials that Mirai could have used, but aren’t in the source code
• Mirai telnet interfaces, but not used by Mirai as they ran on ports other than 23. Mmmm, stealthy!
• A daily changing super user password for most Mirai-vulnerable DVRs
• Using the DVR as a pivot to disable your house alarm
• Why BrickerBot didn’t quite work as intended

We also discovered WHY we believe XiongMai is at the root cause of these issues and also found some examples of DVR security done well, despite using the same chipset as insecure devices.

TL;DR? Here’s a summary. The detail is further down

#1: a new set of credentials that need to be added to the list of default creds:

qazxsw

#2: non standard telnet port

TCP port 12323 is used by some DVRs. It’s telnet and vulnerable to the same set of Mirai default creds.

#3 a shell on a different port

Several DVRs we bought offered an interface on TCP/9527. The creds were admin/blank or admin/123456 or similar which led to a shell.

#4 directory traversal

Using the interface above, simple directory traversal can be used to recover the hashed passwords. Crack them offline, then use these to get shell access as root.

#5 exploitable buffer overflows

The scary bit: see below for the detail, but there’s an exploitable buffer overflow in the web interface. This leads to remote code execution and a wormable exploit. Shodan shows ~1M devices available as of today, which would make for a nice botnet.

#6 the dilemma

We’ve also found a route to remotely fix Mirai vulnerable devices. Problem is that this method can also be used to make Mirai persistent beyond a power off reboot. Hajime and BrickerBot used a different, less effective method. Do we publish or not? Currently we’re thinking not.

#87 daily changing super user password

Whilst this is probably only for a local interface, publishing your list of su passwords on the public internet makes for a bad idea!

We haven’t found a DVR that is exploitable using these creds, but we’ve had several reports on Twitter from users that have succeeded.

Commonality between DVRs

Most of the DVRs we looked at were incredibly similar, both in software and hardware. To illustrate:

The one on the left is a Floureon, the one on the right is a different popular brand. Virtually identical, yet there are no vendor markings on the PCBs!

Guess what; virtually identical vulnerabilities too…

The detail

XiongMai provide the DVRs for whitelabelling; many of the exposed web interfaces have no branding. No specific versions are known; the software running on the devices does not report a version.

We found the following utility http://wiki.xm030.com – this is the XiongMai ‘makepack’ tool that describes how vendors should customise their DVR. It covers branding, functionality, credentials and more.

This was the motherlode! Everything we needed to figure out how to pack new binaries for each DVR.

It creates a single monolithic binary called ‘Sofia’ which provides all DVR and remote access functionality.

We believe this is the root cause of the Mirai issue – XiongMai provided insufficient customisation detail to the DVR vendors, resulting in default creds being found in production systems.

We have no idea what this XM DVR app is all about. Very odd; hopefully just lost in translation and not for DVR voyeurism!

Hardcoded telnet password, aka the Mirai problem

The “SDK” uses the above “makepack” utility to customise and brand the OS and UI of the DVR. This mechanism, by default, leaves telnet running on the device with a hardcoded password. The /etc/ directory is read-only, meaning that users cannot change the password without a firmware upgrade.

The password can be changed from default during the vendor customisation process, but the list of 63 credentials used by Mirai has covered all XiongMai based DVRs we tested.

The use of the telnet protocol means any credentials could be intercepted by an attacker.

The running telnet service is not documented, so users are unaware of risk.

Consequence: The Mirai worm.

An attacker with root access to the device can access DVR functionality, use the device to attack the internal network, or add the device to a botnet (as has happened in Mirai and Hajime).

Exploitable unauthenticated buffer overflow in the web service running on port 80

Port 80 is usually forwarded to the internet to allow for remote viewing of the DVR video feed from a mobile device. That’s bad enough…

The web server running on port 80 is vulnerable to a buffer overflow via the GET request, allowing remote code execution. Simply append at least 153 characters and the Sofia process will crash and reboot. This prevents the DVR from recording footage.

A watchdog service will restart it after about 2 minutes, but it can simply be crashed again. Ideal if you’re a thief that wants the CCTV disabled whilst you break in to a building!

The binary running the web service has not been compiled with any of the common mitigations (ASLR, SSP etc.), allowing this to be used for remote code execution.

Here we can see the hex representation of A (41) overwriting memory. From here we can execute arbitrary code. Note that the process is multi-threaded, so a few attempts may be necessary.

As all processes on the device run as root, this allows commands to be run as root.

Consequence: a worse worm than Mirai

This likely to make for a scary botnet; as port 80 is more likely to be externally available – it’s required for remote access from a smartphone to remotely view DVR video feeds. We found a number of XM based DVRs that didn’t offer telnet by default, but did publish port 80. This suggests that the potential botnet that could be created could easily be larger than could be created by Mirai.

We also found a few DVRs that have been updated since Mirai was released. Telnet/TCP23 has been removed from the latest Floureon firmware, but port 80 is still available and exploitable.

It is not easy to fingerprint these devices using telnet, but currently (May 2017), ~720k devices are found to be exposed on Shodan running the XiongMai web server “uc-httpd”.

Debug interface on port 9527

As mentioned above, most XM-based DVRs offer a debug interface running on port 9527, which allows shell access as root using the credentials used for the DVR login. This isn’t always port-forwarded, so the risk is probably lower.

Description

As mentioned above, most XM-based DVRs offer a debug interface running on port 9527, which allows shell access as root using the credentials used for the DVR login. It’s port-forwarded by default, so likely to be found on the public internet in a home user & SME environment.

The debug service running on port 9527 is text based and appears to mainly be for controlling DVR functionality. Access is controlled using the username and password for the DVR functionality (as compared to the OS passwords).

Most devices have a default username and password of admin/123456 or similar. Failing that, a directory traversal vulnerability (CVE-2017-7577) allows the hashed passwords from the device to be recovered and brute-forced offline.

Once connected to the service, a command can be used to get shell access, allowing commands to be run as root.

We also found command injection through the NFS settings page by monitoring UART, though we didn’t take that much further as the cut-down busybox made it difficult to gain persistence.

BrickerBot: why it didn’t work as intended

BrickerBot was supposed to be a ‘healing’ worm – fixing vulnerable DVRs if it could. If it couldn’t, it would brick the DVR.

However, based on our research, it didn’t work as expected.

Here’s a relevant snippet of the BrickerBot code:

Here’s the problem: almost all the DVRs we looked at run a very cut-down version of busybox.

The commands simply aren’t present for most of the functionality that BrickerBot wants to use. Most of the mtdblocks are read-only, so sending random data to them simply doesn’t work.

That said, we did find a couple of DVRs that BrickerBot did trash – we noticed that one of the mtdblocks on the Floureon was read/write, so the attacked worked in a fashion.

House Alarms

Most of the DVRs we looked at had either an RS232 interface or a Bluetooth connection that could be used for monitoring or connecting to other devices.

One of the more popular devices to connect to was a house alarm for obvious DVR home security reasons. In a couple of cases, we found that it was possible to deactivate the house alarm using a compromised DVR.