Security Evaluation of Tesla Model S API | Hacker News Reader

Security Evaluation of Tesla Model S API

dhanjani.com

65 pointsIghart18 comments

Open articleView on HN

A bit tangential to the Main post, however, taking a quick look at the so called "REST API" of Tesla:

/vehicles/{id}/command/charge_port_door_open - Open the charge port.

/vehicles/{id}/command/charge_max_range - Set the charge mode to max range

/vehicles/{id}/command/door_lock - lock doors

These are all GET Methods.

I am a bit surprised that the company that claims to pay so much attention to detail has used Blatantly incorrectly principles (Using Idempotent & Safe designated HTTP methods for actions that change the state of the Car) for their "REST" API.

Where does Tesla call it a "REST" API?

AFAIK the API isn't even publicly documented (officially) and is only known because it was reverse engineered by sniffing traffic from the iOS and/or Android apps. The people who did that work refer to it as a "REST" API, but they aren't Tesla.

As far as whether they should be using GET for these calls regardless of whether they call the API a "REST" one or not -- they are a pragmatic company, and the simpler the software is on an embedded device like a car the better; strict adherence to the intent of various http methods is less important than just keeping things as simple as possible, maybe they didn't even implement post or put, I doubt they are running apache on that thing.

It's not a matter of 'simple', it's a matter of correctness. GET being safe and idempotent is really important. For example, you get breakages like this: http://signalvnoise.com/archives2/google_web_accelerator_hey...

And hopefully, even on an embedded device, sending a POST as opposed to a GET should be trivial.

If they only have one method it should be POST. HTTP clients are free to retry GETs without warning the user or even without their direction.

Do you know of any library that generates multiple GETs without some blatant warning in the documentation? I would guess that even though it might be allowed in the RFC it poses no problem in practice.

You're not calling those methods on the car. You're calling them on https://portal.vn.teslamotors.com/ which has no particular limitations. Likely the web service communicates with the car over their VPN using an internal protocol (though it could well be similar, since there are web servers running in the car.)

So there's no particular excuse based on "embedded systems". I do agree it should use POST, but it's not quite as bad as it looks. Besides it being an authenticated API (so bots aren't a real problem), the calls are almost all set up to create a certain state, and repeating that call once the car is in that state (or working on it, I presume) seems quite safe. 'auto_conditioning_start' and 'auto_conditioning_stop' are okay to repeat; 'auto_conditioning_toggle' not so much. Though one does kinda wonder about the horn honk one.

Car security is a big deal. The amount of code running on cars compared to the amount of security researchers working on it is incredible. I can count the car security researchers I know of on one hand.

This is really something we really need more of, even in cars without nice pretty APIs like Tesla's because they have a lot of code on them too.

Letting the car automatically phone home to the manufacturer worries me. Collecting anonymous stats about the car's health and battery condition will help them design better vehicles and firmware in future, so that's okay. But isn't knowing the location of each and every Tesla vehicle, and who they belong to some kind of privacy risk? Is law enforcement able to subpoena the manufacturer to release all previously recorded locations of an individual and use that as evidence against him?

The ability to remotely unlock the car opens up a whole new can of worms. Could someone potentially steal a car (like how they steal domains and twitter handles) through social engineering? Or perhaps by stealing the auth token on the user's mobile device? If you don't continue paying the loan for your car, could they refuse to unlock the vehicle remotely?

> The ability to remotely unlock the car opens up a whole new can of worms. Could someone potentially steal a car (like how they steal domains and twitter handles) through social engineering? Or perhaps by stealing the auth token on the user's mobile device? If you don't continue paying the loan for your car, could they refuse to unlock the vehicle remotely?

You know GM's OnStar [http://en.wikipedia.org/wiki/OnStar] has existed since 1995, and allows not only for vehicle tracking, but the remote shutdown of the vehicle (typically used in the event of theft), correct?

And cars that won't start if you don't pay your loan are already a thing: http://edition.cnn.com/2009/LIVING/wayoflife/04/17/aa.bills....

So, just to summarize and understand this article:

Basically, the Tesla software has some holes that need to be patched and some security settings changed. However, there has not been a proven method to penetrate the cars' software yet.

I see this becoming a concern the in the coming months as more people purchase a Model S and more people start to tinker with it. I am intrigued to see if systems such as propulsion and braking are easily hacked considering how the whole car is basically networked. We shall see...

I'd summarize it as there are currently gaping security holes that leave the car immediately vulnerable to a determined hacker. The currently level of security is below what anyone could reasonably consider minimum enterprise level.

I would summarize it more as, the main vulnerability is the user's choice of password, the security of their email account(including phishing emails), or the possibility that a tesla employee could fall for social engineering. None of which are actual vulnerabilities.

There is the possibility that one day an issue could be found in one of their services, but these issues could be found in almost any modern service.

...including our bank accounts, which we might have protected with a pretty bad password and might contain more money than it costs to buy a Tesla. Someone's Tesla will get stolen, just like anything gets stolen, but I find it difficult to imagine a mass theft of this or any particular vehicle. At any rate, this might give people to think about the passwords they use for things that aren't as expensive as a car.

>None of which are actual vulnerabilities.

That's an extremely dangerous position to take. Any reasonably secure system deals precisely with these problems through password policies and principle of least privilege. For example, successfully phishing a Tesla engineer's email credentials should not get you access to active vehicles. If this were the case, I would classify this as a major vulnerability because many things can result in access to someone's email.

OnStar by GM has many of these features (app, location, unlock, customer service representative can unlock etc.). I don't think there is a recorded hijack/hack there too.

It's not that these features exists which is the problem. It's that Tesla has implemented it's security poorly, potentially exposing these features to hackers.

Calling from the registered phone number and verifying address is all you need to get OnStar to unlock your car (I am not sure if its still the case now, but it was the case two years ago).

Same thing for username and password. That's all you need to log into their app. Not sure about failed attempts, but there are no other authentication methods.

Reply on news.ycombinator.com