Threat modelling and IoT hubs

IoT hubs are increasingly being used to provide a single point of access to the myriad of smart devices in the home. One ring to rule them all, if rather than multiple apps for different devices.

When reviewing devices we often start with the single biggest security threat: unauthorised access to the device over the internet. That might come from the API, perhaps from an IDOR that allows an authenticated user to obtain other customer information, device status and in some cases full access over other devices

Then there is the mantra of Break Once, Run Everywhere or “BORE”. This normally involves finding credentials or a vulnerability within a single device, which can then be replicated to impact all devices.

However, these aren’t the only things to consider or the only threats to mitigate against.

I recently looked at a VeraEdge IoT hub. This device allows all of your smart lights, lightswitches, plug sockets etc to be connected to this hub and accessible via a single app. Effectively a one-stop show to monitor and administer all of your IOT .

There are other products which fill a similar role, including Samsung SmartThings, Wink Hub and the Staples Connect by D-link.

While this is a good idea, it does mean that all of the information and access to your entire smart home is through one device, so it really needs to be secure as possible to keep you and your home safe!

The VeraEdge provides either local or remote access. The remote access works via the website or a mobile app and provides access to your hub via their secure relay. Time and effort had been put into this, with effective user segregation and device separation, what this means is that I could remotely monitor my IoT hub, but was unable to access any others, which is great!

However, it appears that this was the only threat that was considered and with the rise of everyday IoT products and smart devices being incorporated into our lives, local attacks are becoming more viable allowing attackers with bigger attack surfaces.

Supply Chain Attack

This product has the potential to be fully compromised via a Supply Chain Attack. All the details to compromise the device are printed on the device! Whilst this is a similar issue to a Wi-Fi router from an ISP, in that the credentials are printed on the device, what’s different is that in certain circumstances these hubs can be compromised remotely and locally if those credentials are known.

It’s possible to connect locally into the device via an IP address which is created using the MAC address. Taking the last 4 digits of the MAC address, converting any letters to their numerical position in the alphabet (e.g A = 1, B = 2 and so on) provides the .

The MAC address is printed onto a label on the back of each device.

The last four characters of the mac address are “D1A6” so using the code this creates “41.16” with D being the 4^th letter in the alphabet and A being the first.

The first two octets are always consistent, which provides an IP address of 192.168.41.16.

A quick scan of the device showed that SSH (on port 22) was open, so if there are credentials available I can gain access.

Looking at the documentation for the hub, it becomes apparent quickly that root access to the device isn’t difficult to achieve.  Their own wiki has a walkthrough:

These two pieces of information, both printed onto the device, provide full root access to the device.

Adding malicious code or a regular cron-job to the device would not different for a determined supply-chain attacker.

Disgruntled Employee or Vendor Breach

Established SSH Session

There is an exploit chain which could allow a disgruntled Vera employee to take control of your device and have root access to a device within your network. This attack method would heavily depend on the access controls within the organisation and how much access is provided to different levels of employees within the organisation.

When looking at the VeraEdge we found something rather unexpected. The device has an established connection to an external host:

Investigating what was running on that host at that port, I found that it’s a SSH server.

This means that there is a permanent backdoor in the device, connecting via SSH to an external host. Not only that, but it is using outdated and insecure key exchange methods, so it isn’t even a secure backdoor into the device.

Looking further into the process, it is running a constant port forward of the administration webpage for the device.

root      3459  0.0  0.4   1240   576 ?        S    Apr19   0:00 ssh -p 232 -T -y -i /etc/cmh-ra/keys/cmh-ra-key.priv -R 26766:127.0.0.1:80 [email protected]

After a bit more research I found that this was how the secure remote access via the website or phone app worked. One connected in via the relay31.mios.com, however if security controls for the relay host failed, a malicious insider could use this tunnel to access devices in users homes!

Remote Assistance

Within the webapplication there is an option to turn on Remote Access for tech support. It should be noted that this is turned off by default within the device, however when this is enabled, the webGUI provides some new information:

This information lists the server that it’s connected too (45116000) with the SSH port (25462) and the second half of the string of digits (612000) is the password for the user remote. Looking back at the device, we can see that there is a new established SSH session:

This is again an SSH connection, however this time provides a few more services than just the webserver over the tunnel.

root      9435  0.0  0.4   1212   548 ?        S    04:37   0:01 ssh -y -T -p 232 -i /etc/cmh/ra_key -R 25462:127.0.0.1:22 -R 25726:127.0.0.1:80 -R 25074:127.0.0.1:23 [email protected]

This time the tunnel provides an SSH session on port 22, an unencrypted telnet session on port 23 and access to the webserver.

When connecting in via SSH as the user remote. The user is immediately dropped into a root shell, as it is part of the “root” group, resulting in immediate full access over the device in your network.

Local Network Attack

Assuming that the device hasn’t been set to restrict local access, the web application is available to anyone on the same network, without any authentication being required for access.

The easiest method to gain full control of the device would be to enable the remote assistance as shown previously, as the password is then printed on the webGUI. It would be possible to directly SSH in as the remote user with that password which provides a root shell.

However, if you didn’t want to actively make changes to the device, another task that can be done without authentication is to create a backup. This is assuming you can’t find the box and read the Wi-Fi password off it, or the owner has changed the default root password

Being able to Create Backup might provide some interesting things.

The backup creates a .tgz which can be extracted and provides us with the /etc/ folder.

Looking through the backed up data, there are a couple of interesting configuration files:

Within the wireless config, there is the WiFi Key (also the root password) in plain text.

This same information could also be found by doing a grep for password on the backup as it’s within the main cmh.conf file

This folder also includes both the passwd and shadow folders, so even if the owner had changed the root password to the device, it would be possible to view and crack the hash.

If it isn’t possible to crack the password, the web application allows user created scripts to be run. These can be executed from the web application and run with root privileges. This script could therefore do anything, including changing the root password, turning off the device or creating another persistent backdoor, which is what I decided to do.

These methods have now provided anyone plugged into your network fully access to the device. It wouldn’t be difficult to use this as a monitoring tool or provide persistent access from outside of your network.

Disclosure

All of my findings were inferred from the device documentation, so they appear to be intended functionality.

Conclusion

When thinking of threat models for devices, the one that people focus on is quite rightly the most critical if done incorrectly: allowing remote control of devices can be devastating for the product and all the users. We have seen this issue on smart devices many times.

However, it is always worth considering other threat models in addition to this. There shouldn’t be easy ways for the supply chain to access the device, or unauthorised users to gain control of the device.

All web applications should be password protected; the device should follow the principle of least privilege and there shouldn’t be persistent backdoors as default!

While researching the product, we became aware of a number of CVEs attributed to the device, with seven of these vulnerabilities having a CVE rating of 9 and above. We feel that these scores are rather high as none of these allow full remote (i.e. no local network) compromise.