Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

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

This site may earn commission on affiliate links.
Ok, lets work in that direction for a while. How about we stand up an OAUTH server and document how we did it, just to demonstrate to Tesla how easy it is. This would make it easier for them to implement something similar.

This is a well-known problem. How they solve it is dependent on the languages they use and other aspects of their architecture into which I have zero visibility.

If they can't solve this quickly, they need to fire their entire API/mobile team.

- - - Updated - - -

No, no, and no. I don't give out copies of keys to my house to other parties. Why would I give someone keys to my bank account or brokerage.

The point really wasn't about *you* specifically, but to point out that there are A LOT of third-party banking apps out there and it's common-place today for people to connect different third-party software components. Doing so requires handing out some kind of authentication keys to those third-parties.

You may well not do that. But the rest of the world does. You are more secure by not doing it, but they have access to more capabilities by doing that.
 
One small point, even though the Tesla API doesn't have a required way for apps to identify themselves,
from the beginning I made sure my windowsphone app tells Tesla who it is and what version it is on all requests, so they have the option of selectively blocking me. (and have the ability to know how much traffic comes from my app vs others, etc)
 
Deonb, can't quote your long post. But two big issues identified:

1) 90% of Microsoft exploits are in private APIs.

Not sure where you get this. Can you provide a reference? This is not my experience, but maybe terminology getting in the way. P.S. I've got more than 30 years of experience in that field, with the last 13 as CTO of a network security company, and lead the security response teams with tens of thousands of networks under our management.

Our internal security training, as well as the breakdown of API bugs I fixed over the years. Part of this is that Windows internally is much more likely to call a private API than a public one, but it caused us to have to harden private and public API's just the same. So public API's generally had scrutiny on them to validate input, credentials, execution context etc. but private API's didn't go through this because it was assumed nobody could call them (well, years back).

Of course, malware needs access in the first place, which is gained through buffer overflow exploits, social engineering etc. This is the most widely publicized part of security vulnerabilities. However, after the malware has access, it needs elevation of privilege to do real damage. This is were API attacks come into play.


Anyway, the answer is yes I would hold Microsoft to the same. 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.

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.

If there is such an exploit, what is Tesla going to do? Say: "Oh, we created an API that we thought was secure and internal only, but someone has cracked it, and it's THAT thing they're using to exploit the car".

Short spin on that: "Tesla created an insecure API that they admitted was able to be cracked within a weekend. And you're trusting them to send you over the air firmware updates that can control your accelerator??".

Even a relatively benign hack of a Model S isn't going to go over well in it's current state.

Tesla SHOULD be able to say: "We designed this API really well so that you even an unscrupulous hacker can't do any real damage - go try your best. Free Model S to the first hacker that manages to damage a Tesla using the API". But at the moment all they can say is: "Well, you weren't supposed to be able to call this in the first place. Oops.". And therein lies the real problem.


2) Hacker website.

Using OAuth would have zero affect on that scenario.

The hacker would still collect the authentication tokens for hundreds of cars, and once he has enough could launch the attack.

The flaw here is giving control to untrusted third party websites, not the authentication mechanism.

Agreed, OAuth alone does not help. Think more of the Apple or Windows App Store models:
a) First of all, any addition of a new app, device or service that can control the car, needs to start in the car, not out on the web.
b) You need the ability to give specific apps & services specific privileges. If I use an app that is meant to monitor my battery and it asks for permission to see my location, unlock my car and open my sunroof, I'm not going to use that app.
c) The car should also be able to keep a log of when and where a service has connected to it, and for what purpose.
d) Tesla needs the ability to revoke access to an app at a moment's notice.
e) Finally, and probably most importantly, they need to provide an official mechanism to get access to apps and services that Tesla has verified, rather than driving the developer community underground.

Once there is a legit way to do all this, suddenly the non-legit way becomes a lot more suspicious. Lacking that, any one app looks the same as any other app.
 
One small point, even though the Tesla API doesn't have a required way for apps to identify themselves,
from the beginning I made sure my windowsphone app tells Tesla who it is and what version it is on all requests, so they have the option of selectively blocking me. (and have the ability to know how much traffic comes from my app vs others, etc)

That's a good practice, but I would venture it's uncommon.
 
