I just tried and mine automatically connected to Tesla Guest. I assume it'd automatically connect to any other remembered WiFi network too. Is Tesla Service special in this regard?
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Since i don't have a tesla yet (December can't come fast enough) I'm not entirely sure what they've done, i can only speak to my experience.
my preference would be for tesla to completely eliminate wifi probe requests and make it so that if you wanted to connect to any wifi you have to hit a button to initiate the connection, then after it is disconnected for whatever reason it does not auto reconnect you have to once again click a button to reconnect.
if that's how it works now, id be super happy.
that would defeat deauth attacks and rogue access points
my preference would be for tesla to completely eliminate wifi probe requests and make it so that if you wanted to connect to any wifi you have to hit a button to initiate the connection, then after it is disconnected for whatever reason it does not auto reconnect you have to once again click a button to reconnect.
if that's how it works now, id be super happy.
that would defeat deauth attacks and rogue access points
It auto connects to known AP's if the keys are the same. When you get yours you will see that it shows up as an unknown device on your home network with Tesla's internal non routable IP I believe through their gateways VPN.
https is a hard thing for a website to get right, if you do it wrong its the same as not having it at all and the encryption can be stripped very easily.
also if you don't implement public key pinning and hsts its almost as bad as not implementing https anyways
hsts and public key pinning basically tells the browser to never even attempt to try http, it also gives the browser the fingerprint of the encryption it should expect enabling the browser to deny the connection of its been altered.
this is a good place to start checking if https has been properly enabled
SSL Server Test (Powered by Qualys SSL Labs)
this site has some good tools for checking pinning and csp Welcome to report-uri.io
sadly teslamotorsclub.com hasn't properly implemented https meaning it is vulnerable to a man in the middle attack.
Don't be afraid though, about the only thing a hacker would want to do so on here is steal your username and password and use it on other higher profile sites like your bank or email, that can be mitigated by not using the same username and password everywhere.
if your not using good password practices you should, i recommend using either a password manager like onepass or lastpass, even writing them down is better than using the same one everywhere.
also if you don't implement public key pinning and hsts its almost as bad as not implementing https anyways
hsts and public key pinning basically tells the browser to never even attempt to try http, it also gives the browser the fingerprint of the encryption it should expect enabling the browser to deny the connection of its been altered.
this is a good place to start checking if https has been properly enabled
SSL Server Test (Powered by Qualys SSL Labs)
this site has some good tools for checking pinning and csp Welcome to report-uri.io
sadly teslamotorsclub.com hasn't properly implemented https meaning it is vulnerable to a man in the middle attack.
Don't be afraid though, about the only thing a hacker would want to do so on here is steal your username and password and use it on other higher profile sites like your bank or email, that can be mitigated by not using the same username and password everywhere.
if your not using good password practices you should, i recommend using either a password manager like onepass or lastpass, even writing them down is better than using the same one everywhere.
Last edited:
i don't use exchange so i can't speak with any specifics in that regard.
but i can say that hsts and pinning are enforced by the clients, for instance Internet Explorer does not enforce pinning whereas chrome Firefox and others do so its a two part problem to solve, enabling the features on the server and using clients which enforce the features
Gizmotoy
Active Member
Maybe it's mostly nuance, but no, that is not what I was saying. I meant that there's no evidence they executed arbitrary code on the black, secure side of the gateway. It appears they've only gained access to controls made available to the insecure side of the gateway. That severely limits the scope of what an attacker could do with another, similar hack. At the same time, it is very hard to protect against another similar attack because systems on the insecure side must, out of necessity (apparently), have access to those functions.
So part of the point was that Tesla may have closed the vector used to access the vehicle, without correcting the underlying problem that gaining access to the center console provides full access to all functions available from the center console, including several that may be dangerous for the driver.
I think you both miss the point that the vector they apparently closed was *remotely* exploitable. It wasn't meant to stop someone with a local connection to the MCU with two factor authentication. The remote vector was the risk.
Sure, but those are all browsers. I meant to ask does Outlook/Thunderbird/iOS mail etc. support HSTS?
Gizmotoy
Active Member
So we're ok with every single remotely exploitable vector being able to engage the emergency brake, possibly power down the vehicle, or whatever else the center console can do? Let's not pretend that this is the last one ever.
There's no such thing as 100% secure or bug free. Sorry. That's the value of security researchers and bounty programs.
its most likely that the initial exploit required a local mitm atrack thus enabling remote access considering the video showed him searching for charge points first.
remote mitm attacks on a tesla would require a different attack vector such as compromising teslas servers or discovering a way to search for connected tesla..... both very scary if accomplished especially if tesla did not fix the underlying issue and only fixed one vector of attack.
hsts and pinning a primarily browser based solutions, mail servers would need to implement their own solutions if the end client isn't a browser, that's not to say that you can't implement pinning in a mail client, but I don't use mail clients so i can't say for sure.
im just guessing but i think the mail server probably implements its own version of certificate verification, not necessarily pinning, it could have a certificate it uses to authenticate to the server or its own fingerprint verification whatever it is just make sure that's implemented, then find a tool to test it, kali Linux provides a suite of pen testing tools, there is probably something on there to test mail servers.
I'll do some investigating to see if i can't point you in a good direction
Gizmotoy
Active Member
Right. So why exactly would you advocate that if the remote access vector has been patched that's the end of it? The main issue is the fact that the insecure center console can push requests through the secure gateway and have them performed. For some stuff that's fine, but parking brakes (for example) are not one of them. That is the underlying issue that needs to be fixed, and the real vulnerability. If not, we're just going to see the same thing all over again the next time there's a remote exploit.
In other words: how they got access matters. What they were able to do with that access is far more worrisome. An internet-connected, remotely-exploitable computer in the vehicle should not have access to the brakes. Period.
Edit: And to be fair, we don't know what they fixed. Maybe they fixed both, we don't know.
an example local attack that could enable remote attacking would go something like this.
1. hacker sets up a rogue acces point, 2. tesla has wifi enabled with an AP called "homewifi" saved in the preferred network list and is sending out probes for that AP
3. hackers AP responds to the tesla probe saying yes i am "homewifi"
4. tesla is now connected to the hackers AP
5. tesla owner does a search for charging stations
6. hacker records that search which also includes the bearer token used to access the tesla api
7. hacker can now use that token (depending how long it lives) remotely to access the tesla api and act upon that Tesla that he performed the mitm attack.
in this scenario tesla could fix a couple things to mitigate the attack.
they could make sure that bearer token is short lived, like 7 seconds or something, they could not use the bearer token for unencrypted searching like for chargers (if they were) , they could fix the wifi probes, they could not allow break access from the api etc..
this isn't what happened to the best of my knowledge its just an example of how a local attack could enable a remote attack.
also this attacks assume breaking and such are possible via the api
1. hacker sets up a rogue acces point, 2. tesla has wifi enabled with an AP called "homewifi" saved in the preferred network list and is sending out probes for that AP
3. hackers AP responds to the tesla probe saying yes i am "homewifi"
4. tesla is now connected to the hackers AP
5. tesla owner does a search for charging stations
6. hacker records that search which also includes the bearer token used to access the tesla api
7. hacker can now use that token (depending how long it lives) remotely to access the tesla api and act upon that Tesla that he performed the mitm attack.
in this scenario tesla could fix a couple things to mitigate the attack.
they could make sure that bearer token is short lived, like 7 seconds or something, they could not use the bearer token for unencrypted searching like for chargers (if they were) , they could fix the wifi probes, they could not allow break access from the api etc..
this isn't what happened to the best of my knowledge its just an example of how a local attack could enable a remote attack.
also this attacks assume breaking and such are possible via the api
Last edited:
I never said that's the end of it. Things like this trigger a risk based assessment process intended to identify any and all attack vectors and vulnerabilities. Given my experience in this field I am confident that's going on and should be an ongoing process. If you look at this gateway from the outside in you'll see its more secure than you think. As to Tesla servers and Tesla hosted infrastructure I am aware those are also part of an ongoing assessment process. Again, unfortunately you can't expect perfect.
Gizmotoy
Active Member
Are you sure?
Because, with all due respect, no. The remote vector was the immediate issue, but the risk is that a computer connected to the internet, which is remotely exploitable, has access to the brakes (even if that's only the parking brakes). It's entirely possible the remote vector was closed and the risk is ongoing. There's two separate deficiencies at work here.
Yes, plausible and what most think happened but I don't think #6 is as trivial as you do and that's the key (no pun intended) to the exploit. It is possible though.
