I got a bit waylaid the last couple of weeks working through the vulnerabilities in Nissan’s LEAF, their best-selling electric vehicle. What it boiled down to was the ability to remotely control the climate facilities in the car as well as pull the driving history, all with no more than the vehicle identification number or VIN. Perhaps unsurprisingly, a media storm of press followed with many articles explaining how the vehicle could be “hacked”, but that’s stretching the truth a bit.
I know very little about how the electronics within cars work. I’d have no idea what I was doing if I had access to the firmware within the vehicle; the closest I’ve come to any of that is modifying performance cars, a task I’d always entrust a workshop with because frankly, it’s just not my expertise. But I don’t need to understand those things to find vulnerabilities like Nissan’s – let me explain.
The mechanics of how web applications work – now that’s something I understand. Every command that controls the Nissan LEAF’s functions in the way I wrote about last week is simply a request over the web. That request is then routed through Nissan’s infrastructure whereupon they relay it to the vehicle and ultimately instruct the software running in the LEAF to perform certain tasks. But because the commands start out life as web requests, they’re at risk of many of the same vulnerabilities we see in more traditional web apps.
The Nissan “hack” is a perfect example of an insecure direct object reference risk. We’ve seen these many times before, perhaps most notable in AT&T’s implementation that allowed an attacker to pull out details on 114k customers in 2010. It’s exactly the same premise: observe a web request that has an ID in it, change the ID to another one (usually easily guessed) and then send the request back again. It’s that simple and we know this risk exceptionally well, yet here we are.
When I look at a smart phone app like Nissan’s, what’s at the other end of it is almost inconsequential. Whether it’s a website, a car or any number of other IoT things that have had vulnerabilities in them lately (light globe, kettle, door bell, toilet – yes seriously), it’s the same patterns I’m observing when it comes to controlling them via a device connected to the web. I suspect the people building these systems lose sight of the fact that the web has a very well-established set of vulnerabilities they need to be conscious of. I know the press misses the fact that an incident like this is a web vulnerability and not a vehicle vulnerability, but then one of those doesn’t quite have the same ring to it…
Ultimately, this is all just another example of a very well-known web application security risk, it just happens to have a car plugged into the other end of it.
