Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Transportation Security

Tesla Model S REST API Authentication Flaws 161

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.'"
This discussion has been archived. No new comments can be posted.

Tesla Model S REST API Authentication Flaws

Comments Filter:
  • by Anonymous Coward on Tuesday August 27, 2013 @02:06PM (#44689281)

    Can someone give me a car analog?

    • by Rosco P. Coltrane ( 209368 ) on Tuesday August 27, 2013 @02:08PM (#44689311)

      Sorry, cars are digital these days.

    • 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
      • by az1324 ( 458137 )

        I'm sure you could get a token revoked with an e-mail to Tesla. The API is not intended for use by third parties so really the only valid criticism here is "Tesla does not have a 3rd party API".

        • by Zalbik ( 308903 )

          The API is not intended for use by third parties so really the only valid criticism here is "Tesla does not have a 3rd party API".

          I don't get it (and I did RTFA which didn't help much).

          It looks like this API is the API for third-party Android and iOS apps to use.

          In order for those apps to log in, the user must provide the app with their Tesla motors username/password.

          That isn't good security. Tesla shouldn't trust that every third-party is handling credentials properly.

          Am I missing something?

        • The API is not intended for use by third parties so really the only valid criticism here is "Tesla does not have a 3rd party API".

          Agreed. The only way to exploit this security issue is if you give your login credentials to an unauthorized website using a private API. If you do that, shame on you!

    • by Meski ( 774546 )
      "All hands, brace for impact!"
  • by Anonymous Coward

    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.

  • by Anonymous Coward

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

  • Major fail for Tesla (Score:5, Interesting)

    by RobinH ( 124750 ) on Tuesday August 27, 2013 @02:21PM (#44689447) Homepage
    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.
    • by Stainless_Steel_Mous ( 1130169 ) on Tuesday August 27, 2013 @02:34PM (#44689585) Homepage
      Classic failure mode for companies that do not primarily write software, bur use software in their products. We are seeing more and more of the continued use of security through obscurity followed by goggle-eyed amazement that haxors would figure out a way to penetrate the systems of the device/vehicle/airplane/whatever, finally ending in lawsuits to attempt to hide the existence of grotesque security failures. I cannot wait for the first corporation to be sued for insecure product design.
      • by DuckDodgers ( 541817 ) <(moc.oohay) (ta) (flow_eht_fo_repeek)> on Tuesday August 27, 2013 @02:58PM (#44689881)
        Even for companies that primarily write software, it's easy to design something that looks secure to you but in fact is trivial to defeat. WEP wireless security is inherently flawed. PPTP VPNs from Microsoft are inherently flawed, though not as badly as WEP, and Microsoft has deprecated the entire protocol. WPS wireless easy setup is flawed. The AES encryption used by Megaupload in their re-launch earlier this year was not implemented properly, and thus is useless.

        The history of computing is littered with flawed attempts at designing new security protocols. As far as I can tell, the best practice is to adopt an existing open source technology that is well proven. If you're trying to do something new, you probably need to spend an unholy fortune on multiple independent audits of the system, as well as inviting people on security mailing lists to examine it, and possibly offering a bounty for discovered flaws.
        • by DarkOx ( 621550 )

          WEP was never designed to be "secure" it was designed to be inexpensive so low (compute) power devices could use it. It stands for "Wired Equivalent Privacy" which is not very private. Passively tapping your UTP Ethernet segment isn't exactly hard. All WEP was ever expected to do was discourage the causal snoop; a lock of honest people if you will.

          • TKIP modifies WEP to be secure, and TKIP runs on any hardware that can run WEP.

            WEP was designed to be secure, nobody would go through the trouble to invent a security protocol that they knew could be defeated by commodity hardware in under an hour. WEP was just designed poorly.
            • by DarkOx ( 621550 )

              That is silly. There was never a need for a fully secure 802.11 specific solution. From the outset anyone who wanted that could just use IPSec tunneled or otherwise, either with 3DES or AES.

              That is what people were always advised to do; if they needed both privacy and to run a traditionally clear text protocol over wifi. I have been part of Enterprise wifi deployment in one way or another since 802.11 because a standard and at no point did even any of the vendors attempt to pass WEP off as doing anything

              • For home computer users, it's far easier for someone wanting to listen to your internal network traffic to crack WEP than physically tap into your cat5 cables somewhere in the house. Listening in wirelessly takes a laptop in a car outside the home, listening to the wired network requires at a minimum a physical home invasion - obviously the person can tap your phone, coaxial cable, or fiber connection between the provider and your house, but that doesn't give them the same internal network access as physi
    • I would assume Tesla's API to be better than industry standard before I took George's opinion.
    • by pavera ( 320634 )

      The problem with the article and the sentiment you express is that this api is *not* a third party api. It is not published, it is not intended for use by third parties. Oauth is a PITA. Why would tesla setup Oauth between themselves and... themselves?

      Oauth is designed to work between 3 parties, the user, the "authenticator", and a third party app that wants to access the authenticated service on behalf of the user. In this case, tesla implemented an API for their app to communicate with, so there is no

    • by bentcd ( 690786 )

      The article doesn't describe a security flaw with Tesla's API. What it does is complain about how Tesla doesn't provide a reasonable framework for allowing third party apps access to the car. Which is probably correct: Tesla never promised this and never intended to deliver it at this point in time.

      The API that is provided is a proprietary one that is intended only for communication between the car and Tesla's own app. It has a perfectly fine password-based security implementation for which the article does

  • by Doug Otto ( 2821601 ) on Tuesday August 27, 2013 @02:23PM (#44689477)
    "I can also honk their horns, flash their lights, and open and close the sunroof."

    So he discovered a 10 year old?
  • I can also honk their horns, flash their lights, and open and close the sunroof.

    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

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

  • Seems Trollish (Score:5, Insightful)

    by sl4shd0rk ( 755837 ) on Tuesday August 27, 2013 @03:05PM (#44689955)

    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 [huffingtonpost.com] to falsified reviews in The New York Times [time.com]. 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.

    • Re: #1
      What has logging in over SSL got to do with anything?

      If a third-party is storing credentials that control everything, then you are screwed if that third-party is compromised. Twitter suffered greatly from these kinds of problems prior to adopting OAuth. The trick with OAuth is that the third-party never sees the primary credentials, just an application-specific set of credentials with very specific access rights. Because of the design of OAuth, it's also easy to revoke credentials on an app-by-app bas

  • ...are doomed to so so in a way that is somewhat less secure but infinitely more usable.

    • When done right, OAuth is more secure and equally usable.

      Usability issues crop up when OAuth is applied to contexts in which it makes no sense (systemsystem authentication).

      • by pavera ( 320634 )

        Well, I'd argue this is one such context. There is no third party, Tesla's API is not designed for third party access, its designed for Tesla app -> Tesla API communication. Adding Oauth to this workflow, just for kicks, certainly would decrease usability, as you'd get redirected to a third Tesla page, to provide your credentials and generate a token for Tesla's own app.... The facebook and twitter apps published *by those companies* don't use oauth, they ask directly for your username/password

        Saying T

    • by pavera ( 320634 )

      Tesla wasn't even trying to re-create Oauth, they *don't* provide third party api access. They implemented a perfectly reasonable first party api authentication mechanism. If users are inclined to give their creds to *unauthorized* third party apps then that is on the user.

      Every API in the world shouldn't be *required* to provide third party access.

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

    • by Nemyst ( 1383049 )
      It can be closed and the documentation sealed in a titanium safe stored inside a reinforced container dropped at the bottom of the Mariana Trench for all I care; if the API is active in production models, it's going to get discovered and exploited. Nefarious usage, especially, won't be stopped by "Hey, you're not supposed to use this!"

      There really is no excuse for this. It's just sloppy security practices.
      • It can be closed and the documentation sealed in a titanium safe stored inside a reinforced container dropped at the bottom of the Mariana Trench for all I care; if the API is active in production models, it's going to get discovered and exploited. Nefarious usage, especially, won't be stopped by "Hey, you're not supposed to use this!"

        There really is no excuse for this. It's just sloppy security practices.

        I'm not trying to excuse anything, simply pointing out that this exploit can only be executed with the end-user as a willing, active participant. Please, show me a security model that works in that scenario.

      • by pavera ( 320634 )

        How is it sloppy security practice? You're seriously arguing that *every* *single* *api* on the internet *must* implement oauth right now because the api *will* be reverse engineered and users will be tricked into providing their credentials directly to a third party? Even when third party apps are not authorized? Every company with an api on the net *must* provide for third party access?

        Oauth doesn't provide any security anyway. Users will still be tricked into providing their credentials directly to t

  • 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?

    • 1. Only if there is a vulnerable third-party site with whom the user has shared their credentials. Out of the box, no.

      2. I would consider that a flaw in the car if you could do that. The API and the fact it resulted from a hack would be incidental to the whole thing.

  • by Luthair ( 847766 ) on Tuesday August 27, 2013 @03:41PM (#44690375)

    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.

    • by Zalbik ( 308903 )

      The article is mostly FUD.

      Not really. I believe the author's biggest beef is that the user should not be providing the app with their credentials to Tesla Motors.

      This is true, and with OAuth they don't have to. All the third-party app get's is an access token. The access token can have completely different rights than the user account, and can be revoked /controlled by the user.

      You can use OAuth for mobile/desktop access, it's just not as seamless as it is on the web. Here's a post that has some oth

      • by Luthair ( 847766 )

        Not really. I believe the author's biggest beef is that the user should not be providing the app with their credentials to Tesla Motors.

        And I'm not arguing against that, the problem is that the suggestion of OAuth is moronic. The very same article you're linking conveniently also explains what I stated - to write a desktop application with OAuth the user must enter the username and password in the application. This entirely negates not trusting a third party with authentication, also known as the entire point of OAuth. (Though the article's author argues that the point is moot as a user is inherently trusting an application they install

      • by pavera ( 320634 )

        The problem with the article is there are *no* authorized third party apps that use this API. Tesla does not provide third party access.

        People have reverse engineered the api, and then if you give these third parties your credentials, they can make calls to the api and do things to your car. The article is arguing that *any* API that is exposed on the net *must* implement oath so that third parties can use it. Seems pretty crazy to argue that any api exposed to the internet must implement third party app

        • by dkf ( 304284 )

          The article is arguing that *any* API that is exposed on the net *must* implement oath so that third parties can use it. Seems pretty crazy to argue that any api exposed to the internet must implement third party app access.

          It's also crazy to claim that OAuth is the only mechanism for doing it. There are others that are stronger, though more of a PITA; we were doing secure third party service access by other mechanisms (there are a few variations based on client-authenticated SSL with security assertions) 10 years ago, and that expertise still exists. The good thing about OAuth is that it works very easily with browsers and is relatively simple for simple websites to support, but if there are no browsers or it's not a simple c

  • 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 ?

  • 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 [gbiv.com] 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 con

    • I remember reading Fielding's blogs and work when REST was becoming a popular term. The idea of hypertext links was not as prevelent. It was there with some mention to atom rss and the likes, but it wasn't the main point of REST.
      There are some that think any stateless json/http webservice means rest. There are some that think anything with resources and actions on those resources is restful (ie: an sql select statement or your webservice example). And then there are those that follow R. Fieldings work a

      • by Bogtha ( 906264 )

        I remember reading Fielding's blogs and work when REST was becoming a popular term. The idea of hypertext links was not as prevelent. It was there with some mention to atom rss and the likes, but it wasn't the main point of REST.

        Hypermedia as the engine of application state is listed as one of the four fundamental constraints of REST in his thesis. It's a central part of REST. It wasn't retrofitted later. If you missed it, you weren't paying attention. REST is essentially a description of the archi

        • I understand what they mean. Multiple business partners use the term. This isn't just "the people that work next to me". This is my observation among web developers across the board. I'm talking about all the big players, they use the term wrong. While I can applaud people for having concise definitions, I'm not about to tell all the third party APIs I use daily that their REST api's aren't REST. It's too much work. If you campaign to get everyone to use the term correctly, more power to you.

          (PS - I

          • by Bogtha ( 906264 )

            This isn't just "the people that work next to me".

            I'm not about to tell all the third party APIs I use daily that their REST api's aren't REST. It's too much work.

            Here is what you originally said:

            When I hear a colleague say REST it usually means what you have in your example. So much so, that it would take to much time and effort to correct everyone.

            We weren't talking about the whole world fucking up, we were talking about your colleagues not knowing what they were talking about. To which my r

            • I don't feel like we are communicating well. What are you trying to tell me? I am talking about years after he published his Thesis. I'm talking about 2004 or so, when it became the fad to start calling things RESTful. At that time if you did a google for "REST" you would get a webpage from Fielding. That's what I found at the time and went with until I researched it more. And, no, I don't put effort into correcting people on this topic. You seem to think it warrants correcting people, I don't. Word

              • by Bogtha ( 906264 )

                The point you were trying to make is that links being important is actually something that came later, and you tried to argue this point by saying you read his early work and blogs and it wasn't mentioned.

                I am pointing out that it was a central theme right from day one. It was mentioned in his thesis published in 2000, and it's also ludicrous once you recognise the fact that REST is a description of the architecture of the WWW, which clearly revolves around links. It's not plausible that you could ever

  • I don't get it...at all. The article "bashes" the security, but makes no suggestions or recommendations how to improve it. And frankly, I see no problem. It see it as a "minor issue" that you need to use SSL encryption.

    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 ente

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.

Working...