Creating and designing secure IoT devices is a mission of high complexity. IoT devices often contain many functionalities that require using third-party software components within the device. In this article we will review the hidden risks in third-party components – as these components are highly critical in IoT devices, and affect device security greatly.
What are third-party components used for?
Third-party software components are essential part of every IoT device. There’s no IoT device without third-party components. Common third-party components are:
- Communication libraries (Bluetooth, Wi-Fi)
- Encryption libraries (i.e., wolfcrypt)
- Operating System
- Open source tools
- Different communication protocols (zigbee, mqtt)
- Chip/module manufacturer components – the software within the communication modules, i.e. Broadcom, Qualcomm, Sierra etc.
Many more exist.
In fact, it’s highly unlikely to find an IoT device that does not rely on third-party code for one or more of the mentioned components. Awareness to this fact is crucial when trying to secure IoT devices end-to-end.
Why do third-party components matter?
Imagine you have built a well-secured IoT device: encryption & authentication are in place, an over-the-air (OTA) update mechanism is set up and prepared for the next update, you have even used static analysis to make sure your code is of good quality and topped it all with some penetration testing before launching. Now imagine that despite all your efforts, the Bluetooth library has a vulnerability in it. The vulnerability might even exist in the device’s operating system or – as crazy as it sounds – within the encryption library itself. In such cases, your device is completely exposed to cyber-attacks, regardless of the best practices that have been used.
On one hand, vulnerability in third-party component is very dangerous. In many IoT devices, there is no separation and segmentation between processes and/or tasks, which means that a vulnerability in one third-party library leads to compromising the entire device. When no user-kernel architecture exists, this could lead to lethal results. Even if such architecture does exist, attackers can still leverage the third-party vulnerability, take control over the device and cause damage.
On the other hand, securing third-party components is extremely difficult. Many third-party components are delivered in binary form, with no source code available. When source code is available, it’s often hard to dive into it and asses the security level or vulnerabilities inside, and most developers use the open source components as black-boxes.
Existing security tools are not enough
Common security tools lack an effective solution for the protection of third-party components:
- Static analysis tools don’t work on compiled C/C++ code, which is common in those third-party components that are used in embedded devices.
- Penetration testing will usually focus on first-party code issues and high-level security issues and won’t reverse engineer or research third-party components for vulnerabilities or issues within them.
- Network security solutions cannot secure the device itself, no matter what part of its code is vulnerable to an attack.
- Built-in security, such as compiler flags (stack protection, CFI), works only on source code, and does not apply to closed-source third-party libraries.
These gaps lead to a scenario in which even the most highly-secured devices may be exposed to cyber-attacks.
Attackers have already figured this out
Third-party components are an attacker’s “sweet-spot”. Instead of targeting specific devices, attackers can research common third-party component in IoT devices for vulnerabilities. Once succeeded, they can now attack different devices across vendors, using the same vulnerability discovered within the third-party components. This enables them to spread high scale attacks with little efforts and without targeting or putting their hands on a specific device. As you can imagine, such scalability makes finding third-party vulnerabilities highly desirable for attackers.
It applies for vulnerabilities in operating systems as well – Linux being one of the most desired platforms to attack. Many attackers focus on finding vulnerabilities in operating systems, as they can enable exploiting a wide range of devices, from mobile devices to IoT devices. Replicating the same tactic, with only minor modifications.
The importance of keeping your device up to date
If you are a security-aware developer, you are probably familiar with the importance of keeping your device up to date. Using multiple third-party components could make this mission rather difficult. To keep your devices safe, you should be monitoring two main things:
- New version releases for each of your components, in order to update them as quickly as possible.
- New security issues (CVEs) to make sure your components aren’t exposed to hacking.
This is a highly demanding mission. New component versions and CVEs are hard to constantly track. In worse cases, third-party components could be obsolete, with support or updates not being available, leaving your device more exposed.
Keeping your device up to date is extremely important. WannaCry is just one example of that importance: organizations that have patched the vulnerability on time did not suffer from the consequences of the attack.
Summary
Using third-party components in IoT devices is inevitable. Be it communication libraries and protocols, encryption libraries, chip manufacturer components and operating systems – major device functionalities are not developed directly by the manufacturer. As a result, they require extra caution when it comes to security.
The risk of vulnerabilities in third-party components is not easy to mitigate. At Sternum, we believe that in order to create secure IoT devices, all parts of the device must be protected. Handling third-party security is a must. We advise not to rely on the built-in security within third-party components, and to take extra caution. Remember that even if third-party components are up to date, they are not necessarily free of vulnerabilities.