This is a well-known problem. How they solve it is dependent on the languages they use and other aspects of their architecture into which I have zero visibility.

It shouldn't matter what language Tesla uses because I am asking for guidance for how *we* could stand up an OAUTH server, just to prove the point that is it easy and doesn't require a lot of resources. It's safe to assume the back end code is Java/POJO and the mobile apps are written in Objective-C and Java. In you want, make it even easier and consider this a greenfield deployment. Describe a system for any language and architecture you are familiar enough with that you can tell us how to easily replicate it and help us stand that up. Be a part of the solution instead of just pointing out a problem.

If they can't solve this quickly, they need to fire their entire API/mobile team.

That's harsh and totally uncalled for. The people at Tesla work their tails off and do the best they can with the limited resources they have. They are heads down working on rolling out the infrastructure for Europe right now.
 
Big companies go through this as well. OnStar did.


OnStar gives Volt owners what they want: their data, in the cloud

GM rushed work on a new API to get a popular Volt owner site back on road.

http://arstechnica.com/information-...wners-what-they-want-their-data-in-the-cloud/

From tire-kicking to app hacking

While GM and OnStar were planning a broader rollout of access to the ATOMS APIs, customers had limited access to a controlled set of partners until recently. But that didn't stop Rosack from wanting access to his OnStar data and wanting more than just a look at it on his phone.
"Right after I got my Volt," Rosack said, "I started playing around with (the phone) app... I figured it'd be cool if I could find a way to store that data in a database, so I reverse engineered the service calls that the app makes and created Volt Stats. [ Volt Stats! Tracking real world usage of Chevy Volts in the wild... ]"
Soon, he took the next logical step and launched Volt Stats as a website. Using the reverse-engineered Web service call, he allowed other Volt owners to gain access to their own data and share it on the site. It did more than track a vehicle's electrical and gas mileage—it allowed owners to share their location to show geographic differences in mileage performance and track driver "achievements"for the best performing cars. Cars here were ranked by energy efficiency history.
<snip>
The site gained a good deal of notice within the Volt owner community and the automotive press. By September of 2012, there were more than 1,800 active registered users sharing their Volt data. But as OnStar continued to develop its API, it discovered a problem with how Volt Stats was connecting to the ATOMS cloud. Among the concerns was owner privacy, since the site used owners' OnStar usernames and passwords directly to access the data. It was also pulling location data.
On October 13, Rosack informed the Volt Stats community that GM was cutting him off. " GM has informed me that they'll be shutting down the interface I'm using to collect data for Volt Stats effective immediately," he wrote on Facebook.
Rather than leaving it at that, GM accelerated efforts to build a new public API. "They've promised to work with me to get an alternate API available," Rosack told his users, "so hopefully data collection won't be down that long. I'll keep you all updated as I hear more."
That new API uses JAX-RS (the Java API for RESTful Web services) and OAuth, the protocol for API access delegation used by Twitter and other social media and Web services providers. Doug Mutart, OnStar's Chief Architect, immediately put out a call for API developers to help build the public UI, and a group of contractors came on to rapidly scale up OnStar's API efforts. Meanwhile, Rosack needed to draft a privacy policy that would pass inspection with GM's legal department. A little more than a month later—November 20—Volt Stats was back up and running, though users had to re-register through the new API.
 
It shouldn't matter what language Tesla uses because I am asking for guidance for how *we* could stand up an OAUTH server, just to prove the point that is it easy and doesn't require a lot of resources. It's safe to assume the back end code is Java/POJO and the mobile apps are written in Objective-C and Java. In you want, make it even easier and consider this a greenfield deployment. Describe a system for any language and architecture you are familiar enough with that you can tell us how to easily replicate it and help us stand that up. Be a part of the solution instead of just pointing out a problem.

I've got my own software development teams and projects to worry about. I'm not interested in engaging in free software development for a company I just shelled out $83K to.



That's harsh and totally uncalled for. The people at Tesla work their tails off and do the best they can with the limited resources they have. They are heads down working on rolling out the infrastructure for Europe right now.

It's not at all harsh.

And I seriously doubt the people responsible writing the API are involved with rolling out the infrastructure for Europe.
 
If they can't solve this quickly, they need to fire their entire API/mobile team.

