Something to keep in mind is that they didn't have access to the actual brakes, they had access to set the parking brake. Which if I recall correctly can only be activated at under 5 MPH. So they can't just slam on the brakes while you are driving down the freeway.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Something to keep in mind is that they didn't have access to the actual brakes, they had access to set the parking brake. Which if I recall correctly can only be activated at under 5 MPH. So they can't just slam on the brakes while you are driving down the freeway.
Gizmotoy
Active Member
Right. Sorry. Got sick of putting that in my replies over and over. Guess I should have continued for clarity.
(Edit: actually, looks like I did state it in this post, just not in this sentence. Double )Though, one thing we're not sure of is whether that 5mph (or whatever it is) restriction is enforced on the center console or if it's enforced behind the secure gateway. The latter is clearly the right place for that check, so hopefully you're right. Impossible to say for sure for those of us without root access (maybe Ingineer or wk knows?).
with all due respect, it is trivial, if it's unencrypted. i do this everyday for my customers.
What is it that you do? pentester? security researcher?
The braking is what I found most interesting. I don't know about a speed requirement but from the manual (which is a little confusing on the topic of "e-brake") it sounded like it engaged if you switched the button AND hit the brakes. So if that's true the bad guy would have access to the brakes. I hope I'm wrong because that takes it beyond the MCU I think.
That's good to know and not reported nearly well enough, i think the assumption is access to brakes means sudden stops at high speed
HankLloydRight
No Roads
I'm not so sure about this. How does doing a search in the browser (over HTTP or HTTPS) expose the bearer token for the API?
Nothing in the browser connects to the API.. I never put in my MyTesla credentials or login in the car, no API token is acquired, so the car would never have the bearer token to access the API , or to send it over HTTPS from the browser. In fact, I can't see how or why the car itself would need to access the API since all the same data exposed on the API is already available internally.
Unless the user is actually logging into the MyTesla page from the browser, and even then I don't think the bearer token is passed back in the webpage interface to MyTesla (it's not using the API), but in that specific case, the hacker could gain your MyTesla credentials. But that's not what you're saying.
Head of a very large global IT security organization (recently retired). This stuff happens but most of the successful ones are people who obtained pw's. BTW we have much more sophisticated enterprise level tools than Mitnick's and we see thousands of attacks but we can stop them real time because we control both the AP and the node and the software detects the attack signature. Tesla's problem is different but I think manageable on the gateway.
Last edited:
Yeah, I didn't read far enough. I thought his scenario was grabbing the wireless auto token via a mitm AP/Browser not the Tesla API credentials.
it doesn't, It was a theoretical situation as an example of a local attack enabling a remote attack, I highly doubt the situation is remotely the same, if tesla was that careless with security I would cancel my order.
Congrats on retiring.
if you are speaking specifically about Tesla's security that's one thing (I can only hope that its not trivial) since my tesla hasn't arrived yet I can only speak to other similar scenarios until I have a chance to get more specific information myself.
However, if you are speaking in general that is alarming, you of all people should know just how trivial a scenario like that is, the fact that you say its not trivial is very concerning especially if you are the head of a very large global IT security organization. I mean no disrespect but you really should know better.
Last edited:
No need to get defensive it's just that the real world is different than what a researcher experiences. Yes I think Tesla is managing this risk and wrt large corporate networks this is also managed.
Do me a favor though when you get your car if you find a vulnerability please communicate directly and privately with TM.
Of course, please understand that I am not trying to be defensive, I apologize if it comes across that way, I simply want it to be clear with whomever it concerns that a typical man in the middle attack is trivial and that it is most likely the attack vector used with the most recent vulnerability.
To tell people they are secure because something seems hard or difficult is to reinforce a false sense of security.
I did a little more checking teslamotorsclub.com is definately not using public key pinning which means they are susceptible to a man in the middle attack.
A man in the middle attack means that if you are on the site at say a coffee shop or at work, someone could remove the https encryption and see everything you are doing in plain text, they could also grab your cookies and impersonate you on the site.
Depending on when a mitm attack occurs they could potentially intercept your password in plain text, which if you use the same password elsewhere say on facebook, your bank or God forbid on your tesla app well then you have real trouble on your hands, the worse case scenario is someone could steal your car, your money and your friends......
The lesson here is to assume you are not secure, insulate yourself from cascading trouble and don't use the same password for everything.
That's not what I'm saying. What I said was the risk is managed. Risk is measured in several different ways one of which is the likelihood of occurrence.
@doug - see post #152. Not sure if this is true or if the poster reached out to you before posting publicly but F.Y.I.
Last edited:
They overwrote gateway firmware:
Tesla Responds to Chinese Hack With a Major Security Upgrade
That's pretty gutsy. I mean screw up one line in the firmware bin and you basically brick the car.
Tesla Responds to Chinese Hack With a Major Security Upgrade
That's pretty gutsy. I mean screw up one line in the firmware bin and you basically brick the car.
Thanks for sharing. Even though they've been testing code signing for some time I agree it was a gutsy but necessary move.
interesting, I'm glad to hear they implemented code signing, hopfully they fixed the wifi attack vector as well.
the fact that they were able to remotely execute code on connection is really scary, that means they could have setup a rogue AP close to a highway and gained entry into every tesla that drove by.
it's one thing to put your valuables in a safe inside your house, but if you continue to leave the door wide open thieves are bound to walk inside and look around.
Last edited:
The web browser had to be actively used from what I read. And a fixed access point would only be in range for 10 seconds. So it would take a good bit of luck for this exploit to be used.
Of course, could follow someone, amplifiers, directional antennas, etc.
But how many actively use the web browser when driving?
Gizmotoy
Active Member
Hard to say, but it's possible that a noticeable percentage do. After all, there are a variety of Tesla-targeted pages written by enthusiasts. The Waze one is popular, and there's a bunch of different homepage-style ones. It wouldn't be hard to come up with a short list of sites that might be active on a vehicle in motion, and an additional set that have high likelihood of being used when parked (Plugshare, etc.).
I thought this back and forth with the Keen group from China and Elon was interesting.
There could still be thousands of unpatched cars around the world.
There are, like the people that are refusing to upgrade from 6.2 or 7.0. (Or didn't get the 7.1 security update before the 8.0 push and now they don't want to install 8.0 because of something like the media player handling of USB drives.)
