Authentication flaws in the REST API (if you give 3rd party your private login info)

[S-19910]

pfff, don't feed the trolls.

 

[markwj]

You're one of a few people then. Many (most?) people who looked at the famous Sony rootkit blamed Microsoft for allowing this in the first place. Perception is unfortunately everything. Whether that web site that they accessed uses some vulnerability in Flash, all that happens is people think Windows is broken.

I think in the security industry I work in, my view is the accepted one, and the majority.

I'll try one more time to explain the difference. Please read what I said carefully:

If they had a private API intended for one purpose, and third parties re-purpose that API for another purpose it was not suitable for, then something got exploited by the third party use that would not be exploitable with the original use, then I would neither call the API flawed for its original purpose, nor hold Microsoft accountable.

For Microsoft to not be accountable, (a) the API must work fine for its original purpose, and (b) someone unauthorized must re-purpose it for some other use that introduces this new vulnerability not present in the original use. That is the line that is drawn.

In the case of a straightforward Microsoft API (public or private), if a hacker exploits a vulnerability in that API in normal use, then Microsoft is accountable. If someone takes a Microsoft API and uses it for something different that introduces new flaws that were not present in the original use case, then I would not hold Microsoft accountable.

In the case of the Tesla API, Tesla designed it for Tesla Apps to talk to Tesla servers, and both authorizes and supports it as such. None of the identified flaws affect the API in that use case.

Now, others have MITM reverse engineered the API and are now using it for purposes not originally intended. These new purposes (third party Apps and web services) introduce grave security concerns and when used in that way, the API is flawed - or to put it another way, plainly not suitable. Nothing new here, we've been discussing this here for months, and whenever someone announces a new service based on this API, we all chime in with warnings. Caveat emptor.

Bottom line: To me, it comes down to the simple fact that using this API, for the purpose it was designed for, is secure (or at least not vulnerable to these flaws identified).

Regarding the more philosophical point of view of whether Tesla should have designed it this way, I would have hoped that Tesla would have had an API published and suitable for third party Apps and services by now. It would clearly be unacceptable for such an API to use the same authentication mechanism as this private one. Similarly for the apps on the 17" display. I believe that would be the best for Tesla, the community, and the product. But creating such an open ecosystem is certainly non-trivial, not least from a legal and support point of view, so I understand that Tesla may need some time to release this in a secure and supported way.

I really cannot write it clearer than that. This horse has truly been beaten to death. Perhaps all we can agree is to disagree and move on.

 

[Jason S]

Two things:

#1 Tesla should have a software engineering team that basically works on things like the API and the mobile apps. This is not some huge drain in resources.

#2 Handing out credentials to third-party sites to leverage an API is not stupid. Having an API that puts people at risk when they do so is stupid.

#2 is my biggest problem with the arguments so far.

Tesla produced apps. The apps were/are secure. Some folks figured out what the apps were doing and engineered their own apps.

So Tesla is at fault because the apps weren't so secure that an API couldn't be derived? It should've used encrypted communications that couldn't be tapped even by the customer? Are they at fault because rather than releasing an open API, they instead released an API that could be reverse engineered?

Tesla did #1; team that made mobile apps. Application users did #2; handed out creds to 3rd party sites. ... Tesla is at fault for the 3rd party app users?

 

[nspollution]

#2 is my biggest problem with the arguments so far.

Tesla produced apps. The apps were/are secure. Some folks figured out what the apps were doing and engineered their own apps.

So Tesla is at fault because the apps weren't so secure that an API couldn't be derived? It should've used encrypted communications that couldn't be tapped even by the customer? Are they at fault because rather than releasing an open API, they instead released an API that could be reverse engineered?

Tesla did #1; team that made mobile apps. Application users did #2; handed out creds to 3rd party sites. ... Tesla is at fault for the 3rd party app users?

Tesla is blameworthy here because, instead of following industry best practices in the way they handled API authentication, they made up their own scheme that makes support for third-parties weak.

 

