Last updated at Wed, 30 Aug 2017 01:02:31 GMT

Over the past couple of years I've dove into Internet of Things (IoT) security research and found it to be a rather fun (and sometimes terrifying) mixture of technologies, [in]delicately woven together to provide for some pretty useful, and not so useful, devices. It's a very exciting time right now as technologists navigate the nascent waters to determine what the best-of-breed platforms, protocols, and languages that will drive IoT for years to come will be. We're at the HD-DVD v. Blu-Ray phase in a lot of ways, except there aren't just two players in the space, but thousands of organizations all trying to get their special new technology to be the cornerstone of a revolution.

Recently, I was invited to speak for the Plug and Play Tech Center as part of my mentorship for their Plug and Play Accelerator portfolio companies. In my presentation, I conveyed to the very people who are creating the newest generation of innovation what real-world security research has uncovered for those early participants in IoT. By explaining the security missteps of vendors and guiding the appropriate ways to avoid those mistakes in the future, my hope is that the audience left with actionable guidance to create a more safe and beneficial contribution to this world.

In this blog post I'd like to give a high-level sense of what IoT security research often entails. This is definitely not a comprehensive post, as, I'd have to write a book and then get about a dozen co-authors to accomplish that. This post is intended for the casual security researcher, or even IoT vendor, who wants to know what this research looks like, and where to get started. I hope it spurs additional research into this space, because there's plenty of ground to cover.

IoT Has Many Avenues... Where to Start?

There's a long-winded excitement to IoT security research because in many cases there are a number of technology components involved, including mobile applications, Bluetooth, Wi-Fi, device firmware, services, APIs, and a variety of network protocols. Each of these has the potential to provide a researcher with new insight into the operation of the device or become a critical foothold to take a next step in the research process. Where you start with research covering this many areas is certainly a personal preference, but I happen to like to begin with the mobile application.

Mobile Applications

Because a mobile application is often central to the function of many IoT devices, the contents of the application are likely to provide clues about how the device operates and could even leak hardcoded credentials, protocol details, and keys. Since I am an iOS person, I often use Clutch on a jailbroken iPhone to provide me with an unencrypted version of the device's app. Once you have this, simple CLI tools like strings and otool are a good start to get a sense of what the application is up to.

Of course, more advanced application analysis is possible with tools like Hopper or IDA, but you'd be terrified what you can find without much trouble in these applications. Also, I highly recommend taking a look at Dan Mayer's awesome tool, idb, which will help streamline your iOS efforts with a nice GUI and integrated tooling to accomplish tasks more easily.

Inside the application, try and look for interesting classes, hardcoded strings, and other details that may provide privilege over the device never intended by the developer. I've found hardcoded root credentials, API keys for Amazon Web Services, URLs never meant to be known to end-users, and manufacturing network configurations. There can be a treasure trove of details if you look intently enough and a lot of flexibility if you instrument against a live application and see how it operates.

If you're interested in learning beyond these basics, check out Android Hacker's Handbook and/or the iOS Hacker's Handbook for in-depth knowledge from some of the best minds on each of their respective platforms.

Network Traffic

Once I've gotten into the mobile application and have seen what I can see, I like to start using the mobile application and begin interacting with the IoT device. This includes every step that I can witness, from setup to registration to normal usage. Using network analysis standbys such as mitmproxy, Wireshark, Burp Suite, and Ettercap, you can view connections from the mobile application to the device, and the device to the Internet. In many cases, you'll even be able to intercept SSL/TLS connections with little trouble using these types of tools. Some applications (and hopefully more in the future) utilize certificate pinning to thwart MITM attempts of encrypted connections, but of course there's always a way around that.

By combining knowledge you gained through looking at the mobile application with live traffic, you can quickly understand how this device functions at a network level and start diving deeper into how it performs authentication, transport security, what inputs the components take, how outputs are rendered, platforms & frameworks being leveraged, and even see data that the developer perhaps never intended you to see. Whether web or mobile, applications often leak data unintentionally by developers who failed to scope a database lookup tightly enough, or send data over before it should have been sent. Whether by design or mistake, API calls and the resulting outputs can lead to some interesting findings.

Beyond simple network traffic, interception can actually lead to entire firmware images for the device. While older technologies may have required users to plug in a USB device with a firmware image loaded, IoT is heavily driven on over-the-air upgrades, often via Wi-Fi or cellular networks. Due to this, vendors aren't as likely to widely publish their firmware on FTP sites like you may have been used to with your older home routers. By observing network traffic at the right moment (e.g. user-requested firmware checks, vendor-pushed updates), analysis can lead to either downloading the entire firmware image while it's in transit, or a URL that contains firmware images when your device checks for updates.

