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.
If someone uses the Tesla iOS app only to communicate with their Tesla, never uses any 3rd party app/site to do so, and never divulges their ID/PW to anyone, is there a risk that someone can gain control over their Model S? If not, then it's not a flaw.

If it only becomes a risk if another person builds a 3rd party app (using the API garnered only thru hacking), and the Model S owner then chooses to use that 3rd party app to access their car. Then I don't call that a flaw. Perhaps it wasn't thinking ahead and about the possibilities what unscrupulous people might do and designing to that possibility. But it isn't a flaw.
 
Please answer this: If someone uses the Tesla iOS app only to communicate with their Tesla, never uses any 3rd party app/site to do so, and never divulges their ID/PW to anyone, is there a risk that someone can gain control over their Model S?

Repeating your stance doesnt make you righter.
 
Can anyone confirm if this is indeed the case? Does changing the password on the My Tesla site invalidate the authentication tokens previously issued?

I just tried it. It took several minutes for my changed password to take effect. Once it was changed I could continue to use the mobile app for at least 45 minutes and counting. The location tab does not display but all the other tabs display and the controls still work. The location information on the mobile app comes from the streaming API so I bet the streaming tokens expire more quickly and shut down only that portion of the mobile app.

So in summary:
1) The phone thief can honk your horn and unlock your car, but they might not know where the car is.
2) If you can track your phone, you are safe to hunt the thief down using the car ;-)
 
Please answer this: If someone uses the Tesla iOS app only to communicate with their Tesla, never uses any 3rd party app/site to do so, and never divulges their ID/PW to anyone, is there a risk that someone can gain control over their Model S?

Repeating your stance doesnt make you righter.

You know that, and I know that. And maybe 100 other people. Nobody in my family is going to understand the difference between downloading an iPhone app and a Windows phone app, but there is. Heck, not even the Tesla employees know that since in the store they now tout the Windows phone app as just another app.

If Tesla itself does not differentiate, what is my mother-in-law to make of it?

Tesla does not look at the source - they don't know whether that app takes your username and password and uploading it to some central server. We trust that it won't because the author is on TMC, but that's pretty much it. He might just be someone who want to create a short opportunity by waiting for a hurricane and then opening everybodys sunroofs.

Yet Tesla recommends that app... Heck they sell cars based on the availability of that app.

The most dangerous attacks in the world are social engineering attacks, and there is no protection against that here.
 
I just tried it. It took several minutes for my changed password to take effect. Once it was changed I could continue to use the mobile app for at least 45 minutes and counting. The location tab does not display but all the other tabs display and the controls still work. The location information on the mobile app comes from the streaming API so I bet the streaming tokens expire more quickly and shut down only that portion of the mobile app.

Thanks. It would be helpful if you could see for how long you can continue to access this without 'knowing' the new password. Try it for a few days...

Also, perhaps you can try to disable and then re-enable mobile access in the car? See if that invalidates the token.
 
Nothing unscrupulous or uncommon needs to happen for this flaw to become an active vulnerability.
Assuming there are no other security issues with Tesla's servers, I am at a bit of a loss as to where the extraordinary risks lie. Here's a few scenarios:

1. Someone steals your auth token. Can be used to get access to the API as you. You say Tesla can't revoke the token, but how do you know they can't? Did you ask them?
2. Lose your username/password. Same risk as any other application. Change your username/password.
3. Lose your phone. Better hope you have a strong passcode on it and it's not vulnerable to any one of the hard-hacks that get you access to it. Or are able to remote-wipe the device.
 
Assuming there are no other security issues with Tesla's servers, I am at a bit of a loss as to where the extraordinary risks lie. Here's a few scenarios:

1. Someone steals your auth token. Can be used to get access to the API as you. You say Tesla can't revoke the token, but how do you know they can't? Did you ask them?
2. Lose your username/password. Same risk as any other application. Change your username/password.
3. Lose your phone. Better hope you have a strong passcode on it and it's not vulnerable to any one of the hard-hacks that get you access to it. Or are able to remote-wipe the device.

If you lose your phone, and can not remote wipe it, then you need to change your passwords. You should change your passwords even if you think you can remote wipe it.
 
Thanks. It would be helpful if you could see for how long you can continue to access this without 'knowing' the new password. Try it for a few days...

