In this week’s Whiteboard Wednesday, Deral Heiland, research lead for IoT technology at rapid7, discusses Internet of Things (IoT) API testing, particularly around tracking IDs used to identify, manage, and manipulate devices via cloud services.
Welcome to this week's Whiteboard Wednesday. My name is Deral Heiland, research lead for IoT technology here at Rapid7. This week we're going to be talking about IoT API testing. Specifically, we're going to be talking about tracking IDs used to identify, manage, and manipulate devices via cloud services. Most IoT technology—or a lot of IoT technology—utilize Bluetooth low energy quite commonly, and when a tracking ID used to identify a device and control a device happens to be the MAC address for that Bluetooth low energy, this creates a higher possibility of an attacker to be able to identify and potentially gain access to control that device.
Why do I say that? Well, first we also need to make sure that the APIs are secured so that somebody cannot manipulate another person's device via this tracker ID. But second, MAC addresses are very predictable. The first three octets of a MAC address are actually the organization's unique identifier. Those are specific to the actual Bluetooth chip that's actually on the device. The second three are the NIC controller specific. Those ones will always change. If you gain access to a device or have a device, you can easily identify what the organizational identifier is and then you can set up application code or use Burp Suite to potentially guess through these other identifiers. And if the APIs are flawed, it may be possible to identify other people's devices or gain data or actually control the device.
One of the examples of this was in a blog we recently posted on the Eaton Halo where the actual MAC address was used to actually query information about a device. Vendors in some cases, will actually make an attempt to obfuscate this. Some of the methods they use is actually reordering the octets. The Halo, for example, actually did that. It swapped the first three octets with the second three octets to try to obfuscate this. They called that the MAC address, but they also had what was known as the familiar MAC address, which was the actual correct structure. Other methods they'll use is completely reversing the MAC address and I've also seen where each octet is actually hex encoded to obfuscate this process.
What should vendors do that are producing products? First and foremost, we need to make sure our APIs are secure and thoroughly tested to ensure an unauthorized user cannot actually query another user's device, gain access to it or manipulate it based on that identifier. That's first and foremost. Second, we need to move away from this method where the Bluetooth low energy MAC address is used for an identifier. This may be unique, but it is guessable and predictable.
One of the methods I recommend is utilizing UUIDs. These unique identifiers aren't easily predictable or guessable in any fashion, and they prevent the device from giving up information potentially. Like I said, first and foremost, make sure the APIs are secured. Second, move to UUIDs, take every effort to protect those UUIDs so they are not disclosed. And if these methods are actually followed, this will reduce the risk of your devices or system's data being compromised or the device being controlled by somebody who is not authorized.
That's this week's Whiteboard Wednesday. Thank you very much.