Yes, it is harsh. You have no idea what the priorities are at the moment for the team that did the API work. To issue a blanket statement like 'they should fire them all' is irresponsible. If you do run software teams, as you state, then you know how much work can be in a pipeline that may have higher priorities, and that people outside the group are incapable of sizing.

Just an fyi. Most of the people here were also the smartest one in their class.

- - - Updated - - -

And I do not use mint.com or quicken. ftr.
 
I've got my own software development teams and projects to worry about. I'm not interested in engaging in free software development for a company I just shelled out $83K to.

I am. I guess that's the difference between you and I, and everyone else that has found the time to add value to this ecosystem of enthusiasts. Either join the party or leave the party but don't spoil the party.
 
I am. I guess that's the difference between you and I, and everyone else that has found the time to add value to this ecosystem of enthusiasts. Either join the party or leave the party but don't spoil the party.

I don't get this. Why doesn't identifying a deficiency (i am not sure if it is) and writing about it and discussing in depth in a forum, not considered as a positive contribution ? Why does everyone have to go the whole mile ?

Now if my objective was to get a better Tesla ecosystem I wouldn't go write in a forum like Forbes or worse Seeking Alpha - but that's a different point.
 
I don't get this. Why doesn't identifying a deficiency (i am not sure if it is) and writing about it and discussing in depth in a forum, not considered as a positive contribution ? Why does everyone have to go the whole mile ?

Now if my objective was to get a better Tesla ecosystem I wouldn't go write in a forum like Forbes or worse Seeking Alpha - but that's a different point.

No, you didn't get it at all. They were talking about software contributions in this exchange (and it was the author who said he didn't have time).
 
I don't get this. Why doesn't identifying a deficiency (i am not sure if it is) and writing about it and discussing in depth in a forum, not considered as a positive contribution ? Why does everyone have to go the whole mile ?

Now if my objective was to get a better Tesla ecosystem I wouldn't go write in a forum like Forbes or worse Seeking Alpha - but that's a different point.

Discussing in depth would be a positive contribution. I see no depth to the discussion from nspollution. I'm not saying that everyone has to write code and give it away. All I was asking for was a recommendation on an OAUTH server and how to size it, based on someone with actual experience implementing such a thing. OAUTH clients are easy. I've never setup an OAUTH server, nor an entire app store. It seems like a large effort to me but I'm willing to be educated.
 
Discussing in depth would be a positive contribution. I see no depth to the discussion from nspollution. I'm not saying that everyone has to write code and give it away. All I was asking for was a recommendation on an OAUTH server and how to size it, based on someone with actual experience implementing such a thing. OAUTH clients are easy. I've never setup an OAUTH server, nor an entire app store. It seems like a large effort to me but I'm willing to be educated.

The point is that some of us put substantial amounts of effort and time in creating something that we are sharing with the community.
And that is a better way to contribute then to throw stones and then walk away when asked to help make things better.

Hans, through other open source efforts I'm involved in I know a couple of people who have set up oauth servers. None of them has a Tesla but they are huge open source enthusiasts. Maybe I can find some help there.
Otherwise I'm sure you and I can figure it out...
 
The point is that some of us put substantial amounts of effort and time in creating something that we are sharing with the community.
And that is a better way to contribute then to throw stones and then walk away when asked to help make things better.

In other words, you and Hans expect me to contribute my time in exactly a way that suits your interest without any regard for my different priorities. Any failure to do so on my part constitutes "throwing stones".

Brilliant.

- - - Updated - - -

Discussing in depth would be a positive contribution. I see no depth to the discussion from nspollution.

I wrote an article that described the problem in depth. I've followed up here with more detail.

The answer is simple: implement OAuth in the Tesla API. It's not rocket science, it's been done a million times, and Tesla doesn't need me to tell them HOW to implement OAuth in their architecture.

You doing a proof of concept independent of their architecture is great for you, but it doesn't actually do anything to address the issue.

- - - Updated - - -

No, you didn't get it at all. They were talking about software contributions in this exchange (and it was the author who said he didn't have time).

No, I'm not in the least bit interested in writing software for Tesla.

I may at some point write one of those third-party things you guys don't think should exist as part of a home automation project and it will almost certainly be Open Source.

But I'm not writing software for Tesla.