Also, perhaps you can try to disable and then re-enable mobile access in the car? See if that invalidates the token.

I would have someone else try that, in order to still be able to measure the time it will work.

Also, I would have someone else try it and see if logging in to another device invalidates the previous token.
 
There is the risk of a brute force attack. But Tesla would notice that. Other than that, no.

If the Tesla API was reverse-engineered via a MtM, then yes, your iOS app is open to a MtM attack that can easily happen on any public WiFi.

I have NOT verified this is, in fact, possible. There are other ways that the API could have been reverse-engineered without an MtM depending on how the app is designed and how keys were being handled. However, my understanding is that it was reverse-engineered via MtM.

- - - Updated - - -

Assuming there are no other security issues with Tesla's servers, I am at a bit of a loss as to where the extraordinary risks lie. Here's a few scenarios:

1. Someone steals your auth token. Can be used to get access to the API as you. You say Tesla can't revoke the token, but how do you know they can't? Did you ask them?

I assume Tesla can revoke the token. It would actually be a critical flaw if they could not.

Yo, however, cannot.

Furthermore, you can't know which token to revoke, so all tokens must be revoked.

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.

With Tesla? You call them up, they wipe all current tokens. You then have to go back and re-authorize anything that had been previously authorized.

Also, with the Twitter model, there's full traceability. If something funky is going on, it can be traced to specific authentication credentials for an application. With Tesla, you just know something is wrong, but you likely have no idea what tool is responsible.

2. Lose your username/password. Same risk as any other application. Change your username/password.

No. Using the Twitter example, Twitter is the only site with your Twitter user name/password. Under the Tesla model, every site that needs to access the API must at various points get access to the user name/password.

3. Lose your phone. Better hope you have a strong passcode on it and it's not vulnerable to any one of the hard-hacks that get you access to it. Or are able to remote-wipe the device.

If the MtM reverse-engineering story is true, the iPhone app is a walking vulnerability.

- - - Updated - - -

All I understand from this entire debate is that razor blades for flossing are a bad idea.

The important thing to know is that no one actually flosses with razor blades.

On the other hand, people regularly share their authentication credentials with (often reputable) third-party sites to gain access to value-add functionality. The architecture of the Tesla API ignores this reality and is thus flawed.
 
If the Tesla API was reverse-engineered via a MtM, then yes, your iOS app is open to a MtM attack that can easily happen on any public WiFi.

I have NOT verified this is, in fact, possible. There are other ways that the API could have been reverse-engineered without an MtM depending on how the app is designed and how keys were being handled. However, my understanding is that it was reverse-engineered via MtM.

It was a self-MITM attack. A ssl proxy is placed so traffic passes through it, proxy CA installed onto iPhone as trusted, then App started. Not something that could happen on public wifi unless you manually installed the MITM SSL proxy's CA.
 
On the other hand, people regularly share their authentication credentials with (often reputable) third-party sites to gain access to value-add functionality. The architecture of the Tesla API ignores this reality and is thus flawed.

I think this is a logical fallacy.

You can say it's flawed in your opinion, but not "thus flawed".

Your article should have appealed to people to not use 3rd party web apps, and not proclaimed that the internal API is flawed.
 
Last edited:
I think this is a logical fallacy.

You can say it's flawed in your opinion, but not "thus flawed".
Pretty much. The entire flaw is that Tesla hasn't engineered a proper 3rd party API. If they did so, it would eliminate all these issues.

I don't really see it as an issue. I'm sure that Tesla will get around to it eventually, the same way that GM did with voltstats.net.

The real issue is that nspollution's article makes it seem that the reverse engineered API libraries are an official Tesla API. When in fact, they are not.

It was a self-MITM attack. A ssl proxy is placed so traffic passes through it, proxy CA installed onto iPhone as trusted, then App started. Not something that could happen on public wifi unless you manually installed the MITM SSL proxy's CA.
Exactly. I'm really surprised that a so-called "expert" did not bother to figure this out first before bagging on it.

On the other hand, people regularly share their authentication credentials with (often reputable) third-party sites to gain access to value-add functionality. The architecture of the Tesla API ignores this reality and is thus flawed.
This is really your only legitimate claim.