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....I am not making any judgement on this issue you raised...you may be accurate, semi-accurate or completely off base. If there is a problem it should be addressed. If you are semi-accurate, it should also be noted you are blowing the issue by some degree. But I will leave it to those in the computer field to the make proper assessment.....

First of all you came in here expecting "troll hunters", which by the way you are by hunting for trolls. Update slang.

I don't know how many ways to say that it's hard to be impressed when you want so bad for us to think it's a popping fresh idea. My mom literally brought up the same issue because the same thing happened. Software is a meritocracy. Being king of a fad will get you trend followers.

Your highly thoughtful Forbes readers agree, right?
http://www.forbes.com/sites/reuvencohen/2013/08/22/newly-discovered-flaw...

Very similar idea to this article posted August 3rd
http://www.digitaltrends.com/cars/can-your-car-be-hacked-car-hacking-thr...

Compared to yours on August 21st
http://broadcast.oreilly.com/2013/08/authentication-flaws-in-the-tesla-m...

Similarities arise. Here's an interesting piece from yours:

"As noted above, the impact of any of these very real attack vectors is pretty much economic. 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 surprising and distracting while someone is driving."

I'll let your reviewers grade your ability to actually do one of those things. I just like how you totally qualify for Fox News and write for O'Reilly. Similarities arise.

the same thing happened to another EV*

Were I a developer on the Tesla team, my response would be:

(1) Log a short-term higher priority bug to reduce token validity time.

(2) Log a longer-term medium priority bug to introduce new API, intended for public use, with an authentication mechanism that allows third party use without user password disclosure.

(3) Make sure business is communicating to customers never to use their password with third party apps.

(4) Ask developers to hold off on third party apps until new API is released (knowing that not all will).

I have been following this for a while. The crux of the matter seems to be:

1. Current Tesla API was not architected for third parties to access - which clearly bothers GReese
2. If a user gives his/her Tesla username and password to a third party today, they might expose themselves to attack. - which GReese points out.

I am not bothered so much by 1. I don't at all care if my devices can talk to one another. In fact I'd rather they don't. I am saying this as a digital design engineer for the last 16 years. We have always talked about the Internet of things. Anyone remember how our toilets were supposed to transmit the health status to the doctor directly whenever you did your business? This model does not work. If everything is to be connected, everything gets more complex, more prone to failures, more expensive to fix, and more prone to hackers. We don't need these to talk to one another, let them mind each others business silently, and yes, with a little more human effort.

Regarding 2: I understand there are "dumb" users who'd give their credentials to someone they don't know, after all, in their mind, their Tesla credentials are not exactly their bank account credentials (hopefully), so why worry?
Well, it turns out, there IS a valid reason to worry, thanks to the OP who pointed this out.

Maybe he was 'reaching' a bit with his title, may be even to get some limelight. Heck, I have fallen prey to that myself, especially when one discovers something like this. I think we should give credit for that, and move on.

My 2 dollars.

@GReese Have you actually tested to see if the tokens remain valid after changing your password on the web site? It seems that you are just asserting that they are valid for three months because the cookie duration is set to three months. It is entirely possible that the cookie is no longer valid on the server side after you change your password. It depends what is in the cookie and how they manage it.

@GReese Ok, I just did the experiment as can anyone else on this list -- I used the app on my iPhone then I went to the web site and changed my password. I went back to my iPhone and restarted that app. It worked at first, but after about a minute or so it suddenly brought me back to the login screen. Obviously something on the server side invalidated that token.

So, in summary - the API is fine for its intended purposes. Don't give you password to anyone and if you do just change your password.

@patn

I've seen mixed results on this issue.

By the way, even if the tokens reliably expired on the server after a password change, it doesn't alter the point of the article. It just minimizes one of the issues I pointed out.

Update on Token Expiration

It seems people are getting mixed results on token expiration. My best guess is that there's some caching thing going on here.

I noted this in the article and its implications.

Basically, it means of the issues I have noted:

1. It cannot safely operate over any channel but a trusted SSL connection (minor)
2. It requires the sharing of the user's password with third-parties (major)
3. No mechanism exists for cataloging applications with active tokens (significant)
4. No mechanism exists for revoking the access of a compromised application (major)
5. The automated expiration of tokens in 3 months encourages applications to improperly store your email and password (significant)

#4 should be altered to be:

Only an inconsistent blunt-force mechanism exists for revoking access to a compromised application (moderate)

And actually, #5 should be updated to be:

5. The automated expiration of tokens in 3 months along with the blunt-force token revocation mechanism encourages applications to improperly store your email and password (significant)

I've updated the O'Reilly community piece for #4, but did not bother with #5, but that's all I control. I have notified the O'Reilly editors for the Programming piece.

I also posted this on your G+ post.
---

Ok, I just ran the test. I started my temperature data collection, which uses cached tokens and makes a request to climate_state every 10 seconds. After it started and asked me for my password (the previous token was no longer valid), I let it run for a bit. Then I went to My Tesla and changed my password. On the request 2:40 after the one before changing my password, it prompted me for my password again. A second trial resulted in a 2:20 delay.

