How Cloud Security Influences IoT Security

I keep on finding security issues at IoT vendors cloud services, and that saddens me. That is why I joined Xebia to learn more about cloud security and help IoT vendors to fix security issues with their cloud infrastructure. The default security of our IoT devices are improving. The cloud services behind the devices are not. These cloud services are used to control the devices and collect all data, so securing this is very valuable. So, let’s talk more about what are the issues that cloud systems that handle IoT devices face and what are the potential solutions to them.

When I started hacking embedded and IoT devices, my focus was on identifying issues with the device itself. These ranged from open debug ports to command injection vulnerabilities on the web interface of the device. Most of the vulnerabilities I had identified earlier were those that could only be attacked locally or within the same network. As device vendors learned more about securing devices, they were able to patch or mitigate these low hanging fruits on the devices.  However, the same level of security improvements have not been done on the backend systems monitoring and maintaining these devices.

A typical IoT device network.

Image credit for router and backend icon: onlinewebfonts.com

As I gained more experience, I began to look for issues that could be exploited remotely and at scale. This usually meant that I was looking at the cloud based backend for managing multiple IoT devices. From a usability perspective this was incredible for developers and maintainers. No more reliance on manual updates for devices. You can configure and even manage devices from a central point. From a security point, however this was also a goldmine for attackers. Instead of compromising devices individually, they can compromise the central monitoring and management system to compromise all the managed devices through it. Like application security earlier, I see IoT developers make the same mistakes in the cloud and backend security that have known solutions. 

A brief history of connected devices 

When devices began to be connected to the Internet early on, it was usually direct connections to the Internet without much connectivity to a central service owned by the manufacturer. If there were any updates, these were offered on the manufacturer websites and the users would have to download it from there and install it manually on the device. This was not an easy task for users without the technical know-how. Additionally, this did not allow manufacturers to have visibility into how the device was operating and gain useful telemetry data. 

Later on, to mitigate users who would or could not update their systems manually, manufacturers began to use automated update mechanisms that would only require the user to click on the update button. For this, they required a central server where the update (binary) would be stored and even allow for some basic usage data (telemetry) to be sent. This server was maintained and patched by the manufacturer and would usually be physically located at a data center. 

Due to this usually being a server set up by developers who were primarily focused on embedded devices, there were quite a few misconfigurations and vulnerabilities. We discuss some of these vulnerabilities later. There are still a few device vendors who use this approach to store configuration and firmware for devices. However, a significant number of developers started moving towards cloud hosted services for their backend services. At the time of transition, there were not many cloud vendors who provided dedicated IoT connectivity solutions. This meant that most manufacturers opted for running a cloud virtual machine instance and then use this for their backend. Once again, configuration and maintenance would be done by the manufacturers or in some cases, contracted parties. The vulnerabilities that were present when they were self hosted, would still rear their heads here. 

In the last few years, there’s been multiple cloud service providers who provide dedicated IoT services. While there has been adoption from the IoT industry for these services, not everyone uses them. Cloud providers are well equipped to identify threats and respond to them better than the manufacturers due to cloud and network security being something they had to work on securing over the years. Let’s discuss some of the available services later in the next post. 

Threat model 

What are the threats that may arise from having an Internet connected device? What are the assets that are in play when you consider the scope of a cloud based backend for IoT devices? Who are the attackers that you would need to defend against? 

These are all questions that concern both the cloud provider and the manufacturer of the device. The best way to answer this is to through a threatmodelling exercise. Don’t know how to do that? Here’s a good blog post: https://xebia.com/blog/threat-modeling-start-using-evil-personas/.

Would you like some more help? We conduct workshops regularly on this topic. Reach out to us and we can plan something specifically for you! 

Assets

Firmware image – An attacker having access to an unencrypted image can reverse engineer the image to identify vulnerabilities. 

Code execution on the device – Being able to execute code across devices would allow attackers to get access to other assets on the device or run cryptominers. 

Telematics from the devices – Information about the device operation can be used for industrial espionage 

Ability to configure the device – A misconfigured device might be a dangerous device, especially in areas such as industrial IoT. 

User data/Personally Identifiable Information – The user of a device might have personal information stored on the device that the attacker can access. 

Company confidential information – The backend or the device might contain information that the company wants to keep confidential. For example, an upcoming product that they are not ready to talk publicly yet. 

Availability – Having the service being accessible is quite important for customer satisfaction and security updates. 

Threat agent

Malicious device user – The end user of a device might be malicious. They might want to bypass security on the device or the backend to gain free access to services. 

Skilled external attacker – An attacker who is skilled but does not have any access to the resources when they begin the attack.  

Rogue employee – An internal employee who is misusing the access they have to modify or destroy assets. 

Rogue IoT manufacturer – An IoT manufacturer who wants to use the access that’s provided to gain access to/modify other client’s data, get free access to services or misuse services that are provided. 

Threats 

Information disclosure about customers – Since customer data passes through the server, it can be intercepted and stolen by attackers. 

Denial of service – An attacker can bring down the service and limit access to it from the device side. 

Leak of firmware data – Firmware data can be leaked from the service which could lead to reverse engineering and identification of vulnerabilities 

Modification of firmware data – An attacker could modify the update coming from the backend service to backdoor firmware on the device. 

Arbitrary code execution on the device – An attacker could use a combination of vulnerabilities on the device and backend to execute code on the device. 

Security challenges

The security challenges associated with a cloud-based backend for such devices can be described in a few questions: 

1. How does authentication work? 

Ideally each device would have a unique credentials. Some devices use an X.509 certificate to authenticate while others have derived credentials based on unique device characteristics such as MAC addresses. When using non certificate authentication, it’s important that the credentials cannot be guessed by the attacker. 

2. Is anonymous access enabled? 

Can a non-authenticated user access information on the service? This usually happens due to misconfiguration of the services such as MQTT brokers or an incorrectly designed API. Try to avoid anonymous access to the service if possible. 

3. Can one device access the data for another? 

When authentication is done correctly, what sort of access does a device’s credentials provide? There’s been situations where one device could see the data of all other devices using the backend services. Limit accesses on a device basis. 

4. How is data stored on the service? 

Is the data purged on account deletion? Can a user buy old devices and recover historical data from the backend services? This could have implications on user data privacy and GDPR. 

5. Is backend service access monitored? 

Is the system designed to identify malicious access and respond accordingly? Can it determine the difference between a device retrying an API access due to lost connectivity and an attacker performing a bruteforce attack? Once again, lessons learned from the early days of cloud security can be applied here. Use of Web Application Firewalls and monitoring systems is still valid for these systems irrespective of the intended use of the API. 

6. Is there an incident response process in place?  

Is it tested? What happens when an alert is triggered? Is there a dedicated monitoring team in place? Can you isolate an incident and identify the culprit device? 

Conclusion

In short, it’s seen that backend security for such devices is not a trivial matter. There are lessons that can be learned from application and cloud security. At the same time, there are some IoT specific challenges that need to be resolved. In the next part of the blog post, we will look at some offerings from major cloud vendors in this space and compare the security features from them.