Speaking at the RSA Conference in San Francisco on how to build a comprehensive Internet of Things (IoT) security testing methodology, Rapid7 IoT research lead Deral Heiland said that it is currently hard to determine what IoT is, so he built a testing model to determine the traits of IoT so they can be better detected and secured.
He said that he often asks companies if they have got any IoT technology, so created a methodology to define the traits of IoT, which is based on four key areas:
- Management control—to control and manipulate data
- Cloud service APIs and storage
- Capability to be moved to the cloud
- Embedded technology
He said that you have the ability to better defend your ecosystem if you know the traits of IoT, and can build a methodology to build and test IoT:
- Functionality
- Reconnaissance
- Testing
- Analysis
This is about finding information and gathering knowledge, as “there is no way to test your IoT ecosystem if you don’t know how it works.”
Heiland said that once you have done a functional evaluation, you can do a larger reconnaissance to look at what is going on, use open source intelligence to see what frequency the communication is running at and what components it was running, and if they had any notable vulnerabilities and exploits in the past.
The next stage is testing, including web-based penetration tests, scans, and more manual tests of the build, including looking at physical ports. Looking at the firmware, Heiland recommended analysis testing to look for hardcoded keys, passwords, undocumented command structures, IP addresses, and hardcoded URLs of interest. He also recommended doing radio frequency (RF) testing, as most IoT “have some form of this.” This can also determine if the communications are encrypted and effective, and find RF protocols. He also recommended looking at pairing and over-the-air updates.
Heiland admitted that one test does not work for all IoT, and elements will need to be changed for different products, as “you find new things every time and new ways of doing things.”
In one case study, he presented an analysis of a smart door lock. The idea of it is to provide short-term access via email, so he set up a Man in the Middle attack using Burpsuite to create a certificate, “as the mobile app didn’t have SSL, so it was simple to create a certificate and gain Man in the Middle access and see communications flowing back and forth.”
He said that he was able to see the communications, such as how the API returned control keys to all users, which was written to the developer debug log and available via a file on the phone. “We didn’t need to root the device as all of the data was in there, this had a session token so in theory you could control the lock forever.”
He explained that this issue has now been patched, and he declined to reveal the vendor name.
In terms of who can do this sort of testing, he said he would expect a person to be a “seasoned tester at a bare minimum” as well as have hardware skills, budget for kit, and “an endless desire to learn.”
Heiland said there are three elements needed in order to get to a better stage of IoT security. These were for manufacturers to implement a product security testing program and test before a product goes to market and for those that are available, bring them back in-house and test them.
Also, enterprise consumers should ask questions of the vendor, inventory their IoT, define what IoT is to their organization, and assign ownership.
The final element is for IoT researchers and testers to follow Heiland’s methodology and improve their own skills sets.