Adopt embedded penetration testing to keep IoT devices secure

With growing adoption of IoT and connected devices, organizations need to focus on their embedded systems security.

While many organizations conduct regular application and network penetration testing, they often forget to evaluate connected devices for vulnerabilities. Embedded pen testing analyzes connected devices, including IoT products, for potential weaknesses.

To help security teams and interested individuals conduct proper embedded pen testing, Jean-Georges Valle wrote Practical Hardware Pentesting. During Valle's career, he has worked in embedded pen testing, security architecture and risk management. He currently serves as senior vice president at Kroll, a cyber risk and financial services consultancy.

The book, currently in its second edition, teaches readers how to conduct offensive techniques to test embedded devices for vulnerabilities and weaknesses.

While the goal is the same as software pen testing, it's a different experience for the tester. "It's a practical activity," Valle said. "You're physically interacting with the devices: You're soldering, opening up parts and reverse-engineering a physical device."

In an interview, Valle discussed the challenges in embedded systems security, embedded pen testing and how he conducts a pen test.

Click here to learn more about
Practical Hardware Pentesting.

Learn more about Practical Hardware Pentesting

Check out an excerpt from Chapter 10 that explains how to conduct dynamic reverse engineering during embedded pen testing.

Editor's note: The following interview has been edited for clarity and length.

What's the biggest weakness when it comes to embedded systems security that organizations need to better account for?

Jean-Georges Valle: The biggest weakness is that embedded systems never exist on their own. They always interact with something on the back end and with other services somewhere in the cloud. The problem from there is that these embedded systems and devices are generally considered as fully trusted and not an attack vector.

This mindset is not at all true, I've found and I'm sorry to say. Attackers can leverage embedded devices and systems as an attack pathway into an organization's IT infrastructure and go from there. Due to this faulty idea of trust regarding embedded devices, the usual principles of least privilege, hardening, segmentation, etc. get forgotten. Organizations may overlook embedded devices and their potential vulnerabilities. This opens them up to common attack vectors, such as command injection, or results in embedded devices having access to secrets, such as API keys, that attackers can then use to dig deeper into an IT infrastructure.

Have you noticed recent recognition from organizations around improving security for IoT and similar devices?

Valle: A little, but this is largely due to the European Union cracking down on embedded systems security. The EU introduced legal constraints towards these types of devices in a 2022 proposal for the Cyber Resilience Act. The act establishes security baselines that connected devices must comply with or they don't get the CE marking, which effectively means you cannot sell in the Europe Economic Area. Due to a lack of industry incentive to harden embedded devices, regulators had to step in and start cracking down.

Too often, vendors treat digital products differently than most other industries and refuse to accept any liability following security incidents. For example, if you go to the store and buy an apple pie and get poisoned, the manufacturer of that food item is liable. This isn't really how it has worked for digital products, but that's changing from a regulatory perspective, which is a good thing. Now, if a manufacturer sells a vulnerable digital product, they can be held liable. This makes manufacturers rethink their products and focus less on providing cheap and insecure connected devices.

Is the goal of embedded pen testing the same as classic network or application pen testing?

Valle: Yes. It's commonplace to find and let manufacturers know about the problems with their devices and help them manage their own risks. In the end, it's all the same goal for helping with risk management, whether you're pen testing a car, industrial PLC [programmable logic controller], an IoT product or a website. Just because IoT devices aren't obviously a computer at first glance because they aren't a box with blinking LEDs doesn't mean they don't need testing to help a manufacturer or organization take ownership of their risks. They still want to know about the risks they're exposed to.

Do you feel organizations today consider embedded pen testing, or is it often forgotten?

Valle: Thankfully, it is becoming less and less of an afterthought, especially for companies that are mature in their security lifecycle management. They realize they are at risk from IoT devices and that regulations are coming, especially in the EU. Other countries will follow in time, requiring manufacturers, especially, to ensure their connected devices aren't security risks.

Historically, embedded systems were produced with the goal of cost reduction, and risk management wasn't given much thought. Manufacturers were more worried about competing against constantly falling prices and didn't look at their products through the prism of security and risk management for a very long time. Security would come third, fourth or fifth in their list of priorities, but their mentality is starting to change. But it's not an on/off switch, so it takes time to change their mindset.

What is the most difficult aspect of embedded pen testing?

Valle: Every product and device you approach is a snowflake; they're all different. To me, this is both the most difficult aspect, as well as the most rewarding part. When you look at network and application pen testing, you have a lot more common software and shared technology that you'll be testing and examining. For example, 90% of the enterprise environments you pen test will have a Windows OS and use applications such as Active Directory and VMware [desktop hypervisor].

This isn't necessarily true for embedded systems. You have a lot of different IoT vendors, and they all use different physical components for their devices to create their specialized devices and systems. This makes things difficult for pen testers because they have to go through varied hardware ecosystems and different IoT OSes and custom-built software.

Embedded penetration testers need a specific mindset to be successful. They need to be curious about the devices they come across and be prepared to learn and read through a lot of documentation.

That's what I like about embedded pen testing because you never get bored and experience the same testing process as you might for software pen testing. You really need to have that hacker spirit and not expect to just check boxes on a list when going through a pen test.

What are some common steps to take when conducting embedded pen testing?

Valle: Every embedded penetration testing experience is different. I do have a typical approach I can explain, however. I usually begin by opening the device up and try to identify all the different components it uses and their functionality. I'll figure out where data gets stored on the device and determine what code gets used to make everything function. From there, I'll usually start to reverse-engineer the whole device and try to link digital functionalities of the device to each hardware component.

Embedded penetration testing requires a healthy dose of experience to really figure out connected devices and tease out those vulnerabilities and weaknesses. There are common attack vectors that pen testers will learn to target over time -- low-hanging fruit they can attack for quick wins. In IoT devices, this will include examining the debug ports, seeing what the serial interfaces are exposing and looking over the chips used in the device. From there, pen testers can poke and prod the storage chips.

At the end of the day, embedded devices are still computers, and they have the same basic functionalities, such as storage, memory and communication lines. The components may be more specialized, but the device is still a computer.

What should an organization do after an embedded pen test?

Valle: Prioritize addressing the vulnerabilities and weaknesses discovered through the penetration test. Organizations usually have a limited budget for addressing security issues; it's wise to focus on vulnerabilities that are very exposed and very easy to solve. Organizations have remediation costs to address and need to figure out the risk management strategy that works best for them. Really, it's the same process that any organization will go through following any other pen test -- it's all about risk management.