Embedded Devices

An embedded device is the key to any IoT device architecture and is also the “thing” in the Internet of Things. The embedded device in an IoT product can be used for several different purposes depending on the user case scenario. It could be used as a hub for the entire IoT architecture of the device, it could serve as the sensor that collects data from its physical surroundings, or it could be used as a way of displaying the data or performing the action intended by the user. Thus, the things in Internet of Things could be used to collect, monitor, and analyze data, and perform actions.

To clarify this with a real-world example, think of a smart home IoT product. There are many devices that together make the smart home IoT product. These include a smart gateway or the hub, smart lightbulbs, motion sensors, smart switches, and additional connected devices.

Even though the devices serve different purposes, for the most part, the approach to test these devices for security issues would be the same. Depending on what purpose the device serves, it will hold sensitive information that when compromised would be considered critical.

To assess the security of the device, the thinking process should be based on these questions: What are the device’s functionalities? What information does have the device has access to? Based on these two factors, we can realistically estimate the potential security issues and their impact.

Once we go deep into hardware exploitation, in Chapter 3, we will understand more underlying flaws in common IoT devices and look at how we can exploit the various hardware security vulnerabilities that we find in IoT devices.

Firmware, Software, and Applications

After hardware exploitation, the next component that we look at is the software part of an IoT device, which includes everything from the firmware that runs on the device, the mobile applications that are used to control the device, to the cloud components connected to the device, and so on.

These are also the components where you can apply the traditional pentesting experience to the IoT ecosystem. This would also involve topics such as reverse engineering of binaries of different architecture including Advanced RISC Machines (ARM) and MIPS, as well as reverse engineering of mobile applications. These components can often help you uncover many secrets and find vulnerabilities. Depending on what component you are testing, you will be using different tool sets and varying techniques.

One of the other objectives during the pentesting of software-based components is looking at the various ways in which we can access the individual component we want to test. For instance, if case we want to analyze the firmware for vulnerabilities, we would need to get access to the firmware, which often is not easily accessible.

We also need to focus a lot of our efforts on the reverse engineering of the communication APIs that help us understand how the different IoT device components interact with each other, and look at what kind of communication protocols are in use.

Mobile applications, web applications, and embedded devices often communicate with the other components and back-end endpoints through different communication mechanisms such as Representational State Transfer (REST), Simple Object Access Protocol (SOAP), Message Queuing Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), and more, which we cover briefly in the upcoming chapters. Additionally, some of the components would be collecting data and sending it to a remote endpoint on a frequent basis, which could often be also treated as a privacy violation, more aptly, than a security issue. The whole focus of attack surface mapping is to ensure that you have enough information to understand the all the various aspects and functionalities of the device that will help us understand the security issues in them.

That list is just a sample of some of the vulnerabilities present in these components, which should give you an idea of the kind of vulnerabilities that affect these components.

Radio Communications

Radio communications provide a way for different devices to communicate with each other. These communication mediums and protocols are usually not considered by companies when thinking about security, and thus act as a sweet spot for penetration testers to identify vulnerabilities in the IoT devices.

Some of the common radio communication protocols used in IoT devices are cellular, Wi-Fi, BLE, ZigBee, Wave, 6LoWPAN, LoRa, and more. Depending on what communication protocol a device is using, specialized hardware could be required to perform analysis of the radio communication .

During the initial analysis process, you should also list all the different hardware and software items that are required to perform a security assessment of the radio protocols in use. Even though initially this might appear to be a onerous task, once you have acquired the tools required to perform the assessment, it’s just a matter of analyzing the communication using those tools.

Setting up software and tools for radio pentesting (and other IoT pentesting components) can be a daunting task. That is why we have built a custom virtual machine (VM) called AttifyOS that you can use for all the IoT pentesting exercises and labs covered in this book. You can download AttifyOS at https://attify.com/attifyos .

These are just some of the items you should consider when analyzing the radio communication for a given IoT device .

Creating an Attack Surface Map

Now that we are familiar with all the different components that we are going to look at, and the kinds of vulnerabilities that affect the components, we are in a good place to create an attack surface map of any given IoT device. Figure 2-2 shows the process to create an attack surface map.

The initial architecture diagram also helps us during the entire architecture of the IoT solution and the various components involved. Make sure that during the architecture diagramming process, you list all the components involved, no matter how minor they seem to be, along with all the technical specifications of that component.

For some of the information, which might be tough to obtain initially, such as the frequency on which the device operates, you can find information available online, starting with places such as fccid.io where you can enter the FCC ID of an IoT device and find plenty of information about that specific device.

Additionally, it also has a mobile application available on the Google Play Store and Apple AppStore. The next step is to draw a diagram of these components to help us visualize them better. Figure 2-3 is a sample architecture diagram I created for a sample smart home device.

