Imagine a sex toy talking with an application on the phone, adjusting mechanical parameters in accordance with the personal profile stored, or based on FB Likes, or using a playlist of mechanical movements, controlled sounds, lights, and smells, or even a json stream of parameters from a remote controlled application (by another sex toy?) on another continent and you want to test it!

This and other fun objects are called the Internet of Things (IoT). These devices with applications connected to networks, especially the Internet, are often not considered to be computers because of their shape – but they are. Recently it has been popular to test/hack these devices, resulting in the discovery of many nasty vulnerabilities. The OWASP project has suggested an IoT Top Ten, as they have done before for web and mobile applications, to give testers a framework to test in. This article proposes ideas as an extension to the Penetration Testing Execution Standard (PTES) when testing IoT devices.

The reason we look into extending PTES for IoT devices is, that when we test on a regular basis, we usually have one or two technologies and we can define the scope very easily. By contrast IoT devices are not a single technology and not a family reunion of technologies but rather a big collection of different technologies and components. Most devices will have a management interface that could be controlled through a web application, a mobile application or something else. It usually has some kind of network, sometimes wired, sometimes wireless. Only look at those two big topics – we haven’t even touched the actual application.

This article will follow roughly the high level organization of PTES.

Pre-Engagement

The definition of an engagement’s scope is critical to using your time efficiently and not destroying customer relationships. Any input and every output is something worth considering. So when you define the scope of an IoT device additionally think of:

1. Management Interface
2. Firmware
3. Related mobile and web applications
4. Physical device itself

Are all of those in scope? These aspects will be part of the basis of threat modeling.

Intelligence Gathering

Intelligence gathering is the foundation of every test. Depending on which level of information gathering, social engineering of the producing and developing companies, it might be worth it. Ask yourself:

1. What research has already been conducted that affects this device?
2. Are there similar devices from the same company?
3. Are there any white papers on the device itself, or any of the technologies it uses?
4. Is there any information on the device (e.g. sticker) or on the chips, if you can open them up.

Threat Modeling

You will need threat modeling. Since we have so many vectors you will have to have threat models for each one of them, and the impact of the findings on each of those is different. Be aware that the following threat model might not be that interesting: “Needs physical access and something you soldered onto the device once you opened it, including removing special screws and maybe heating up the glue so you got access to a seriel interface.”

Also, don’t assume a toaster is safe, because nothing interesting is on it. It’s got a CPU. Sometimes that is all that is wanted.

Vulnerability Analysis

This chapter needs awareness, that to do vulnerability analysis, you might need the dumped firmware. Think of the entry points the device gives you:

1. Physical Access (especially, but not limited to home automation devices):
   1. Ports (USB, Ethernet, …)
   2. Debugging Interfaces (JTag, Serial, …)
   3. Buttons (On-Off, Reset, …)
2. Wireless (NFC, Bluetooth, Wi-Fi, …)

Unless it is whitebox testing, and the vendor gives you all information, you will need to do full traffic analysis.

1. What data does the device send / receive?
2. What other devices does it communicate with?
3. How can you ensure there is no out-of-band communication that you are missing?
4. Does it communicate only directly or is there a pivot host? (Check your scope!)
5. How does remote access work? (Open port, UPnP with STUN, …)
6. What are the authentication mechanisms (for administration, through WiFi, through Internet)
7. Does the device change its state? (e.g. offer a Wi-Fi and disable it, once properly set up?)

Exploitation and Post-Exploitation

Exploitation and post-exploitation of IoT devices is fundamentally the same as regular devices. The development of binary exploits is – as always – specific to the architecture of the hardware. Existing exploits for x86 or 64-bit architecture are likely not to work out-of-the-box.

Moreover the operating systems running on such devices are often trimmed, as for example BusyBox, a size-optimized Linux for embedded devices. This will need to be accounted for, when writing a post-exploitation toolchain.

Conclusion

All things considered, the PTES is very comprehensive. As we’ve shown in this article, the situation doesn’t change much when applying PTES to testing IoT devices. The biggest challenge is to keep all entry points in the back of ones mind when developing threat models.

About the Authors

Veit Hailperin has been working in information security since 2010. His research focuses on network and application layer security and the protection of privacy. He presents his findings at conferences.

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• http://securityaffairs.co/wordpress/29353/security/smart-meters-hacking.html
• http://undeadly.org/cgi?action=article&sid=20160107075227
• http://we-vibe.com/we-vibe-4-plus
• http://www.wired.com/2015/05/new-sex-toys-sync-virtual-reality-porn/
• http://www8.hp.com/h20195/V2/GetPDF.aspx/4AA5-4759ENW.pdf
• https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project#tab=OWASP_Internet_of_Things_Top_10_for_2014
• https://www.pentest-standard.org