Penetration testing

Getting Started with IoT Security - Mapping the attack surface

IoT or the Internet of Things is the new buzzword all around. However, not enough attention has been paid to the security aspect of these so-called "smart" devices.

This series of post will help anyone interested, get started on IoT security and penetration testing of "smart" devices.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

To assess the security of IoT devices, we must first understand the various components involved in it, and then identify what kind of security issues could affect each component and then look into each of them. That is exactly the approach we will be taking in this series of "Offensive IoT Exploitation".

The Internet of Things device infrastructure could be divided into three major categories:

1. Embedded device
2. Software and applications
3. Radio communications

Device

The "Device" component is the key to any IoT architecture. Here, the device is a combined term which I have given to refer any hardware device that is involved in the architecture.

For example, in most of the smart home appliances, the device will usually comprise of the "gateway" and the "operating device". The gateway is what acts as a central hub to the other devices, whereas the "operating device" is the device which performs the actual action or monitor using sensors, depending on what is it intended to.

The vulnerabilities in "device" will be any vulnerability which we typically see in an embedded device. For example, communication over serial ports leading to root access, and ability to extract firmware from the flash are some of the examples we will get started with. We will go in-depth into these once we cover the device section in subsequent posts.

Software and Cloud component

The Software and Cloud component in an IoT device comprise the following elements:

1. Firmware of the device
2. Web application dashboard
3. Mobile application used to control, configure and monitor the devices

There are some specific vulnerabilities in each of the components. For this post series, I will only cover the Firmware section in detail, with a bit of insight on each Web and Mobile based vulnerabilities affecting IoT products.

Radio Communication

The radio communication is a critical aspect of any IoT device. By Radio communication, we simply mean any communication is happening between device-device or app-device.

The various communication protocols which are usually used in an IoT architecture are WiFi, BLE, Zigbee, ZWave, 6LoWPAN and Cellular to name a few.

For this Offensive IoT Exploitation series, we will look at some of the major communication channels used and specific attacks against each of them. However, this section will need a good amount of hardware setup (just like the "Devices" section), so be prepared for all the fun and action.

How to map the Attack Surface of an IoT device

Having done numerous IoT pen testing engagements so far, I can assure you that to conduct an IoT device pentest effectively; you will need to assess and map the entire attack surface for that given device. Assessing an IoT device attack surface does not vary a lot from web attack surface mapping, however here a lot many more components will be involved.

Below are the steps you would need to follow to map the attack surface of an IoT device:

Step 1: The first step of Attack Surface mapping is to understand the entire IoT device architecture. This would need you to go through all the product manuals, documentations, information on the vendor's website and any additional detail which you can find from any other source.

Step 2: Build an architecture diagram for the given device specifying each of the components that is used in various categories we discussed above. If it is a radio communication between two devices, show it with a dotted line and also specify the kind of communication protocol being used. If the application is communicating with the cloud to send and receive data using an API, mark it in the architecture diagram along with the kind of API which is used.

One sample architecture diagram is shown below:

Step 3: Once the complete architecture diagram has been prepared, think like an attacker. If you have to attack a particular component, what techniques would you use and what kind of information would you try to extract. List down all the specific test cases for each component in a spreadsheet.

Below is a snippet of attack surface list for the above architecture diagram:

Once the above steps have been completed, we can now proceed to the actual execution of the attack vectors. Since we already have a clear idea of what technique we are going to use, and what data we are after, our efforts will now be much more optimised for the time and would lead to better results.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

1. IoT gateway:
   1. Hardware based attack vectors – serial communication, firmware dumping, etc. to get access to the firmware and any sensitive information stored in it.
   2. Sniffing communication data being sent to the cloud
   3. Performing replay and spoofed attacks against the communication data sent to the cloud
2. Devices:
   1. Hardware based attack vectors – serial communication, firmware dumping, etc. to get access to the firmware and any sensitive information stored in it.
   2. Radio communication analysis between device and the gateway attacking Zigbee, zWave, 6LoWPAN
   3. Attacking BLE
3. Mobile App:
4. Cloud/Web dashboard:

That is all for this post, in the next post, we will learn on how to start performing a firmware analysis for a given IoT device.