IoT in the Wild West: A Personal Call for Consumer Vigilance and Responsible Development

I wrote this short summary in honor of Cybersecurity Month, inspired by discussions from a panel talk and my own experiences. The main topics are: what I currently see in the world of IoT security, what the main challenges are and why they are now in focus, and what could be the solution?

What are the global issues with IoT devices?

Perhaps the biggest wake-up call was the Mirai botnet attack, which initiated the changes. The compromised set-top boxes and the coordinated attacks that could shut down GitHub, Twitter, and Reddit demonstrated the biggest risk very well. If there is a vulnerability in one device, it is present and accessible in all deployed devices. This is no longer just a simple security risk.

The current war between Russia and Ukraine also highlighted this. Intelligence agencies tried to hack into IP cameras, which were weak points through which the enemy could be most easily spied on. Let's not forget that these devices are not only in our homes but also in government, military buildings, and critical infrastructure.

Regardless of the sector, most digital enterprises face risks if IoT devices are operated within their network boundaries. Device vulnerabilities can be the entry points during attacks against high-value targets. As a prime example of this, a casino made the news in 2017 that was hacked through a smart aquarium. Despite investing a lot in information security, they didn't think that the aquarium could be the weak link. Since then, more and more information security departments have realized the risks associated with IoT assets on their network and increased their spending to discover such malicious attempts and risky devices.

What makes IoT different? Why is it more challenging?

Embedded systems security is fundamentally different way compared to the applications space. Here are the key factors in my opinion.

1. Perhaps the most significant initial difference is the limited storage and resources, which impose many constraints on IoT code. Although some software projects have a relatively large market share, such as Linux and FreeRTOS, the spectrum of all IoT designs is very heterogeneous and there is usually some closed hardware-specific code involved in these that often has a detrimental effect on security.
2. Devices need to solve the entire problem on their own, often without a full-fledged operating system. Bare metal code is often susceptible to attack vectors, where simple issues such as a dereferenced null pointer end up being exploitable due to the environment lacking memory protection or other security facilities that are usually set up by the OS.
3. There's often no control over certain procured components, and associated SDKs come with vulnerable example code without any warranty. Sometimes, the vulnerable code is distributed as source code where a 3rd party audit might catch those, but it is often the case that the SDK hides these vulnerabilities in the form of custom modifications to system binaries that are pre-compiled for the platform.
4. Adding further complications is the fact that manufacturers typically seek the cheapest element that meets the requirements. As long as robust security isn't among the hard requirements, the designs will minimize costs at the expense of basic measures such as strong cryptography or privilege separation.
5. The programming languages commonly used in the domain, such as C and C++, are challenging from a secure coding perspective. Issues with memory safety are still the primary vulnerability classes that plague these designs.
6. The difficulty of security testing is the last nail in the coffin. Tools that could assist in this area are lacking, with only a few open-source projects available. This is compounded by the fact that there's a shortage of several million security professionals in the market, making it impossible to rely solely on human supervision.

We covered some of these elements from another perspective here, detailing the variety of skills needed for IoT security that make it difficult to excel.

Who bears responsibility? Operators or Manufacturers?

Of course, many problems can be mitigated through proper operations, such as firewalls, XDRs, and IoT observability platforms. However, even with these measures in place, the vulnerability of devices can remain a risk, especially if it is a targeted attack against a high-value asset within an organization. Therefore, I believe it is primarily the manufacturer's responsibility to ensure that their product meets basic security expectations.

Fortunately, the situation has improved in one significant aspect: if we discover a vulnerability in a product today and report it, it is typically not seen as a PR attack but rather as a welcomed contribution. Manufacturers are more likely to express their gratitude and collaborate with us on addressing the issue.

Why does one device type have a better security posture than another?

What I'm about to say may not be surprising: those devices had a higher level of IT security where there was a business motivation and a real potential for attacks.

A great example of this is the set-top box as a device. One might think it falls into the same category as a router, especially when considering cheaper, lower-quality devices. However, from a security perspective, I've experienced a significant difference.

The analyzed inexpensive set-top boxes had dedicated hardware resources and operated with serious encryption. This is primarily thanks to content creators entering into contracts with operators and cable TV providers that included hefty penalties in case of theft, as they wanted to protect their intellectual property. As a result, operators suddenly had a strong interest in ensuring that content reached consumers securely.

In the third world, this is especially big business, as piracy has grown into a full-fledged industry, with some malicious groups even running their own pirate satellite operations. Therefore, there was significant pressure on operators, which led to the development of more secure devices.

Similar processes have made game consoles secure as well.

In stark contrast to this, routers and IP cameras are far less secure. Based on our research, serious vulnerabilities can be found in 8 out of 10 on average. And in general, we found that the more serious and expensive devices tend to be more secure.

Regulation and Customer Awareness

Now we come to a critical issue, which is customer awareness. Simply put, it's not at a level yet where it forces manufacturers to optimize for security, as consumers do not penalize weaker devices. Of course, the question arises of how consumers could assess this, but there are more significant problems at play.

Some have not even reached the point of understanding the problem, which is the danger itself.

There was an article about BugProve after our first investment, and the title read something like, "We protect your smart fridge from attacks." One of the top comments was, "Help, what will happen to me if they hack and steal my chicken nuggets?"

This was meant to be a bit of a sarcastic joke, and I also found it funny. However, I think it also sheds some light on the question of whether the average consumer is at a psychological disadvantage when correlating privacy and security concerns with otherwise harmless household objects. One could even call this the “fishtank fallacy” as per the casino incident. For us, security experts, it is easy to immediately see privacy risks wherever we see microcontrollers and other computing hardware hooked up to IP networks even if those are hidden inside familiar objects, however, this has not been the case for the wider population.

As the earlier example with the casino illustrates, the risk doesn't depend on the compromised device's original function; the problem is that any IoT device can serve as an entry point into the customer's network, and an attacker can obtain additional resources from there. Malicious code placed in this way often remains hidden from the user but can still pose a continuous risk.

This is something the upcoming regulations aim to change. The GDPR may not have been the best way to increase data security, but it did at least make everyone aware of it to some extent. We hope that RED and CRA will have a similar effect.

Even more noticeable is the American approach with the Cyber Trust Mark. Products will bear a logo with the shield, signaling to consumers that the product has met at least a certain standard. There will also be a QR code that consumers can use later to verify whether the product still meets these standards.

I believe some consumers will pay attention to this, but there will still be those who seek the cheapest option on the shelves. This is where the need to raise the overall security level of the entire industry comes into play. Even those who go for the cheapest solution should have basic protection - this is key to protecting our society.

How does BugProve fit into all of this?

We are working to prevent vulnerabilities from entering products in the first place. It's always a risk, even if everything is set up correctly. The quality of IoT code is so far behind that of application code that it needs improvement. Period.

Of course, if a manufacturer were to hire even a junior developer whose job is to manage components and find vulnerabilities, doing this manually would be endless and inefficient. We want to assist development and security teams in making this task less burdensome and easily integrated into the optimization equation.

To address the difficulties mentioned in the first point, we aim to offer assistance with:

• Supply Chain Security: Providing visibility into the components and dependencies, identifying vulnerabilities they may carry, making their management easier, and facilitating consideration of security during procurement decisions.
• Firmware Analysis: Reverse engineering firmware, providing a map, and highlighting potential weaknesses and flaws.
• Automation: With automation, security teams can have more time for thorough product examination and error correction, making the testing phase more efficient.

I really look forward to seeing how this industry will evolve in the next few years and hope to be an active participant in beneficial changes.