Controlling vehicle features of Nissan LEAFs remotely via vulnerable APIs
troyhunt.com
troyhunt.com
That's just one example. Nissan said they'd charge for CarWings after three years. Going on almost five years later, we've yet to receive a bill. Nissan knows if they tried to charge for CarWings, they'd have three paying customers because no one else would pay for that crap.
With all its warts, I would have said nothing much would surprise me were a security hole were found. But this is just astounding. The prior API at least required creds. So they took an API that had some modicum of security, discarded that and just use a string that's visible from the outside of every vehicle? Picture me with my lower jaw hanging between my knee caps.
That and the service is going to break this year anyway.
AT&T is sunsetting its 2G network on December 31, 2016. It's already dismantled it (to reallocate the spectrum to 3G/4G/LTE) in some regions.
Most Leafs on the road only have 2G AT&T modems. I'm pretty sure Nissan was still selling them new in 2015 with 2G modems, despite knowing AT&T's plans. There won't be any CarWings service, or charging location updates, or anything else that needs internet on those cars once the 2G network goes away.
No rate limiting. They successfully used the linear nature to collect a list of valid VINs and validate them.
No apparent intrusion detection.
Bad response to security disclosure. They didn't fix the problem when it was reported, they still haven't addressed the researcher properly.
I'm not sure these are the right people to write life critical software (which admittedly, this vuln. does not appear to relate to life critical systems; just privacy and comfort).
Really wish they'd just use CarPlay / Android and go back to analog knobs to control HVAC stuff. Opening a modal dialog to adjust fan speed (in a 2015 MDX I've been in) is terrible UX and very distracting to do while driving. The 2nd gen Prius is no better, and the control panel UI in it looks like something from Windows 3.1.
If the car companies can't write software that would withstand hacking skills roughly equivalent to a curious teenager, what hope do they have against criminal organisations or nation states? I don't really want to think about it...
But here, we have a system that's deliberately designed to use, as its only public-facing authentication token, a string of characters literally printed on the car. No amount of inattention or oversight could possibly lead a person to confuse that for secret data, unless they were somehow totally unfamiliar with cars.
I have a hard time figuring out how something like this could even ship. To me, this is a lot worse than responding badly when told there is a vulnerability. After all, if you think it's OK to use something any passing stranger can read as a secret key, some random internet dude telling you it's insecure probably won't suddenly make you realize you've got it all wrong.
edit: I will inform HN if my climate control mysteriously turns on today :)
I'm being biased here because I recently bought a vehicle which charges some non-significant amount of money ($50, or maybe $99?) to just buy an iPhone app that connects to the vehicle's dashboard, then an HDMI cable if I want to connect the phone's video to the screen to watch my phone's movies, and then a subscription fee afterwards to do GPS and other on-demand services. Not saying that that's a shortsighted business model -- maybe car customers are paying for it in the droves -- just that it's one that naturally attracts fewer scrutinizing eyes, which can non-directly impact the attitudes and culture of the development team. Also, I guess I just don't see many auto software developers talking/showing their trade, as opposed to dev teams from other traditional behemoths -- such as Best Buy and Walmart -- who despite not working for their tech-focused disruptive competitors, still produce and share software that is public-facing.
Can I turn this feature off? How does it communicate?
The article says that you can, by disabling CarWings/NissanConnect. Which you should probably do if you're a connected Leaf owner, as it lets anyone control AC/heating and gives them historic driving information (date, distance and "driving efficiency").
> How does it communicate?
Lost the source (maybe one of the forums linked from http://www.troyhunt.com/2016/02/controlling-vehicle-features...) but I read the CarWings service sends an SMS to the car, which contacts the webservice to return its information.
No, it asks you every...friggin'...time you start the car, with no way to say "you have my permission from now on". I wish it were random, at least that way there be times I don't have to punch the "OK" button.
It's giving Tesla the keys to the car I bought from them.
When did such an egregious affront to privacy and device security become acceptable?
I must have missed that. I originally thought the Tesla was a great car, but I at some point saw that you could remotely manipulate the car and there was no method of disabling it.
I don't think anything of this nature is personally acceptably and I hate similar systems (see onstar).
"Model S periodically receives over the air software updates that add new features and refresh the touchscreen look and feel."
"Autopilot features are progressively enabled over time with software updates. The current software is 7.0, adding automatic steering and parallel parking."
https://www.teslamotors.com/models
"We may use personal information for a variety of reasons, such as those listed below: To provide service to your Tesla vehicle, including to contact you with service recommendations and to deliver over-the-air updates to your vehicle."
https://www.teslamotors.com/about/legal
"Tesla vehicles regularly receives over-the-air software updates that add new features and functionality. When an update is available, you’ll be notified on the center display with an option to install immediately, or schedule the installation for a later time."
https://www.teslamotors.com/support/software-updates
There's probably also purchase and service/warranty agreements you'd be signing prior to buying the car, but I don't own a Tesla so I don't know what's in those.
Never going to be buying one of those then.
Remote-brick-support is not a feature you want, and that goes double for any device that moves 100MPH with you inside of it.
BTW the Tesla wont update while you are driving it, lol.
If you don't want updates being applied to your car, don't press the INSTALL NOW button when the prompt appears, nor the SET FOR THIS TIME option to install it later.
Where did you get this idea that remote access can't be disabled and that updates happen without user intervention?
I'm not concerned about that end API, I am concerned about the company being able to manipulate my car without my knowledge or permission.
That seems like an agreeable compromise in my book, it requires user connect for Tesla access.
Cellular, apparently commands are pushed to the car via SMS, and the car connects to a webservice to return info or whatever.
Let's say you required an account and utilised authentication tokens, sure, that will stop unauthenticated requests. But what is stopping someone else from stealing your VIN and registering an account themselves? If you only allow a single account registration per VIN then what happens if the vehicle changes ownership?
VINs aren't a "shared secret." They're a public fact. Instead Nissan should be utilising a secret number stored in the vehicle entertainment unit and user accessible, and they should add a button to change it when the vehicle changes ownership. Heck they could even do a QR code if they really wanted registration to be as painless as possible.
Further, they also really need to change the HTTP method for the endpoints that change state.
Nothing's stopping someone from putting up an image tag on a well-trafficked website (or buying display ads on a network) with the src set as the endpoint that turns on the AC. Turns into a real-world DoS when the battery is dead.
[1]http://www.mynissanleaf.com/viewtopic.php?p=363558&sid=1dec9...
There's a second part where Nissan's servers talk to the car - that obviously will be harder to fix, but that bit is also harder to hack presumably.
What you need is some kind of actual secret token. For example, the car could generate a random value which you put into the app to link them. Or Nissan could track who owns what car, require a regular login/password to use the app (if they don't already), and only allow the account linked to the car to control that car.
BTW reminds me: Jeep had this clever system whereby the password was generated randomly by the unit. But it used the system time as a seed, and that system time was always the same cos the thing had just been turned on. The rest is history... https://blog.kaspersky.com/blackhat-jeep-cherokee-hack-expla...
Using the time as a seed is a bad idea even if it actually works, of course. It's too easily guessable. But doing it and then failing to even find the current time first is completely silly. You'd think at some point in development someone would have noticed that all the generated keys were identical.
I suspect that they may have dropped the credentials for the new API because they had so many problems with users figuring out what credentials to use for their mobile app. This is obviously a terrible solution, just speculating.
I wondered about hijacking cars by taking their VIN, but the process is not automated. It requires a call or two to Nissan to verify ownership before they will transfer the vehicle over to your account. This isn't to say you couldn't social engineer you way into the car, but you need more than the VIN. Incidentally you can't unlock the car remotely, at least not with the known endpoints :)
"To pair your phone, please ensure you're sitting in the car with the parking brake applied, enter this code when prompted by the car..."
Smart home hardware providers commonly do this by MACID and possibly some type of PKI infrastructure. But even MACID doesn't stop someone from taking my 'unregistered' Leaf and registering it to their own account.
And only the last 5 digits vary on these VINs, so you can just run through them all with a simple script in no time. They're using VIN as the unique key on these things and with no other authentication? Wow. Just wow.
I really think we've reached that point with IoT that its time to start proposing HIPAA-like regulation on this stuff. Its endless amateur hour out there.
I've poked around in the Tesla API and it's much better, based on OAUTH and an account registered to the specific owner.
There are things like insider bias to overcome, but if the older auto companies see Tesla eating their lunch over software, they will go ahead and overcome it.
Like my Kindle keyboard 3G?
Also each newer kindle had a greater price difference between wifi and 3g, and more restrictions
It's only active in the car if you've signed up for a CarWings/NissanConnectEV account on the Nissan Owners portal (which requires verifying ownership of the car with Nissan) and valid login credentials have been entered through the car's touchscreen infotainment system. That's why the article says people who haven't signed up, or who disable their account, aren't at risk.
Once there's a cellular system in there, it's 'free' for the manufacturer to add any other features they like and are willing to pay for the SIM for. Low volume "IoT" SIMs are a few euros per year.
Which makes me glad that I didn't pay extra for that.
If I don't register my car with the app, does that protect me?
edit: yep sounds like it does.
Well to an extent, if you've enabled the service any third party can remotely enable, disable or reconfigure AC and heating (which is pretty problematic for an EV), and the service also provides limited travel information (no GPS location, but travel times and distances)
I'm not sure why Troy can't just refer to others public research directly instead of repackaging it and using "responsible disclosure" as a cover for not sharing his (public) sources.
It seems sketchy at best, dishonest at worst.
>A GitHub repository documenting the API including the observation that “All other operations take the DCMID and the VIN of your vehicle as parameters for authorizing the requested operation” (although the DCMID value is not actually required and is empty in many of the examples above)
https://gist.github.com/joshperry/15eadc2a63b22632d6ae
>Another GitHub repository, this time a Python script to connect to and manage vehicle features via the API (also includes region codes for managing vehicles in other parts of the world)
https://github.com/jdhorne/pycarwings2
>Yet another GitHub repository built to target an earlier generation of the service and referenced as inspiration for the previously mentioned project
probably https://github.com/haykinson/pycarwings
>A blog post on reverse engineering the API which observes that “curiously, it seems like you just need the constant DCMID and VIN fields” (again, the DCMID parameter wasn’t actually used in our tests)
http://virantha.com/2016/01/12/reverse-engineering-nissan-co...
>A forum post on integrating the data into Domoticz (a home automation system) which makes this observation: “No other authentication necessary!”
http://www.domoticz.com/forum/posting.php?mode=quote&f=31&p=...
IMO, his behaviour is straight up despicable. This stuff isn't hard to find, but he still refuses to give proper credit because of "responsible disclosure". Yet, anyone interested in attacking the API can and will find this stuff on google.
Also, another example of Troy BS:
https://twitter.com/troyhunt/status/701733562253336576
Trying to publicly shame vkontakte for a nonexistent SQLi (this is a wiki page that anyone can edit, here's a wikipedia example demonstrating the same "vulnerability" https://en.wikipedia.org/w/index.php?title=%27&diff=70631701...)