Hacker News Reader

Comment by Someone1234 | Hacker News Reader

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.

View on HN

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 :)

This is easy - the legitimate customer has physical access to the in car screen where the attacker does not.

"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..."

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.

There is no danger of this. The endpoints are so slow that the ad network / site would drop it in minutes :)

If the AC stays on for X minutes, you only need to occasionally redirect an actual advertisement image to the endpoint to be effective.

It's 15 minutes[1] by default, I believe.

[1]http://www.mynissanleaf.com/viewtopic.php?p=363558&sid=1dec9...

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.

Doesn't this system use https?Hence why the author used 'fiddler'.

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.

Reply on news.ycombinator.com