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

Security from the frontlines... (OR How to Hack A Model S talk at DEFCON)

This site may earn commission on affiliate links.
Yes, Tesla seems to have architected the system well, but as recent events have shown with all the zero-day vulnerabilities in open-source software, you can't take anything for granted. All they'd need is some strange race condition, buffer overflow or the like, and someone could get into the center display. It appears that Tesla has taken steps to ensure that the critical systems are somewhat isolated, and that the updates are performed by the Gateway ECU which is a separate embedded system, but with so many interconnected systems and so much complexity, there's bound to be a few weaknesses.

It really would deter a lot of potential "hackers" if they'd release an API and let sandboxed apps run on the center display. Then users would be able to develop cool new extensions without as much risk to Tesla.
 
I think it's more connected than you would suspect. Think about the things the main display can do:
enable or disable emergency braking
adaptive cruise
power the car off
parking brake control
enable or disable valet mode
set charge settings
enable and disable tow mode
etc

I think there are a lot of things you wouldn't want app developers doing to your car :)
You might suspect that each component exposes only a known set of functionality and checks for valid conditions, etc. You might also be surprised that developers are lazy and "if the main display checks that the car is stopped before applying the parking brake, we don't have to check it in the e-brake code"
 
The car's AT&T IP is useless also, as Tesla still uses the encrypted VPN connection over this link. Even if you MITM attacked via AT&T you wouldn't get anywhere.

I don't know enough about the cellular side of things, so I might be completely wrong, but. . . I'm not sure I'd agree here (Without more info.) Look at the Jeep hack that was reported. They did it was a Sprint burner. I'm wondering how possible it would be with an AT&T burner on the same network as the Tesla. Yes, they use an encrypted VPN, but that's for talking with the Tesla servers. Tesla's are still talking to the Internet without the VPN to access browsing, music, etc. So not all traffic is going over the VPN. If there's an opening, someone's going to figure out a way in if there's even the smallest crack (Pun not intended, but well taken!)
 
But that's kind of the point... I'm not convinced that the car would respond to anything other than Tesla's servers for actual control functions. I worked on a system like that last year. Sure you could likely get in front of the target system, but it wouldn't listen to you unless you could spoof the certs at the mothership, which is insanely unlikely. As for the other stuff that uses resources from the Internet, I'd be shocked if these were not a completely different, sandboxed system.
 
But that's kind of the point... I'm not convinced that the car would respond to anything other than Tesla's servers for actual control functions. I worked on a system like that last year. Sure you could likely get in front of the target system, but it wouldn't listen to you unless you could spoof the certs at the mothership, which is insanely unlikely. As for the other stuff that uses resources from the Internet, I'd be shocked if these were not a completely different, sandboxed system.

Until we see the actual hack, a lot of this is just pure speculation on our parts.
However, regardless of how this specific hack works, I am always going to be a little worried that there isn't a complete air gap between functions that control the critical functions of the car and the internet connected portions of the car.

Under ideal circumstances, you're right, the car has been designed to only respond to requests from authenticated and authorized source. However, the MO of a hacker to find routes that were overlooked in the original design. Without a physical gap, this will always be a battle of good vs. evil.

With all that being said:
1. I accept the little bit of risk that this exposes me to vs the convenience and utility that the overall connected nature of this car provides to me. This is the same as me using online banking, keeping my email on google's servers, etc.
2. I have complete confidence that Tesla's engineers are much better than those of the other car manufacturers. Hackers often go after the easiest targets. Hopefully they will stick to hacking Jeeps.
3. I'm convinced that events like DEFCON, where they effectively red team the car and share their findings with Tesla, actually increase the security of the car. I'd rather not have the vulnerabilities and 0-days only known to a smaller community.
 
Until we see the actual hack, a lot of this is just pure speculation on our parts.
However, regardless of how this specific hack works, I am always going to be a little worried that there isn't a complete air gap between functions that control the critical functions of the car and the internet connected portions of the car.

Under ideal circumstances, you're right, the car has been designed to only respond to requests from authenticated and authorized source. However, the MO of a hacker to find routes that were overlooked in the original design. Without a physical gap, this will always be a battle of good vs. evil.

