Blog

Building an IoT Botnet: BSides Manchester 2016

03/10/2016 | Author: Admin

Building an IoT Botnet: BSides Manchester 2016

In August, @MDSecLabs delivered a talk at the Manchester BSides titled “Breaking and Entering, Hacking Consumer Security Systems”. The talk outlined research that we had performed in to the security (or lack of), of many IoT devices, specifically consumer security systems such as IP Cameras, DVRs, CCTV and Smart Home Security kits. Specifically, we discussed how these issues could lead to the creation of IoT botnets. In the last week, this prediction came to fruition following one of the largest DDoS attacks the Internet has seen against the krebsonsecurity.com website. The source code believed to facilitate this botnet was recently leaked on HackForums and was shown to exploit weaknesses similar to those described in our talk.

Our research first started back in 2014 when we came in to contact with the DS-7204HWI-SH/A, a widely deployed DVR developed by HikVision. The device is built on top of Linux and BusyBox and at the time was installed with firmware V3.0.1 build140524. The vulnerabilities that we are documenting are resolved in the latest firmware.

To get an understanding of how prevalent these devices and others in the same family are, we can use the “DNVRS-Webs” search term on Shodan, which suggests they are widely used and would be an ideal candidate for building an IoT botnet similar to the one abused by Mirai:

shodan

To gain access to the device, HikVision provide a web interface where the administrator can authenticate to. The default password for the device is 12345, which you are forced to reset during the setup process when physically configuring the device:

pin

As the physical interface only supports numeric passwords in this version of the firmware, there is a high probability that many users will have a numeric only password set. This password is used to authenticate to the device via the web interface. There is no account lockout in place and consequently, the admin password can be trivially bruteforced. Once access has been obtained, the telnetd service can be enabled by querying the “/ISAPI/System/Network/telnetd” endpoint. As the password for the root user account is the same as the configured admin password, a privileged and interactive command shell can be trivially obtained on the device. A demonstration of this attack is shown below:

The exploit code for this attack can be found on the MDSec github page. There were also several other issues found in this device, and you can listen to them in the full talk which is linked at the bottom of this post.

When reviewing this type of device, it’s always useful to have access to underlying operating system to further your assessment. If you have physical access to this model of DVR, you can easily gain a command shell using the device’s on-chip UART port, for which the pin configuration can be found below:

jtag

Once you have physically connected the UART, you will be presented with a shell as the guest user; the root password is the same as the admin PIN configured during setup of the device:

uart1

The next device discussed in our BSidesMCR talk is the RISCO Agility, a widely used intruder alarm system for protecting residential and commercial premises. In our talk we described how these types of devices are susceptible to capture and replay attacks against the rolling code and how this can be used to disable an intruder alarm system to gain physical access to a property. The demonstration for this portion of our talk is below:

The final device covered in our research is the Motorola Scout 85 Connect, an IP camera rebranded for a number of different purposes. This device is built on top of BusyBox and embedded Linux 2.6.32 on an ARMv5 chip. While our research was mainly focused on version 17 of the firmware, the majority of the issues we identified affected the latest version at the time and have since been responsibility disclosed to the vendor.

One of the most immediately obvious issues when reviewing this device was the absence of any authentication on the web administration interface. The functionality available over this interface ranged from fairly benign actions such as physically rotating the device’s camera, to more serious actions like upgrading the device’s firmware. Further to this, we found that the service listening on TCP port 51108 was connected to the device’s audio out, which would accept a 16-bit, mono WAV file without authentication. A demonstration of how this could be abused for humorous consequences is shown below:

The code to exploit this issue can be found on the MDSec github.

While having the device sing and dance was humorous for comedy effect, it could not be used to compromise the device so we moved on to locating more serious issues. Having obtained a copy of the firmware, we quickly moved on to reviewing the other exposed scripts within the web root. One script in particular stood out as being susceptible to a relatively trivial command injection vulnerability, the haserlupgrade.cgi script:

cmdinjection

As is shown above, the script directly populates the contents of the uploadfile_name parameter in to an operating system command and can be abused to execute commands on the device as root. This is demonstrated in the following video:

Having found one command injection vulnerability in the device we set out to gain a better platform for debugging and reverse engineering by performing a hardware assessment in the hope of identifying a debug console. An assessment of the board revealed the device was built using a Novoton N32926U1DN system on chip with an ARM926EJ-S CPU. A review of the development board’s documentation revealed that test points 104 and 105 were of interest as they were listed as UART connectors:

nuvoton

Soldering to these test points and connecting with the JTAGulator provided an interactive root command shell for reviewing the device further:

uart2

With the hope of finding further vulnerabilities, our attention turned to the process used for launching all services on the device, the msloader service. Having previously found a command injection issue we were confident more would exist, and we began to reverse engineer the msloader binary. The first and most promising issue we found existed in the setupWifi() function which appeared to accept a user supplied SSID parameter and concatenate it in to a buffer that was eventually passed to system():

setupwifi

Aside from the obvious command injection vulnerability, the eagle eyed reader will have also noticed that the parameter appears to be concatenated without any prior bounds checking, leading to a stack based buffer overflow. To trigger this vulnerability, we were able to craft a HTTP request similar to the following:

GET /?action=command&command=setup_wireless_save&setup=1002001800100000000000YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYZZZZA HTTP/1.1

When testing this service, it’s important to ensure the corresponding length fields match the length of the SSID and its password as highlighted above. Monitoring the UART console whilst sending the above request will trigger an exception similar to the following:

crash

Exploitation of the vulnerability is relatively trivial due to the absence of any exploit mitigation features in the msloader binary:

checksec

Furthermore, the stack and heap were both observed to be executable meaning that we could simply jump to our shellcode having taken control of the program counter.

When exploiting the vulnerability, we found that we took control of the PC register after 176 bytes, however the payload has a size limitation of 180 bytes meaning that the size of the shellcode is restricted. To counteract this, we wrote our shellcode in thumb mode to make best use of the space. We also found that the overflow corrupted many of the other registers to the point that we were not able to identify a register pointing to our shellcode to jump to, or a reliable method of locating it. This corruption included the stack pointer which required adjusting to allow the shellcode to push parameters to the stack during configuration of the system call. As such we opted to jump to a hardcoded address of where our shellcode resided on the stack which while not being ideal for reliability proved to be the least complex way of exploiting the issue.

While in theory exploitation of the issue should have been relatively trivial, there were several other considerations to bear in mind. Firstly, system wide ASLR was enabled on the device, this was however set to conservative mode meaning that the stack is poorly randomized and susceptible to bruteforce. In practice we found that this took no more than 20 attempts and in many cases as few as 5. Crucially, the software watchdog plays an important role in facilitating this as every invalid attempt causes the msloader process to crash at which point the watchdog detects the stability and reboots the device ready for another try. Secondly, the payload needed to be “URL safe” as it was passed within a GET request. As such we needed to construct out payload so that it did not contain characters that would make it an invalid HTTP request; we circumvented this restriction using URL encoding. In addition to this the payload could not contain null bytes else the string would have been terminated early. To handle this restriction, we simply constructed our shellcode so that it was self-modifying, patching the null bytes in relevant locations within our buffer on first execution. Finally, the payload was observed to be corrupted in a number of locations; rather than jump over these which would require additional instructions, we opted to adjust our payload so that the corruption converted the instructions to something that would not impact our shellcode.

The demonstration of how we exploited this issue is shown below, whilst the proof of concept exploit can be found on the MDSec github.

In conclusion, we have demonstrated how the security of IoT is much less mature than that of desktop and mobile environments. In many cases devices are configured with default credentials, missing basic exploit mitigation features, run all services as root and are often plagued with low hanging fruit such as command injection vulnerabilities. The analysis of the Mirai botnet has brought to light how prevalent these devices are and how they are fast becoming a soft target for exploitation by cyber criminals and we predict that this is likely to grow in the future.

The slides to this presentation can be found here, whilst the presentation can be watched in full below:

 

Ready to start testing your applications?

Speak to one of our industry experts and find out how MDSec can help your business.

+44 (0) 1625 263 503

contact@mdsec.co.uk