Anyone who has been cursed with using anything related to CarWings might not be surprised by this. I swear their backend is running on some intern's personal laptop. That feature where you can preheat your car from your phone? Be sure to allow a few minutes to do that. Start the app, wait 30 seconds for it to log in. Go to "Climate". Oh, shoot, it thinks the heat's still on (the app does a pathetic job of managing state). Click "Turn Off". Wait another 30 seconds (or more) while it round-trips to the car. Click "Turn On". Wait another 30 seconds. Go to car, expecting it to be warm. Open car door to discover that it's stone cold.
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.
> Nissan knows if they tried to charge for CarWings, they'd have three paying customers because no one else would pay for that crap.
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 authentication. The only sort of authentication token is linearly predictable and printed in plain text on the outside of the car.
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).
Car companies are terrible at making software. I'm not surprised that they want to lock down the ECU code, since it's probably awful and full of subtle bugs as well, and they don't want to get hit with tons of lawsuits when people find a bug in the firmware.
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.
It's genuinely scary to see how trivial these attacks often are. Who on earth wrote these API endpoints and thought they were acceptably secure?
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...
Bad stuff happens - I think it's a pretty safe assumption. What is worse is that there was some PM out there who didn't want to immediately disable the whole service until the issue was fixed. So I think this disclosure is a fair thing to do - when they choose between PR image or security, they must understand that both can get dragged through the mud.
Seems to me that this goes beyond "bad stuff happens." To me, that phrase would apply to stuff like using a weak random number generator, or forgetting to check some critical piece of authentication, or accidentally leaving some test code enabled that lets people go where they shouldn't. Basically, inattention or oversights or lack of understanding.
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.
Ideally a car company with a record of good manufacturing partnered with a software company with a record for good security. But I don't see that kind of partnership happening with the likely players we're talking about in the space.
Neither. I'll continue to assume that embedded code is shitty and insecure, because it always has been before, and nothing about the fundamental economics of the problem have changed.
What's the developer ecosystem around car software like these days? I mean, in an industry in which mechanical/aerodynamic engineering is so paramount, what is the rigor of the mindset and culture among the groups that build the network and user-interface software? I'd have to guess that it'd be an emerging field, with the IoT being relatively new, even if it were heavily populated by programmers who worked on the more traditional aspects of vehicle operation (engines, etc)...and with the overall high demand for skilled developers in all the other parts of software industry.
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.
So far as I can tell, it combines the rigor of the Toyota unintended acceleration code with a zillion global variables with the Volkswagen approach to regulatory compliance with the IoT approach to security and vendor lockin. By the sounds of it they're discovering the mobile industry's approach to extra charges.
Sounds like a "greatest hits of terrible development practices". Hey, at least everyone won't have to bring their vehicle in to a stealership to get it updates if they ever release a fix. Wait.
How does the Leaf connect to the servers to receive commands? How secure is this link? It would be easy to speculate that after breaking into the link between Nissan servers and the car you'd be able to do rather more mischief and likely exploit vulnerabilities in the software itself to do things not exposed in the API. Its easy to imagine that there isn't even a firewall between the remotely-accessible system and the engine control system. Its also easy to imagine that the data being uploaded to Nissan is rather more privacy-invading than the travel log exposed by the public API. We want someone to hack into the Leaf and expose it wide open.
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").
The car actually randomly asks you permission to do this. You will start the car up and there will be a dialog asking you to continue to allow the computer to communicate with Nissan. If I recall, you also need to enter in some credentials into the car's computer for it to communicate with Nissan.
The car actually randomly asks you permission to do this.
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.
No. And even better, when CarWings stops working at the end of the year because there's no AT&T 2G network for it to connect to, you'll still be pressing "OK" twice a day for no reason at all.
On a Tesla its not a back door, its a front door, and its there by design. If you don't want a car that can accept some commands from the net, don't buy a Tesla. But my point is that given they wanted those features, Tesla at least built them with security in mind.
I was very interested in the car up until they said that they would push out an "over the air update," please would you be able to point me were on their product page they said they could push software updates and remote commands to your device after you purchased it?
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).
> please would you be able to point me were on their product page they said they could push software updates and remote commands to your device after you purchased it?
"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."
"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."
"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."
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.
If you don't like remote access to your Tesla, then go into the settings, locate the "Remote Access" slider, and slide it from ON to OFF.
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?
Tesla cars connect to the net via a standard SIM card arrangement. So there is a SIM card somewhere inside the dash that you could find and pop out if you really wanted to be sure. But then its goodbye autopilot, etc.
Autopilot will still work fine. It may receive periodic data updates, but it doesn't require a connection to operate. All you'd lose would be remote access through the app, further software updates, and any remote diagnostics Tesla might be able to do if you have a problem, assuming you also kept the car off WiFi.
That to me seems like the best option, considering a Tesla owner could then put the car back in when they need more assistance with the car or just, as you said, connect it to WiFi.
That seems like an agreeable compromise in my book, it requires user connect for Tesla access.
I don't know how one really could check that. At some point you have to trust the manufacturer to do what they say they do. Or don't, but in that case you can't really buy any car, since even if they don't advertise remote access, they could be lying.
I don't think I'll ever trust the manufacturer. I always need to check for myself. There is a lot of cool stuff I have learned over the years about cars as a result.
That's a lot easier than tearing apart every piece of software in a car to look for security vulnerabilities, intentional backdoors, and private information leaks.
I'm doing OK so far just buying older cars that were never saddled with any such crap, but I imagine that when enough time has gone by that I seriously have to consider a vehicle built that comes ready-to-exploit from the factory, enough hobbyists will have figured out how it's done that ripping out the radio won't be such a challenge.
There's no actual way of fixing this, if it ultimately relies on VINs. You can however mitigate it.
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.
The unfortunate part here is that the previous API used authentication, and the credentials were the same as your owners credentials for the Nissan portal. They released this version at the beginning of the year. The previous API endpoint appears to still exist and work.
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 :)
They definitely need to figure out something to mitigate the public information bit. Aside from (presumably) a cost associated with it, there isn't anything stopping someone from going to the DMV and getting the info they need about a target.
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.
They can fix the public API that the App uses, and change the App - e.g. they could scramble or hash the VINS that are transmitted over HTTP so that they are not so obvious and enumerable. They could also have some protection on the API to check for enumeration attempts.
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.
Scrambling or hashing the VIN wouldn't fix the problem. The VIN is public knowledge (literally printed on the car in plain sight), and the scrambling/hashing procedure would also have to be public knowledge since you're literally putting it into the hands of users.
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.
Yeah granted. But obfuscating the VIN in the HTTP traffic would be easy and would at least help a bit. E.g. the guy that wrote the article would have had to dig a lot deeper to figure out what was happening. It still would have been scoffed at, had anyone figured it out, I agree.
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...
That Jeep link is great. I heard about the hack when it was first floating around, but never saw the details.
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.
Came here to echo the last part. Whether is some type of PIN code Oauth flow and/or QR code. There is an extra layer here you can put in the car software that can pair an app/car with a user.
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.
>Mr Hunt said the root of the problem was that the firm's NissanConnect app needed only a car's vehicle identification number (Vin) to take control.
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.
This is unbelievable. Any decent API would have the client authenticate via user credentials over an encrypted channel to obtain a temporary token (that's only valid for a short time period), and all subsequent command requests would require the token to successfully proceed.
What would prevent the auto companies from hiring someone with a clearer idea of how securely architect these things?
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.
There's a bunch of problems with this that established companies face:
The cool kids want to work for Tesla in the Valley, not Nissan in podunk nowhere (which for a lot of people is anywhere but SV).
These companies don't know how to find and hire the kinds of engineers who can do this right, even if they could get them interested.
Even if they could get them, the culture still matters - the right engineer(s) can't fix the problem if the culture / management structure won't allow it.
I heard that the car dealers won't allow car manufacturers to apply over-the-air updates (for example) because it breaks the agreement between dealers and manufacturers (all maintenance and service must go through dealers). I'm not sure if thats true but its pretty hilarious if it is.
Yes, every Leaf has a built-in 2G modem that connects to AT&T to facilitate this service, and they don't charge for it.
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.
All new cars sold in the EU will soon be required by law to have a cellular connection capable of "eCall" (reporting the car's location in the event of a crash).
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.
Yes, a lot of cars have 'sim' card built-in Ford uses this and they're not hiding the fact[1], any car that can autoupdate itself has sim card that connects to remote servers and can be controlled, afaik it's encryption and security is worse than 2G.
I bought a used Leaf two weeks ago from a dealer. From the dash computer, I saw the previous owner's CarWings username and password, as well as his address book, Bluetooth details, and lots of other history. I called Nissan to register the car with the Owner's portal (https://owners.nissanusa.com) and remember being surprised that I didn't have to give Nissan anything that proved I owned the car.
This is borderline negligence for the lack of authentication and security of the app. I suppose it may just be a matter of time until someone figures out how to get access to other more critical systems in the vehicle, similar to the Tesla vulnerability from last year. It took the Tesla security researchers less than a year from when they found they could access the sound and climate systems (over similar cellular networks) to being able to flash custom firmware on-the-fly and take control of steering and acceleration / braking.
We bought a loaded one (leather, premium stereo) used with 11k miles for not much more than that. Best value around if the range works for your driving requirements.
Clarification: this is a vulnerability in the Internet of Things component attached to the car. The car itself fine, and the vulnerability is only in devices with the silly and expensive IoT upgrade package.
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)
Just a nitpick: being able to remotely turn on climate control in a non-EV would be much worse, as it could be life threatening if the car is in a garage. With an EV the worst case is you need to tow it to a charger.
It doesn't look like this affects any systems used to move the car. Still, will I need to start asking if my next automobile is air-gapped at this rate?
Since A/C and heat run off the same battery pack that moves the car, compromising remote climate control can be more than just a nuisance. Someone can ensure that you wake up, or leave work, to find your battery has no charge left and you can't get where you need to go. It's like being able to siphon your neighbor's gas tank, while their car is parked in their garage, via an app.
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)
>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)
>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)
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.
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.