With all that being said:
1. I accept the little bit of risk that this exposes me to vs the convenience and utility that the overall connected nature of this car provides to me. This is the same as me using online banking, keeping my email on google's servers, etc.
2. I have complete confidence that Tesla's engineers are much better than those of the other car manufacturers. Hackers often go after the easiest targets. Hopefully they will stick to hacking Jeeps.
3. I'm convinced that events like DEFCON, where they effectively red team the car and share their findings with Tesla, actually increase the security of the car. I'd rather not have the vulnerabilities and 0-days only known to a smaller community.

I still have my money on most of them being local hacks that need physical access to the car, so, like a hack an owner can do, not some remote bimbo. One of them might be remote, and I have a feeling it would be really limited.
 
Until we see the actual hack, a lot of this is just pure speculation on our parts.
However, regardless of how this specific hack works, I am always going to be a little worried that there isn't a complete air gap between functions that control the critical functions of the car and the internet connected portions of the car.

Unfortunately, you don't get software update capability with an air-gap.

It's made more secure when you guarantee that *every* module has a secure firmware update path. If just one module has an insecure firmware update path, you simply push your own firmware to it that, in turn, accepts commands to send to the CAN bus via more firmware updates. Even if you separate the drivetrain CAN bus (and it seems as if it is), you still have tens of modules on which you must ensure security; that, or you have to secure and validate the CAN bus messages - which is an order of magnitude more difficult and will take a much longer time.
 
It's absolutely amazing to me that a company would release any kind of connected telematics system without having a remote software upgrade system in place. Of course one could posit that keeping the physical need to upgrade prevents an attacker from altering the software remotely. However, on a system that clearly has no real/effective air-gap, firewall or sandbox, this simply fails to make sense. No Chrysler/Fiat is going to pay the price. How many other systems like this are out there waiting to be discovered?

They should immediately hire those security researchers and see if they can find a way to "hack" in and patch the software. That would save them a bunch of $.
 
But that's kind of the point... I'm not convinced that the car would respond to anything other than Tesla's servers for actual control functions. I worked on a system like that last year. Sure you could likely get in front of the target system, but it wouldn't listen to you unless you could spoof the certs at the mothership, which is insanely unlikely. As for the other stuff that uses resources from the Internet, I'd be shocked if these were not a completely different, sandboxed system.
But I doubt the web browser proxies through Tesla to access the Internet. So in that case you have a direct connection between the car and the OCS (origin content server ie web server) and possibly get the user to click on and load malicious code. So there is a vector there. The question as you posit is how separated the browser, radio, etc is from the rest of the system. There was a thread on the internal ethernet network inside the car. Haven't checked that thread in a long time, but IIRC lots of things had access to that network for the screens to communicate w/ each other. So if someone were to exploit the browser or radio they would have remote access to the internal ethernet network.

Here it is:
Successful connection on the Model S internal Ethernet network
 
It's absolutely amazing to me that a company would release any kind of connected telematics system without having a remote software upgrade system in place.
You would think, right? Believe it or not, that kind of automation is rare outside of the really good software shops. It's downright non-existent in a lot of what I call "big dumb companies," where software is not their primary business (or at least, it is but they don't think so).

But I doubt the web browser proxies through Tesla to access the Internet. So in that case you have a direct connection between the car and the OCS (origin content server ie web server) and possibly get the user to click on and load malicious code. So there is a vector there.
Again, I would be shocked (or very disappointed, at least), if the browser was not sandboxed in a way that made it unlikely or damn near impossible to leverage any kind of vulnerability into the operation of the car. I mean, think about the way phones and tablets work... the apps are bound to their own little box, including the browser.
 
You would think, right? Believe it or not, that kind of automation is rare outside of the really good software shops. It's downright non-existent in a lot of what I call "big dumb companies," where software is not their primary business (or at least, it is but they don't think so).