[NigelM]

This morning I'm talking to my wife and mentioned this subject and she had a whole new take on it. This is the gist of the conversation:


Mrs: These guys are hacking into the Tesla system and creating their own apps?
Me: Umm, basically yes.
Mrs: Isn't Tesla paying for those communications to the car?
Me: Yes.....
Mrs: So isn't that like stealing and then complaining that the bank made it too difficult?


Ouch.

 

[Matt_D]

Look at Twitter, for example (and hardly a shining beacon of security). Let's say you use HootSuite. HootSuite is hacked. You go into your Twitter account and revoke HootSuite's authorization. Done. All in your hands, no impact to all the other tools that need to interact with Twitter.

Personally, I would like to see two-factor authentication for all API access per device/system and token revocation -- all part of My Tesla. It would be a huge security improvement, and I think a necessity for large fleet management. (And, I think it would harden the overall security of the ecosystem as well.)

 

[Johan]

This morning I'm talking to my wife and mentioned this subject and she had a whole new take on it. This is the gist of the conversation:


Mrs: These guys are hacking into the Tesla system and creating their own apps?
Me: Umm, basically yes.
Mrs: Isn't Tesla paying for those communications to the car?
Me: Yes.....
Mrs: So isn't that like stealing and then complaining that the bank made it too difficult?


Ouch.

Made me think of this, which is NOT an urban legend:

The burglar and the skylight: another debunking that isnt - Overlawyered

 

[deonb]

I think in the security industry I work in, my view is the accepted one, and the majority.

Would you agree that the majority of the people in the world do not work in the security industry though?

In the case of a straightforward Microsoft API (public or private), if a hacker exploits a vulnerability in that API in normal use, then Microsoft is accountable. If someone takes a Microsoft API and uses it for something different that introduces new flaws that were not present in the original use case, then I would not hold Microsoft accountable.

Every Trojan in the world uses an API in a way that's not part of the original use case!

I think you're mixing a buffer overrun style attack on legit software with the ability to create malware using an API.

We don't have definitions of "normal use" vs. "abnormal use" in API design, and I doubt anybody else does either. You have to assume everything out there tries to DOS, EOP, MiTM, Key attack the API. Besides, sometimes a badly written piece of well intentional code can wreck more havoc than a well written virus. So you have to defend against everything anyway.

But maybe next time when we have a large Trojan, we'll just publish: "Oh, Slammer 2.0 wasn't using SQL in a way that we designed - so don't worry about it.".

Bottom line: To me, it comes down to the simple fact that using this API, for the purpose it was designed for, is secure (or at least not vulnerable to these flaws identified).

The API is not secure. Tesla APP's are secure. But the security model of the API is simply based on "There can only be Tesla apps", but that stopped being true a while ago.

 

[aviators99]

Every Trojan in the world uses an API in a way that's not part of the original use case!

That's a pretty broad (and untrue) generalization. And again, you are comparing public APIs to private ones.

I think you're mixing a buffer overrun style attack on legit software with the ability to create malware using an API.

Most of the MS malware API attacks are indeed buffer overruns. But again, this is not an API in the sense of the Microsoft APIs, which are all meant to be used by 3rd parties.

We don't have definitions of "normal use" vs. "abnormal use" in API design, and I doubt anybody else does either. You have to assume everything out there tries to DOS, EOP, MiTM, Key attack the API. Besides, sometimes a badly written piece of well intentional code can wreck more havoc than a well written virus. So you have to defend against everything anyway.

That's good.

But maybe next time when we have a large Trojan, we'll just publish: "Oh, Slammer 2.0 wasn't using SQL in a way that we designed - so don't worry about it.".

Horrible example. The API you are referring to is a public API. You claim there's no difference. If so, give me an example that is for a private API (and not one that MS made public by accident).