When I did a similar test when I first reverse engineered the API, my recollection was that it was within 20 seconds. So, I could have been lucky before on a couple of tests (perhaps less load as there were few users at that time), or they could have added some latency -- for example, I wouldn't be surprised if they added an LDAP replica to cope with load, which would be consistent with increasing the latency before a token is invalidated. Even with increased latency, I think this is perfectly effective for revoking access from people you have given your password to.

I still think your statement over-reaches, as changing the password is no more blunt than what the user did in the first place -- they gave their password to a third party, so I would think even unsophisticated users would think changing their password would have the desired effect of revoking their access, which it does. Why should they expect a third-party program to behave differently than if they told you personally their password, and then changed it when they didn't want you to have access (knowing that also changed it for everyone else they had given their password to)? Or if they gave you a key to their house, and decided to rekey the lock because they didn't want you to have access any more?

Absolutely, I agree that it would be great if they used OAuth and allowed granular access control. I just don't see it as big a deal as others which have been doing exactly the same thing for a long time -- including mint.com, who asks you for your bank credentials but has the chutzpah to warn against giving your mint.com credentials to anyone. I think your valid complaint reduces to "They didn't use a mechanism that safely allows third-party access".

I think @GReese has done a great dis-service by being an alarmist for this minor issue. The average Joe reading his blog, or the Forbes article can’t tell if @GReese’s claimed risks are actual security flaws, or just a consequence of giving out a user’s password.

The solution is simple: Don’t give your password to strangers! End of the story.

His article and follow-up words raise questions about his motivation. It may be ego, or financial gain. For example, I am sure he wouldn’t mind, if as a result of all this publicity, he gets a job to redesign the Tesla mobile API. :-)

@jat: Your conclusion is fair enough, but not the whole store.

I would summarize it as: "They didn't use a mechanism that safely allows third-party access for an API that provides such useful functionality to Tesla owners that they are already sharing their username/password with third party developers frequently even though they know this is inherently unsafe."

The desire of Tesla owners for applications using the functionality of the API is legit. The motives of, lets say, all existing third parties that create those applications are legit. So that raises the interesting question: are those third parties (and the Tesla owners that create their "demand") wrong in using the API, which not "officially published" and clearly not designed for third party access? Or is Tesla wrong in having designed this API this way to begin with?

I would agree that the term "flawed" is too strong in that Tesla (obviously) didn't mean this API to be public. They were, however, naive in not recognizing the strong desire for it, and have to an extend even ignited the fire by referring to the Tesla as an "iPad on wheels" and emphasizing often that the fact that so much functionality could be added to this car via software is a game changer. It's a game changer in the automotive world for sure. But by 2013, it is common practice in many other area's. And it is what "early technology adopters", which many Tesla owners are, are very much used to.

The demand for a public API could have been foreseen, and it would not have been difficult at all to set the API up like that from the get-go. For IT architects that deal with designing future-proof APIs on a daily basis, it can be frustrating to see that a company that is such a technological front runner in so many ways, dropped the ball on this API like this. Especially when their CEO stood at the very roots of "internet security" (i.e. PayPal).

@sia: "A job to redesign the API"? The OP, (and yours truly, and thousands of others, including the current Tesla developers) could "redesign" it in an hour, implement it in a few days, have it tested and in production in a few weeks. After all, the API itself is fine, it is only the security model on top of it that needs to change. The fact that you suggest that there's "a job in it" indicates your level of experience with these matters.

@sia

I just sold my company and have quite enough on my hands. I'm not job hunting.

Also, if I were looking for exposure, I would have shopped the article to a forum with greater exposure and gotten paid for doing so.

I write about APIs for a living

I write APIs for a living. I trust TMC is taking security more seriously than GReese's critics. This particular security issue is not my concern. From reports of a particular application I suspect a SQL injection* vulnerability that can be exploited by anyone who has access to the touch screen (e.g. valet).

If it is a SQL injection vulnerability, it could be possible to gain root to the OS running this particular application. SQL injection is one of the most common means that hackers use to covertly invade servers.

I haven't tested to see if my Model S is vulnerable because I don't want to brick my car (highly unlikely but still...).

*see http://en.wikipedia.org/wiki/SQL_injection

S85 - Blue & tan, TP, AAS, VIN #136XX

I'm thinking I'm probably not running SQL.

@pebell: I have treated your comments with respect, but see that you cannot reciprocate. You have no idea about my background and expertise. Your responses are completely irrelevant, this time and last time you responded.

@Greese: Fair enough, I overstated that joke. But I wish you would correct the misconceptions that your article has created.

@jbunn,

I find it possible that an application that does searches runs MySQL.

@Rte66 - I would be extremely surprised that a) they are running SQL on an embedded system and b) they would pass unscrubbed data from the UI to it.

I'm sure they know about Little Bobby Tables :).

If you are worried about vulnerabilities in the car itself, I would be more concern about vulnerabilities in pieces they source from others that have been shown to have vulnerabilities -- for example TPMS receivers that blindly broadcast data received from the sensors in the tires to the CAN bus. Unless they want to start building their own processors for things like that, all they can do is select vendors who are careful themselves.


X Deutschland Site Besuchen