Again, I would be shocked (or very disappointed, at least), if the browser was not sandboxed in a way that made it unlikely or damn near impossible to leverage any kind of vulnerability into the operation of the car. I mean, think about the way phones and tablets work... the apps are bound to their own little box, including the browser.

I've poked around at the browser. It won't connect to any of the on-VPN or in-car LAN IPs or anything that the old firmware leaked info about previously. The in car browser actually won't even connect to addresses defined in RFC1918 even if it's local. To get to pages on my in-house server (for my solar status stuff) while on WiFi I have to make a fake route to a non-local IP.

The browser also doesn't seem to connect to nonstandard ports entered in the address bar.

Overall it seems pretty locked down and I doubt there is much meat there for any real hack.
 
Reaction to security issues: Chris Evans formerly of Google joins Tesla Motors

Chris Evans, formerly responsible for the security of Google's chrome browser, has tweeted that he joins Tesla Motors to lead security there:

Chris Evans on Twitter:

This is likely a reaction to the increased interest that Tesla has gotten from security researchers - as well as the apparently appalling state of security in cars from other vendors, that Tesla is so different from.

While probably everybody else are now wondering about last nights earnings statement and the 50.000 versus 55.000 projection, I am looking forward to see how the Model S fares in tomorrow's DEF CON presentation...
 
http://uk.reuters.com/article/2015/08/06/us-tesla-motors-hacking-idUKKCN0QB1AN20150806

That seems bad, "Cybersecurity researchers said they took control of a Tesla Motors Inc Model S car and turned it off at low speed, one of six significant flaws they found... "
It also says that a patch will be distributed to all vehicles by Thursday.

The Firmware Update Tracker does show that 2.5.21 has a very rapid rollout -- 144 cars report receiving it in the past week. Faster than any other release.
 
I got 2.5.21 on Tuesday. In DEFCON badge line now.

- - - Updated - - -

From a Financial Times article:

Tesla Model S car hacked
Hannah Kuchler in Las Vegas
Cyber security researchers have found six significant flaws in Tesla’s Model S cars that could allow hackers to take control of the vehicles and have safety implications for drivers.
Kevin Mahaffey, chief technology officer of Lookout, and Marc Rogers, principal security researcher at Cloudflare, said they decided to try to hack a Tesla because the company has a better reputation for understanding software than most automakers.
But the so-called “white hat” hackers, who probe internet-connected devices to try to push companies to improve security, still found vulnerabilities.
The hack on the Tesla car, to be detailed on at the cyber security conference Def Con in Las Vegas on Friday, is the latest in a series of vulnerabilities discovered in connected cars. One high-profile case led Fiat Chrysler to recall 1.4m Jeep Cherokees last month.
The hackers had to physically access the Tesla first, which made it more difficult than many other hacks. Once they were connected through an Ethernet cable, they were later able to access the systems from afar.
This allowed them to take control of the screens. They were able to manipulate the speedometer to show the wrong speed, lower and raise the windows, lock and unlock the car and turn the car on or off.
“We shut the car down when it was driving initially at a low speed of five miles per hour. All the screens go black, the music turns off and the handbrake comes on, lurching it to a stop,” said Mr Rogers.
But when the researchers experimented with hacking the car at a higher speed, Tesla safety measures ensured they could not put the handbrake on. Instead, all the screens went blank, the car dropped to neutral and the driver maintained full control of the steering, giving them the opportunity to drive to the side of the road.
Tesla is issuing a patch to fix the flaws that all drivers will have by Thursday. The company said drivers will be able to download the updates via WiFi or a cellular connection.
This was another key safety feature that earned Tesla praise from the security researchers. Many carmakers did not have the ability to automatically send software updates to cars without drivers having to take the car to a dealership or mechanic.
Mr Mahaffey called on every car company to create an “over the air update” process, to install strong separation between the internet-connected entertainment network and the systems that control driving and ensure strong security on each element of the car.
He warned that “the internet is a hostile place for the uninitiated”, such as carmakers that have little experience with online security.
“They tend to look at their peers and they all do what each other is doing,” he said. “If no one has done a great job with security they are jumping off a cliff swiftly to their doom.”