Slashdot Mirror
Tesla Model S REST API Authentication Flaws
An anonymous reader writes "New Tesla owner and Executive DIrector of Cloud Computing at Dell, George Reese, brings the Tesla Model S REST API authentication into question. 'The authentication protocol in the Tesla REST API is flawed. Worse, it's flawed in a way that makes no sense. Tesla ignored most conventions around API authentication and wrote their own. As much as I talk about the downsides to OAuth (a standard for authenticating consumers of REST APIs—Twitter uses it), this scenario is one that screams for its use.' While not likely to compromise the safety of the vehicle, he does go on to say, 'I can target a site that provides value-added services to Tesla owners and force them to use a lot more electricity than is necessary and shorten their battery lives dramatically. I can also honk their horns, flash their lights, and open and close the sunroof. While none of this is catastrophic, it can certainly be surprising and distracting while someone is driving.'"
Can someone give me a car analog?
The Tesla Model S will not allow you to run any controls remotely while you are driving even when logged into the iOS as a validated user. One can't honk the horn, flash light, vent the sunroof or unlock/lock the car while it is moving.
Hopefully a light will come on over at Tesla about API security. Let's just hope it's not a Phillips Hue (http://www.engadget.com/2013/08/14/philips-hue-smart-light-security-issues/)
how fast is the car
It seems pretty obvious that while an attacker couldn't directly cause an accident, say by taking over steering/acceleration/braking, there are many ways that the driver could be distracted, and distracted driving is extremely hazardous.
Of course, the real problem the author identifies is that someone could track your location(!). Obviously, inconspicuousness is a high priority for someone navigating public roads in a cutting edge automobile.
Well, terminal velocity will depend on two factors: The ultimate wind resistance of its tumbling chassis, and how high it is above the ground when you drop it.
I've fallen off your lawn, and I can't get up.
There's something of a difference between "hey, look, some guy in a neat car" and "John Q. Private is currently at mile marker 23 on highway 2, proceeding at 65 mph in an easterly direction, with 100 miles of range remaining."
I've fallen off your lawn, and I can't get up.
With all the news about medical devices with deadly security flaws, and people even hacking into cars (even if only from the backseat), I can't believe Tesla really didn't even *try* to add proper security to their API. The only right way to do it (from a corporate perspective) is to hire an outside security company to audit your design and implementation, and to continue to monitor the security whenever changes are made (so continuously in this case). It's well known that you can't trust the programmers to implement security properly, especially if you had Elon Musk screaming over your shoulder like Steve Jobs all the time.
"I have never let my schooling interfere with my education." - Mark Twain
"I can also honk their horns, flash their lights, and open and close the sunroof."
So he discovered a 10 year old?
Solving Unix problems since 1989...
From the summary :
I can target a site that provides value-added services to Tesla owners
This all seems scary, but it seems like all he is saying that he can hypothetically exploit some hypothetical site. Can someone explain how this is different than me saying "I can install a key-logger on your computer and get your email password and read your email!" ??
John Q. Private is currently at mile marker 23 on highway 2, proceeding at 65 mph in an easterly direction, with 100 miles of range remaining.
Say I am John Q. Private. Can you give me a scenario where I might care that someone has this information?
I really can't think of anything bad that could happen to me if that information fell into the wrong hands. Or at least, nothing worse or more likely than many things that could already be done to me by someone with far less information.
My car physically suddenly misbehaving, even if limited to peripheral systems -- that I can easily imagine causing a distraction and subsequently an accident.
Sure. It is like using web based certificates in PKI but in this case there is no revocation system and mandatory 3 month validity for all certs. I have to give this key to a third-party in order to be able to do anything user related like view my emails. That third-party or someone who gains access maliciously to the cert database can use this cert to make a connection to my computer that I can't turn off, to make my cpu spike or use up all the ink in my printer, until the 3 months is over.
...wait a minute, I think I did this wrong
I'd said I flashed your lights mama
your horn won't even blow
I even flash my lights mama
this horn won't even blow
Got a short in this connection
hoo-well, babe, its way down below
'Nuff said.
I'd say being able to flash someone's headlights if they're driving on a winding, unlit road, at night, could most certainly be catastrophic.
Tesla is a big target in the crosshairs of the automotive industry right now so I'm very skeptical. Tesla is doing what no other company has been able to do in the US and that seems to be a problem with everyone from dealers to falsified reviews in The New York Times. Let's do without the TFA drama have a look at the the egregious attack vectors listed:
1) You want to leverage a tool on a website with some useful functionality. You enter your email/password. They willfully and incorrectly store that information and are subsequently compromised (or worse, they use it themselves).
This is a really broad claim. What's more, if you haven't logged in over an SSL connection then... well, you're kind of a dumbass.
2) An attacker gains access to a website's database of authenticated tokens. It has free access to all of that siteâ(TM)s cars up to 3 months with no ability for the owners to do anything about it.
This is no less dubious that so many online services that I couldn't begin to count. The risk of compromise is an accepted one and hopefully mitigated. No fair faulting them without seeing how they would handle said compromise.
In a nutshell, TFA is going to need to find more substantial basis for panic than this. Sheesh.
Join the Slashcott! Feb 10 thru Feb 17!
Read the article. This 'flaw' requires a Tesla owner's email address AND password to 'exploit'.
...are doomed to so so in a way that is somewhat less secure but infinitely more usable.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Like the fact that Tesla's API is closed and 3rd-party applications are unauthorized and using it without any documentation other than what's been figured out through reverse-engineering. No doubt they need to do some work before publishing an API, but there's no warranty when you use homebrew.
Eagles may soar, but weasels don't get sucked into jet engines.
This was intentional because the Tesla S is an electric car. The security issues were released on purpose.
Now the media will say things like "but anyone can potentially honk your car, avoid this electric car!".
NIH syndrome. Like most of the world's software security flaws, they stem from shitty Dumerican programmers and bean counter mega-corps.
This brings 2 questions to mind:
1) Can an attacker use this exploit to remotely alter the heat and A/C settings?
2) Presuming the answer to 1 is yes, couldn't they use said exploit to overheat the element or over-cycle the compressor, causing a fire?
Third, kinda related question: Knowing that compressor motors and heating coils are the biggest amp draws in any circuit, how much does heater or A/C usage affect range? As in, running the A/C | heat at full blast would reduce the range from ~300 miles to what?
An enigma, wrapped in a riddle, shrouded in bacon and cheese
...i didn't want to drive that fast, someone must have hacked my car...
The article is mostly FUD. To start, OAuth is not a User->System authentication system, its a three party authentication system. For OAuth to work as intended the three parties involved need secure communication channels between the pairs (e.g. user to api, 3rd party to api, and user to 3rd party). This leads to the fact that his first two complaints about the Tesla service, are also inherently present in OAuth when implemented in a non-web app:
* Entering login information into any application inherently provides it to the application's author
* SSL is required between the 3rd party and the API service, otherwise eavesdroppers are able to obtain the API token, secret and user token
The final two flaws are really the same issue and are not part of authentication; however it is important that users are able to revoke access that they've provided to third parties. Missing that ability is certainly a problem but it is not a flaw with authentication.
While there are better methods for authentication that ought to be used by Tesla for their API (e.g. a long one time token the user enters, a QR code scanned, etc.), OAuth is not a better form of authentication for desktop or mobile application.
It is a button press away to turn off remote access on the Tesla S console so if an owner is concerned they can turn the interface off. TFA implies that if you give away your credentials and get hacked, you're screwed for 3 months which is not true. Tesla warns repeatedly to be very careful about who you give your user name and password to, not that doing so creates a danger, they are just trying to educate their owners. Tesla's use of a proprietary system as opposed to OAuth isn't necessarily wrong or less secure. It does however point to a more interesting policy; Tesla will have more of an Apple style walled garden than a wide open Android marketplace for anything that communicates with the car. Finally the whole business of economic loss and damage to the batteries is silly. I seriously doubt that less than a dollars worth of electricity if somebody turns the air or heater on are going to be an issue for the typical Tesla owner. And no, the interface does not allow you to turn on the heater and the air conditioning at the same time - you can set the target temperature for the interior. Nobody is going to put up with this happening all the time and suggesting battery damage by using the car in a way it was designed to do exposes the article for what it is.
Greed is the root of all evil.
Much of Tesla's criticism of the Times was based on , supposedly, data that Tesla downloaded from the test vehicle.
Does this security flaw make it more likely that tesla, or a tesla employee, could have altered the data ?
Rest assured that the matter will be taken care of... And the trick will be to honk the car of Mr. Musk and it will be taken care of promptly.
It's funny how I make sense to others and not myself...
Haven't people understood that the previous owner is all about hype and making money, not "make the future safe and fun" as he may like to claim...
199409 Scientific American - Software's Chronic Crisis, W. Wayt Gibbs [software is being written but not by programmers]
Flying fucking cars. Tesla will be first out of the trap on this.... shirley.
Give it a week.
No doubt Tesla will create another 25+ page document to try and justify everything.
If you look at that API and you think it's REST, then you don't know what REST is. Here's Roy Fielding's blog post where he points out that these types of APIs aren't REST. Roy Fielding is the guy that described this architectural style and coined the term "REST" in the first place.
Here's one example: You perform a GET request at /vehicles to obtain a list of vehicles. These vehicles take the form of JSON data, including an id attribute. If you want to perform operations on a vehicle, you need to construct URLs of the form /vehicles/{id}/.... That is not REST.
REST is hypertext driven. It revolves around content types, not manual URI construction. If that were a RESTful API, it would describe a vehicle list media type, and that media type would contain URIs, not IDs that you have to construct new URIs from using out of band knowledge. Their approach is like if every web browser was hard-coded to find articles at /articles instead of using links. It's dumb.
This misunderstanding is far too common. Don't guess at what REST is when you construct an API like these guys did, look it up for yourself.
Bogtha Bogtha Bogtha
Why is this an issue?
Everything is secure, as long as a malicious piece of code doesn't steal the users' username, password and/or temporary authentication token. So - how would they claim to permit any type of login without this information being on the device - unless you make the user enter a password on every login (which I guess could still be snooped). Pretty much every authentication system I can think of - from "plain", to Kerberos to things with session tokens have a vulnerability where if someone could "steal" a piece of data (like a token) one could get in. The only real way around it would be to perhaps put a two-factor authentication system with a very short timeout - but that just closes the window and makes it more annoying for the user.
So - what is this article really getting at???
I want TSLA stock to go down!