Blog: Internet Of Things
Identity is important
Device identity is one of the most important security challenges in the internet of things. If you get identity management wrong, you run a significant risk of anyone being able to access all of your devices.
Getting it right can marginally increase production cost of a device, but a weak approach to identity can trash your brand if consumers lose faith in your ability to do it securely.
Getting it wrong; an example
A couple of years we were tipped off about some issues in Swann battery powered wireless security cameras as a result of some coverage on the BBC.
They had run a story where a guy who ran a pub opened his mobile app to look at his cameras. Instead of seeing the footage from his pub, he saw footage from a brewery. He had approached Swann, but wasn’t happy with their response, so went to the BBC.
Why was he able to see someone else’s CCTV footage? We were intrigued, so bought a couple to investigate and clear up the issue properly.
One of the first things that we would do is proxy the traffic from the mobile app. We could see that it was trying to connect to several different networks:
We also noticed that it was interacting with a service called OzVision, a third party system. I’d had an interaction with OzVision in the past, a result of looking at another camera. Each camera identified by a serial number. Eg SWN for Swann, and then 9 characters of hex:
When we view that camera, it’s simply sending that serial number through to an API at the other end and viewing it. This got our interest, as the device was clearly being identified purely by the serial.
So what happens when you change the serial number of a camera that we own to another camera?
Proxying and intercepting the traffic allowed us to tamper with requests:
We owned both cameras with the above serial numbers, so all we did was swap one serial number for another one.
The cameras had two different serial numbers and were connected to two different accounts. That was sole control for authorising and identifying cameras.
We have given one of the cameras to a friendly security researcher, the awesome Scott Helme. With his permission, we simply accessed the camera in his house.
Nice Lego Scott!
The only thing linking that app to the device was a serial number plus 9 characters of hex. It’s not suitably unique or random; unlike a 128bit AES key.
This is a problem we see a lot in IoT.
Other bad approaches to identity
Quite often a device will have a MAC address. It’s unique, right? Hence it’s common that a device connecting over Wi-Fi or wired ethernet will use it’s MAC address to identify itself to a cloud platform.
Why? Because it’s cheap to do it this way. IoT developers are looking for something unique to the device to identify it from other devices, but don’t consider if it’s random enough to provide security.
Using the MAC is a very common method to identify a device, certainly in its ‘out of the box’ initial configuration.
In this example, the device makes a request along with its ID 79-a0-12, and says “Hi, I’m device 79-a0-12”, and the platform will say “Yeah, Hi, cool it’s you”.
The problem is that as an attacker we can just clone that identity. I can take that MAC address which is broadcast so it can be read from the local network or Wi-Fi.
But a MAC is 6 octets, or 2^48. That’s a lot of randomness, surely? Well, no.
As you’ll know, the first three bytes of a MAC address are called the OUI. Organisationally Unique Identifier. This means that we already lost three bytes of randomness in that identifier. So it comes down to those last three bytes.
We’ve come down from 2^48, which is a big number, down to 2^24.
What we often find is that it’s only those last two bytes that are used, so now we’re down to 2^16 which is 65,000 IDs.
If I can find a way of working out which of those IDs are valid are can connect to those devices and do bad things.
We often look for a vulnerability called enumeration. I’ll go through to a web API or some kind of platform and say “Hi, I’m device 79-a0-12. If the platform replies “Hi device 79-a0-12” I know that the device is real and I can interact with it.
If I say I’m device 79-bd-fa and the service replies “I’ve no idea who you are” then we know the device isn’t real and connected to the platform – an enumeration vulnerability.
What we used with Swann was a combination.
The web application could be used to enumerate devices to find valid IDs. We could send about 1,000 requests a second. To enumerate those 16 million IDs wouldn’t take too long.
Now we have the valid IDs and we can view the cameras feeds of anyone connected to that platform.
We also discovered that we could remotely root those cameras. At this point the platform could be considered completely compromised; all user CCTV could be accessed, should one wish to.
Fortunately Swann were highly responsive – the issue appeared to point to Ozvision & was very quickly fixed. A shame that it had been present for some time though; strong camera identity would have
Ideally, we would like a device that doesn’t have an identity based on easily accessed, easily enumerated or easily deduced information such as a sequential serial or MAC. We’re are looking for a cryptographically assured identity. Something strong that we can challenge. We can say to the device “sign this bit of data with your private key, and then I’ll trust you”.
It never transmits that private key, but we’ve got it’s corresponding public key, so this message can be signed with those private keys.
It’s important to remember that Identity can be cloned. We can take an ID of a device, and it’s possible the application server will just trust any ID and won’t check that the data has been signed – it’s not authenticated.
How does one give the device a suitable identity such as a private key? Probably the only robust way is to load it at the production line.
The drives cost upwards; it also brings in new security challenges such as assuring the root of trust through the supply chain.