Forums

Join The Community
RegisterLogin

Flaws in REST API Authentication

I wrote up a critique of the authentication model in the Tesla REST API: https://plus.google.com/118015857958369316512/posts/URd647tAEsD

The troll hunters will hate it, I'm sure.

GReese,

You do know that the driver can turn off remote access at anytime from the car.

I agree with you that security should always be top concern.

Change your password monthly.

@Greese - My next comment is really not intended as an insult, so please don't take it that way, I'm just pointing out a flaw in your response to chrisdl.

There are a lot of people who write about things for a living who don't seem to have a clue what they're talking about. John Petersen comes to mind re: investing. I also recently read a book of essays by Bruce Schneier the security 'expert', which revealed to me that his status as an 'expert' is, at best, questionable.

So stating the fact that you write about something for a living is not all that convincing.

Private APIs have been around since the dawn of computing. I find it strangely cute that someone who purports to write about APIs doesn't know this.

As far as I can tell from this thread there is no security problem with the Tesla API, the security problem only arises if Model S owners start sharing their passwords with random strangers on the internet. Also, grass is still green.

GReese, thank you for the research and pointing this out. as the things you can do over the API right now are minor they might have not taken the apisecurity too serious and made something simple.

However this concept is obviously very weak and if you don't have the knowledge / Time / Money to do something, you have to use the most important software development skill of all... copy & paste :)

There are a lot of people who write about things for a living who don't seem to have a clue what they're talking about.

Yes. My point was not to say that my being a writer about APIs was in itself proof, but to arm people who want to judge with the information on which to look and see on their own if I know what I am talking about.

I am pretty sure my credentials speak for themselves on this matter.

Bruce Schneier is a security expert. He's very smart, especially when it comes to understanding human factors.

He doesn't do cloud security that well though.

Private APIs have been around since the dawn of computing.

The REST world is very different from your Win32 APIs.

I responded on your G+ post, but basically I don't see a problem with it as it is - yes, it would be nice if they used OAuth (heck, I would even like 2FA for a web site that gave OAuth tokens), but this was never intended to be used outside of their mobile app. They have and will continue to break apps that are built on it (I have been using it since the mobile app was introduced, and my app has been broken twice). People shouldn't be giving their credentials to third parties in any case, so all of the attacks that follow from that are just because people are being stupid.

@jat@jaet.org

I just don't buy the "private API" argument. In the world of the Internet of Things, there's no such thing as a private API.

And, as I noted above, the authentication mechanism is just dumb even if they could control the privacy of the API.

But the reality is they can't control the privacy of the API and there are already very useful 3rd-party tools on the Internet. Those will only increase.

I happen to know George professionally, and he can certainly defend himself, but some of you guys should really take 30 sec to check out Google or LinkedIn before calling into question someone's credibility on a topic.

The excuse that the APIs were never meant to be public is, at best, making excuses for Tesla. That's like saying I don't need locks on my doors because my couch and TV are not meant to be public either.

REST APIs will be discovered and reverse engineered, sites like Tripography or the 51 page thread over on the other Tesla site are proof of that. Its what geeks do for fun. Nothing necessarily malicious about it, its just the way things are. The APIs will (or will let) Tesla do some cool things, but the concept also carries some inherent risks which www should expect Tesla to manage.

The problem is that security always ends up being an afterthought. Devs will hack something together, which inevitably falls over at some point (often very publicly) and they are left duct taping some bigger hack in place.

If we stick to the house analogy, its easier and cheaper to pre-drill for deadbolts and pre-wire for an alarm while the house is being framed than it is after you have moved in.

I think that was George's point--put in something robust and scalable now while things are just getting started, rather than being forced to do it later when it will certainly be more expensive and may still not work as well as it should.

Omar

@GReese "There is no such thing as a private API"
Huh? That doesn't parse. My company builds and uses many private REST API's to have various software components talk to each other, within our product. REST is a nice standard way to communicate but of the 5-6 Restful API's in our main product, only one is public.

You've got your 15 minutes of fame, looks like:
http://www.forbes.com/sites/reuvencohen/2013/08/22/newly-discovered-flaw...

