In this week's Whiteboard Wednesday, Deral Heiland, IoT research lead at Rapid7, discusses the standard methodology he uses when engaging in IoT testing, as well as the importance of the entire IoT ecosystem.
Welcome to this week's Whiteboard Wednesday. My name is Deral Heiland. I'm the research lead for IoT here at Rapid7.
Today's topic is going to be IoT testing methodologies. When we engage on doing IoT testing, we need to have a standard methodology. The way we approach this is first thing we want to do is identify the full product's ecosystem. Often, this will include mobile, cloud, hardware, and also the network communication that involves this. Once we have identified that entire ecosystem, we want to focus on setup. The goal is to set up the product's entire ecosystem in a full functioning manner. Often, I like to set up two independent functioning environments to help facilitate this testing.
Once we've done this, and we have functionally tested the equipment to ensure it is working correctly in the way the manufacturer intended it to work, then we engage and start doing the actual work. The first thing we want to do is open intelligence gathering. Often, IoT technology will use various subsystems that may have a history of having vulnerabilities. We want to identify that information. We want to identify the structure of the IoT technology, as in communication types, how the hardware physically disassembles when we're dealing with the embedded technology, and also other communications that would be outside the normal ethernet or 802.11, different RF communication. We can often do this by engaging the FCC and using FCC ID information from the actual device.
Once we've done that, we want to go onto capturing and analyzing the data communication. What we'll do there is we will set up an environment where we can capture all the communication. We will set up proxy services between the device and the cloud, between the mobile application and the cloud, and we'll capture and analyze that data for various vulnerabilities and issues.
Moving from there, what we'll do next is we'll carry out and start doing vulnerability testing of the mobile applications. In this case, we'll do a thorough assessment, looking for improper authentication, poor storage of data, poor communication, and a number of vulnerabilities we often encounter in mobile technology.
Once that is completed, we'll move onto testing the cloud APIs. This will test for common cloud vulnerabilities, poor authentication, poor encryption. It may also include looking for things like SQL injection or cross-site scripting vulnerabilities.
After we've completed that, we move onto the last phase of the overall ecosystem. This is the hardware. Tasked to do the hardware, we'll actually disassemble the technology, we'll examine it for entry points that may meet JTAGS, it may be UART connections. We'll also dig in deeper into RF communications at this point and try to identify what kind of data is being communicated in that path and is it properly secure.
Also, as part of this process, we'll attempt to gain access to the firmware. If we're unable to get a copy of the firmware via the cloud APIs, we'll often open up the device and actually pull memory, flash memory, directly off the device, and then we'll analyze that for embedded keys, embedded passwords, and other issues, like undocumented command structures that could be used to carry out further attacks on the device.
By focusing on all these key pieces, we can identify any security models and how they impact each other within that particular model.
Thank you very much. That was this week's Whiteboard Wednesday.