Embedded Hardware

Investigating an IoT device's actual hardware can be quite beneficial to research, especially if you were unable to acquire the firmware via other methods. Further, physical access can quite often lead to administrative console access, giving a direct method to explore the operating system, applications, and configuration in a running environment. While an occasional device may provide network services like SSH or Telnet to connect to it, the credentials to login are rarely provided to end users. Thus, hardware may be one of the only ways to really gain hands-on access to the environment powering your research project's device. There are a number of standards related to hardware debugging that can lead to physical interaction with a device, such as JTAG and UART. Well known hardware hacking tools such as the Bus Pirate open up a new world of IoT research possibilities using these protocols and more.

In the case of JTAG, finding pins could provide deep access to the hardware, including capabilities to dump memory or halt the chipset. Because analyzing test points of hardware

to find the appropriate pins can be time consuming, Joe Grand created a device called the JTAGulator, which automates this process for both JTAG and UART. While JTAGulator is great at identifying JTAG pins, it doesn't really do much with JTAG beyond basic sanity checks. I personally have a SEGGER J-Link that has numerous tools to interact with JTAG on IoT devices, allowing for tasks such as dumping memory via GDB.

While JTAG is made for deep, powerful control of hardware components, UART often provides a simple serial console connection to the device's operating environment. With either your existing JTAGulator, or a simple FTDI USB serial cable, software like minicom or screen is all that's needed to interact with a UART connection. Once connected via UART, a researcher can investigate the device from the inside-out, executing applications locally, exploring configuration files, and looking for new avenues of exploitation. While being able to download firmware, or dump memory, or analyze network traffic is hugely important, being able to work in the actual device's operating environment can be a major foothold in understanding howthe device is working.

Lastly, if you're still struggling to find firmware images, you may be lucky enough to have a device where the flash can be physically accessed with a testing clip for SOIC packages. A tool such as flashrom can easily leverage a device that speaks SPI to pull the firmware directly off of the flash while still attached to the device. I've personally had a great experience with Xipiter's custom device called the Shikra to pull firmware using flashrom when other tools had failed to get a clean dump of the image. Even better, Shikra also speaks UART and JTAG, too!

Wireless Communications

One reason why IoT is so capable to amaze us is through a distinct lack of network tethering. Without the need for thousands of feet of CAT-6 or serial cables laying around, IoT is able to exist in the form of everything from IP cameras to tiny water sensors. Today, standards like Wi-Fi, Bluetooth Low Energy (BLE) and ZigBee have changed what is possible over the air, enabling IoT innovators to continue to realize their creativity. Much like the other areas I've discussed, a special world of technologies exist to enable researchers to better understand the usage of these wireless protocols as the glue holding IoT function together.

Long-time Wi-Fi hackers are probably quite familiar with software like Kismet, but they may not realize that Kismet can do more than just Wi-Fi. In fact, using hardware such as an Ubertooth One, Kismet can provide Bluetooth capabilities to researchers. Alternatively, there are a number of Ubertooth tools capable of providing insight into Bluetooth traffic. If, however, you're more interested in ZigBee, Joshua Wright's KillerBee framework can be combined with an Atmel Raven USB to have a powerful assessment toolkit in a small form factor. Lastly, If you're really not playing around, a HackRF provides software defined radio (SDR) functionality that won't let you down.

IoT is a Fabric of Technologies

If you've been reading this post, you may be thinking, "...this just seems like a lot existing technologies all bundled together..." -- bingo! You're all-but-guaranteed to have a broad experience in technologies, protocols, and platforms by diving into an IoT security research project. Due to the nascency of IoT, there are very few standardized aspects of a device you'll encounter, ensuring a fairly unique and exciting experience. Perhaps more intriguing is the reality that the research you perform could have a lasting impact on the direction that IoT moves by guiding vendors to make more secure choices.

One such initiative to help guide IoT down a safer path is called BuildItSecure.ly. By creating opt-in relationships with IoT vendors, small and large, the researchers at BuildItSecure.ly can help to inform and influence the decisions being made by the very innovators you're waiting to release their next product. Vendors such as Dropcam, Pinoccio, Belkin, and Wink have all joined the initiative to work with world-class security researchers to make sure their products are more secure. While I am biased due to being a co-founder of the year-old initiative, I have to say that this sort of effort is exactly the kind of goodwill relationship that the research community needs more of and I'm proud to see it resonating with those familiar.

I hope that this blog post has helped to inform you of the burgeoning world of IoT security research and that you'll decide to make one of the many devices out there a focus for your next project.