First, congratulations, this issue has made national news and was quoted unattributed and out of context. Bah! Journalists trying to get a FAIL story on Tesla. But that doesn't mean it shouldn't have been written -- it's factually correct insofar as it warns of a set of specific actions that might compromise the security of a limited number of features (also disclosed in the original writeup).

That said, there is a certain amount of "don't take candy from strangers" implicit in the cited security vulnerability. If I opt not to give my credentials to value-added tools, the Tesla and it's mobile app will function with no security vulnerability. That's what I did -- I don't give out original login information to anyone but a trusted certifying authority. And by making that choice, I've denied myself use of some value-add sites. Sigh.

But I don't take candy from strangers. Even though there is a perfectly good technological solution to this, there is also an element of personal responsibility involved as well.

Why I'm posting this is not to make a feeble attempt to discredit @greese's argument because it is correct. However, characterizing "the safest car in the world" as easily hackable is fodder for an out of context negative news bite that does not understand nor contemplate the extent, seriousness or personal choices involved exposing this. My $.02

@GReese, your Auth points are very pertinent if this API is ever to made public, I'm not disputing that at all.

You've got your 15 minutes of fame, looks like

This isn't my 15 minutes of fame. If you think this is about fame, you need to follow me on Twitter. I do this shit all the time. Ask the OpenStack or vCloud teams in cloud computing.

I live and breathe APIs. And I've had more fame than this.

Omar, thank you for explaining my original reply about security in APIs more clearly (and with more words).

About George's credibility: George provoked on purpose by saying that private APIs don't exist, while he very well knows that they do. What he meant to say is that private APIs on the internet don't exist. Even that is arguable. Tech writers know that they have to be precise in what they write, so that there can be no wrong interpretation. George writes technology books and blogs. Next, George provoked again by telling bent about "[bent's] Win32 APIs". Hence, George's credibility is still down by 3. He's lucky it's not down by more or he'll have to appear in front of the credibility commission soon! ;-)

Yeah, as expected, the publicity around this will focus on the wrong thing -- what people should get is that they shouldn't be giving their credentials to third parties, instead you get people who don't know anything but have lots of readers to say "OMG, there is a flaw!".

There isn't any security flaw - it just doesn't do what you want, which is safely allow third party access. It wasn't designed to do that, so no problem, don't use it for that.

what people should get is that they shouldn't be giving their credentials to third parties

This is most definitely NOT the moral of the story.

A good API isn't usable with end-user credentials. Period. And it's not hard to do.

The moral of the story is that when you are building a connected device, you should think about the security of your API first. It's not about Tesla. It's not about giving your credentials to third parties.

All APIs get used well beyond the initial use cases. Bad ones break or create issues when that happens.

A good API isn't usable with end-user credentials.

I can think of:
OAuth (which requires end-user credentials to approve each client)
PKI (which quickly becomes a hideous mess)

Could you quickly sum up some other of the most prominent alternatives?

So, lets be clear, a "private" API only means that its not documented. This might be for any number of reasons like its functionality that the owner does not want to expose to 3rd parties or that it might simply not be ready for prime time yet or they might expect the API to change and don't want devs wasting time coding against the old API.

But you can generally still make calls to private APIs if you find out about them, they depended on security by obscurity. Apple is the poster child for this--they have myriad private APIs that you can still code against--and will get your app bounced if you want to sell through the app store.

O

The excuse that the APIs were never meant to be public is, at best, making excuses for Tesla. That's like saying I don't need locks on my doors because my couch and TV are not meant to be public either.

That is a completely erroneous analogy. It's not that Tesla's APIs are unprotected, it is that they are protected in a non-GReese-compliant manner. Which isn't a problem for anyone other that GReese.

The APIs in question are private APIs because they were never intended for access by third parties, not because third parties can't access them if they try really hard. And third parties that do try to use them won't get any access to the car anyway so it's not a security issue. It only becomes a security issue when car owners start passing their passwords around to strangers, for which I can only say, don't do that!

This is the poster child of a PEBKAC issue. Replace user and try again.