As you can see from Figure 2-3, we have all the different components mentioned in the diagram along with the various communication channels and protocols the various devices use to communicate with each other or the web endpoints.

After looking at this diagram and all the technical specifications, when we start our pentest, we now know exactly how to approach these devices and what our drilled-down targets are. At this step, we need to think like an attacker. If you had to attack a component, then how would you go for it? What vulnerabilities would you look for? What test cases would you perform? Exploiting that specific component is what you should focus on.

Based on all this information, prepare a spreadsheet with all the test cases and exploits to be tested on the various components including a detailed description of what specific test are you going to perform and what the output will be if the attack is successful. The more detailed your spreadsheet is, the more effective your pentest will be. If you are working in a team, this spreadsheet is something that you should brainstorm with your team and then adjust. Figure 2-4 shows a sample spreadsheet.

Client Engagement and Initial Discussion Call

This is the initial discussion call after we get a request from an organization to pentest their IoT device. Even before this stage, we have an initial discussion with our technical team members to see if we have expertise relevant to the IoT device we are dealing with and other logistical requirements—resources available, next available dates, and so on.

During this stage, we let our pentesting lead get on a call with the client and discuss the device. These are some of the questions we discuss: What is the expected outcome required from the pentest? What components do they want to focus on the most? Would they like a normal pentest or a pentest with an additional research team involved?

If you are a pentester, I cannot overstate that your clients are your most valuable assets; it is extremely important that you deliver services and offerings only in the domain in which you and your team excel in. In that way, you will be able to serve the client best and will be able to maintain a long-lasting relationship.

Additional Technical Discussion and Briefing Call

Once we have decided that this is the project that we want to work on, and we would be able to contribute value to the overall engagement with great research, we ask the client to have their technical team join in on a discussion with our pentesting team who will work on that engagement. Remember, this stage comes after signing a nondisclosure agreement and other required documentation so that the client can freely share the technical specifications of the product.

We ask many questions during this stage to understand the product better. This enables us to understand the product best and explain to the client our pentesting methodology and what they can expect during each stage of the pentest. We also share our secure reporting mechanism, daily reporting system, test cases that we are going to perform, assessment team, interacting with their back-end mechanism, and so on. It is important that you are transparent and fair to the client on your pentesting methodology and the results they should expect each day, at the end of each phase, and at the end of the engagement.

We also need to understand their development process, what kind of testing their security team runs, if their quality assurance (QA) testing involves security tests, if there is a secure development life cycle, and so on. This also helps in getting the teams introduced to each other, as we also later offer personalized support to the developers when they are fixing the vulnerabilities.

Obviously, most of these components correspond to a gray box assessment, but you get the idea. During a black box pentest, you would omit details that an attacker won’t have, which is also called an attacker simulated exploitation. An attacker simulated exploitation is a pentesting method in which you compromise and attack the end device in a way that a highly targeted attacker would.

Attacker Simulated Exploitation

This is the actual penetration testing phase where we find vulnerabilities in IoT products and exploit them. Once we have received the devices into our labs, our pentesting process runs parallel with several activities going on at the same time:Our reverse engineering team works on the reverse engineering of various binaries, the embedded hacking team hacks into the IoT hardware device, the Software Defined Radio (SDR) team works on exploiting the radio communication, and the software pentest team works on firmware, mobile apps, web apps, and cloud-based assets.

This is only possible if you have a strong team where you have different pentesting divisions and individuals who possess expertise in their area of work. If you are an individual security researcher, you can do this as well, but for IoT pentesting, I highly recommend building a team of at least three people—software and firmware, hardware, and radio specialists—before performing penetration testing engagements.

Once the engagement is completed, we share a highly detailed report along with PoC scripts, high-quality video demonstrations, techniques used to find the vulnerabilities, steps to reproduce, remediation methods, and additional references that provide more about the identified vulnerabilities.

Remediation

Once we have completed the penetration testing engagement, we work with the developers, offering them support over voice and video calls and e-mails, pinpointing what exactly needs to be changed and what kind of patches need to be put in place. Even though all this information is provided in the technical report, we have found that working with developers during this phase and offering support helps them fix bugs more quickly and avoid making the same mistakes again because of the things they learn from our team during the remediation discussions.

Reassessment

Once the security vulnerabilities have been fixed by the developers, we perform another pentest for the vulnerabilities identified in the initial pentest. This ensures that all the patches are in place and the patches applied by the developers are secure, and do not lead to vulnerabilities in other components. This is one of the mistakes we see pentesters make: Once the device is patched, they limit the reassessment test to only the components they found to be vulnerable. However, you need to pay special attention to ensure that the fixing of code at that place has not led to the creation of bugs at another. That is how we conclude our pentest for that version of the device.

Action Point

For feedback on your creation and thought process, send me an e-mail with a picture of your diagram and any additional notes to [email protected].