How many times has it happened that you or your team is in the middle of an IoT pentest and they don’t know what to do next? You get told that they have completed the security assessment, but are you really sure that all the possible test cases have been covered?
Or what about the cases when you submit a report for an IoT pentesting engagement and then realize that you missed out on one of the extremely important test cases.
To avoid these situations, it’s extremely essential to have the correct planning from the very start. Since IoT involves so many different components – Hardware, Firmware, Binaries, Radio, Communication, Web app, Mobile app and cloud – there are chances that you will be missing out some of the vulnerabilities.
Therefore, we at Attify focus on the Ninja Recon technique – we’ll explain what it is.
Ninja Recon Technique for IoT pentesting
The initial steps are the most important aspect of any Internet of Things security assessment, and the way in which we perform these steps is what we call as the Ninja Recon technique.
If you do this correctly, you will be able to find more vulnerabilities and better vulnerabilities, in IoT devices, with spending lesser time. We at Attify often spend a few hours to a complete day during the start of a pentest to do this.
The first step is to look at the IoT device that you have as a target from an attackers perspective. If an attacker had this as a dedicated target, he wouldn’t stop at anything. Think of all the possible scenarios – everything!
How about we take the example of a Smart home solution, which has a couple of different components. It has a smart home hub, a smart plug, a motion sensor, a smart light bulb, a mobile application and a web dashboard. Let’s dig deep into this:
|**Central Hub**||Smart Home Gateway|
|**Connected devices**||Smart Home Hub|
|Smart Motion Sensor|
|Smart Light Bulb|
|Other components – WAF, Messaging queues, IoT specific web services etc.|
What are the different communications that we could think of in the above solution:
- Mobile app and smart home gateway communicates via Wi-Fi
- Smart home gateway and any of the smart devices communicate over ZigBee
- Mobile app and smart device communicates over BLE
- Mobile app and Web endpoint communicates over a REST API
- Smart devices also use MQTT to send and receive data to and from the web endpoint
There might be more communication channels and protocols in use which we will be able to identify as we go further – but don’t worry, the first step is to just list down everything that we know as of now.
Once you have everything listed down, let’s create a Threat Model for the same. You can do it either on paper, or using tools such as Microsoft Threat Research tool. An example of a possible threat model is given below:Once you have everything listed down along with the architecture and threat model diagram, now begins the actual task of researching. If you’re working in a team, brainstorm with your peers about are the various security vulnerabilities possible the components of the IoT device that you are testing. Remember, focus on breadth initially and then move to depth.
During the moving to depth stage, I want you to dig as deep as possible.
- Look at all the public available sources – Google, Community and Support forums, similar products, previous disclosed vulnerabilities in the product etc.
- Find exact specifics on - The Hardware
- Chipsets (once you open up the device)
- Firmware and its internals
- Services running on the device
- 3rd party SDKs and libraries
- Communication protocols
- Vulnerabilities in any of the components mentioned above (or anything merely interesting in nature also qualifies to be noted down)
The end goal of this step is that you should have EVERYTHING listed down. Don’t compromise in this step – as this is THE most critical foundation step for the entire IoT pentesting technique that we are going to follow. Keep pushing and keep trying harder to come up with more information. Trust me, you’ll end up writing down a lot more information than what you would have initially thought of.
Here’s an example from a snippet of my end results –Similarly, we can create one for Web application. Note that these are just the snippets to give you an idea and not the full list that we prepare. And for radio – Doing the above, helps us in the following ways:
- The entire pentesting team works together in sync
- Everyone knows what are the test cases that needs to be performed
- We keep improving our internal (massive) wiki of IoT vulnerabilities with each pentest
- We no longer miss out on vulnerabilities
- Ability to give extremely realistic timeframe estimation to clients
- Helps us during the documentation and reporting phases
Do me a favor – take an IoT device and send us an email on what you come up with. You don’t need to disclose the product name, but just the information you have come up with and we can help you get better and point further.
That is all for this blog post.
Remember, the “Ninja Recon Technique” – where you recon like a Ninja and come up with more and better vulnerabilities in lesser time.
**#1: **This post won’t amount to anything unless you take action. Set aside 20 minutes and perform this exercise. 20 minutes is not going to change your life, but if you do this, you would have learnt a skill for your lifetime which you can improve as you go further. The key is to TAKE ACTION. Don’t be someone who just keep going through blog posts after blog posts, and never actually does anything.
#2: If you want to learn more about pentesting IoT devices and the hands-on techniques which will help you find vulnerabilities, I am teaching a 5-day Bootcamp IoT Exploitation training in San Francisco. You can find more information about the training class here. Remember, there are limited seats which gets filled up very quickly.