Maybe in the future sometime Tesla will provide third-party accessible APIs. They don't today and as far as I know never pretended that they do.

@jat -- @GReese does have completely valid points. His writeup was thoughtful and his defenses well crafted. I have no quarrel with what he's said and I believe it adds value. I also think you're correct in saying what people should get is that they shouldn't be giving their credentials to third parties but the problem with that statement is that directing people's take-aways is almost always the next best thing to suicide.

People read what they want into what you write and hear what they want in what you say. What @GReese said, if I understand correctly, is that there is a potential exploit affecting a constrained set of cases in the event a user takes certain actions (providing their credentials to someone other than Tesla). @GReese, correct me if I'm wrong on this.

In no case is question the credentials of the poster a good idea. That won't make a problem go away if one exists and it sure won't solve one.

sxross: "In no case is question the credentials of the poster a good idea."

I didn't get that. Could you rephrase it, please? Thanks.

I meant that questioning @GReese's veracity a productive way to move the subject forward.

One common thread in all subjects technical is when a person voices an unpopular opinion (and we all love our Teslas, so we don't really want to hear anything negative), the first instinct is to try to undercut the credibility of the person putting forth the initial issue.

For reference here's a news story that picks the post up:

http: www dot forbes dot com/sites/reuvencohen/2013/08/22/newly-discovered-flaw-may-open-the-tesla-model-s-to-potential-attack-from-hackers/

The headline screams:

Newly Discovered Flaw May Open The Tesla Model S To Potential Attack From Hackers

@omar
"But you can generally still make calls to private APIs if you find out about them, they depended on security by obscurity."

Or other security, no?

Let me try an example. Let's say I have a server sitting in the cloud. It is accessible only on port 443 and has an outward facing ReSTful public API and possibly a UI. Once the client initiates an action via the Public API (say with curl or wget via HTTPS), perhaps I have ComponentA, internal to the application, which is accessible via a ReSTful private API on port 8080 which is not a port open to outside world, and supporting actions are performed by ComponentA. A return is sent to the client on 443.

@omar
"So, lets be clear, a "private" API only means that its not documented."

I have to disagree. Good software engineers document well, including private API's.

@sxross: Did you maybe mean "non-productive" :)

O

If this API is not for third party or public use, why does any of this matter?

I think that Forbes should be thoroughly embarassed for using an unmoderated public posting forum as a source for an article.

They should be shamed for referencing a post without the author's permission as well.

What happened to journalism? This is truly pathetic.

@omarsultan: Yes. My sloppiness is pathetic. So sorry.

@Captain_Zap: This is expected behavior. The press has become not just lazy but downright aggressive about using unattributed information.

sxross
Absolutely, as I said in my first reply, GReese has excellent points.

However, that has nothing to do with somebody looking the fool when they say that private APIs don't exist. If you have GReese's portfolio, you would expect a bit more than provocation and trickery to get your point across, right?

Or maybe I'm the fool and I should do exactly what George does, to get my points across.

I'm not a troll, I'm not a troll hunter, I have ordered my Tesla only last week and I'm famously not married to any car brand, least of all Tesla. However, you have to be realistic, and GReese is not.

I've built systems exactly of the type Tesla uses and I'm an advocate of pervasive security. You can make a system with Basic Auth which is perfectly secure.

There's nothing, nothing at all, that can stop user stupidity. Not even OAuth or a full PKI security system.

@NKYTA:

re: documentation: I would hope so :) By "undocumented", I meant released to 3rd parties.

So, APIs are not inherently pubic or private. In your example, you are using network policy to restrict access to the second API (port 8080), but it is not inherently protected otherwise unless you have implemented something like authentication at a higher layer, but again, the API is wide open. If your network controls get compromised then folks would have free access to the second API. The same is true of the first API (port 443), their is nothing inherently public about it, other than there are no network access restrictions to it and developers know about it because you have a) documented and published it or b) they have discovered it by themselves.

O

Tesla's private API is password protected and so is not "wide open" by any stretch of the imagination. The only known way to compromise it is by tricking the owner into giving you his password. This isn't a flaw in the software, it would be a flaw in the owner.


X Deutschland Site Besuchen