The API is not secure. Tesla APP's are secure. But the security model of the API is simply based on "There can only be Tesla apps", but that stopped being true a while ago.

The security model of API is based on the fact that if someone wants security, they should only use the Tesla apps; not that there can only be Tesla apps. If someone is stupid enough to use a 3rd party app (like mine) without waiting for the SDK, caveat emptor.

 

[markwj]

Would you agree that the majority of the people in the world do not work in the security industry though?

Correct, which is why they come to experts for assistance in such matters.

Every Trojan in the world uses an API in a way that's not part of the original use case!

Oh, good grief. At this point, I can only conclude that you must be deliberately missing the point.

What you are talking about is the exploit of an API in a way not originally intended, by a hacker. Fine, but irrelevant. Nobody has exploited this API in that way.

This is the use of an API in a way not originally intended, by a third party, that creates flaws to be exploited by a hacker. Tesla's API is for Tesla's Apps to talk to Tesla's server, and in that use case supported and authorised by Tesla, these 'flaws' do not exist.

Flossing with razor blades. I'm done.

 

[AnOutsider]

So it spreads: Tesla Model S vulnerable to hackers? - Autoblog

 

[markwj]

So it spreads: Tesla Model S vulnerable to hackers? - Autoblog

Again, they've missed the whole 'third party' part of the issue to go for the sexy headline. Good grief.

Meanwhile, we sit here:

 

[NigelM]

Again, they've missed the whole 'third party' part of the issue to go for the sexy headline. Good grief.

Well they got the story from Forbes: newly-discovered-flaw-may-open-the-tesla-model-s-to-potential-attack-from-hackers/

 

[brianman]

Sadly, I expect them to shut it down before 2014 because of the way your concerns were raised.

You think it's going to take that long?

I was being optimistic. Also, I figure "before 2014" is "soon" in Tesla terminology.

- - - Updated - - -

Advertising something and then not providing it after it's sold is not illegal?

Pano shade?

- - - Updated - - -

Fair enough. It's an honest philosophical difference. I realize that I sound like Commander Adama when I say I don't believe systems should be connected or networked.

Props for the reference.

 

[NigelM]

More press:

Tesla Motors Inc (TSLA) Model S Vulnerable To Hacking: Dell Exec

Tesla Model S Could Be Hacked

 

[nspollution]

More press:

Tesla Motors Inc (TSLA) Model S Vulnerable To Hacking: Dell Exec

Tesla Model S Could Be Hacked

The former is more aligned with my thinking, though the title isn't (I specifically have noted many times that there is no vulnerability; flaw != vulnerability).

Although it's odd they elected to refer to me as a "Dell Exec". I am most obviously NOT writing in my capacity as a Dell executive, but as an author and expert in REST API design (why it was published to the O'Reilly blog instead of the Dell blog).

 

[AnOutsider]

The former is more aligned with my thinking, though the title isn't (I specifically have noted many times that there is no vulnerability; flaw != vulnerability).

Although it's odd they elected to refer to me as a "Dell Exec". I am most obviously NOT writing in my capacity as a Dell executive, but as an author and expert in REST API design (why it was published to the O'Reilly blog instead of the Dell blog).

These articles are only doing what you did: taking info and sensationalizing it. They don't bother to fact check. They don't bother to get it right. They go for the juicy headline and run as far as they can while doing the least amount of work. This was inevitable. It's one reason why so many took issue with your original thread title and article to begin with.

 

[NigelM]

This one's a doozy:

Tesla Model S potentially vulnerable to hack attempts: Report

George Reese, Executive Director, Cloud Management at Dell, explains the threat - a flaw in the security of the API, that will allow for partial remote control of the car. Reese himself is a Model S owner.

 

[dsm363]

If there is an issue, you could have done much more good by contacting Tesla and attempting to address your issues with them than a blog post.

 

[NigelM]

@nspollution: you're now famous in Holland= Tesla Model S Easy To Hack and also in France= The Tesla Model S can be hacked