"Tesla pushed a patch yesterday." These words were spoken by Kevin Mahaffey as he began his presentation, along with Marc Rogers, which was a fact filled, tightly-crafted talk on hacking the Tesla S car. At DefCon last weekend, they described six vulnerabilities in the systems they examined, ranging from minor to serious. What was different about Tesla's architecture from other car companies was that security consideration was given to the design of the subsystems and network.
Mahaffey made the point that hacking a car is not like hacking other computers, or "not like getting stuff off the DefCon network" (which received great applause), because car malfunctions can be lethal. That is shown in the rules of engagement he and Rogers observed, though some of that was later modified to include the Tesla bug bounty program.
Mahaffey and Rogers audited three systems: the CID (Central Information Display), the IC (Instrument Cluster), and the gateway, and they were able to compromise these with initial physical access. Though there was a USB port on the backside and two memory cards on the CID board, these weren't useful in the overall compromise. Eventually, they were able to remotely open and close the trunk, unlock and lock the doors, and start and stop the car.
The browser they found in the CID was Qt WebKit-based, and several years old, and thus was subject to several known vulnerabilities, including a JavaScript sort vulnerability. They were able to cause browser crashes, but not reliable memory reads or writes. They could not use the USB interface to extract firmware because they didn't have the password, though they could put the system into the Tegra chip's recovery mode. They found no obvious Wi-Fi vulnerability, but did note that the car attempts to connect to an OpenVPN server when connected to the Internet, but was not vulnerable to their man-in-the-middle attacks (MiTM). As shown in the diagram, they looked at the Certificate Authority (CA) chain to see if the car and server certificate chained to the same root.
Their attempts to impersonate the server failed, as Tesla did use proper validation here.
Aside from the headers and possible interfaces on the infotainment system, they found a mysterious, non-standard connector. After some teeth gnashing, they determined this was an Ethernet port using a non-standard configuration, and so were able to gain access to the car's internal network. In the middle of their audit, others reported this open port, and Tesla issued an update that prevented this port from communicating with the car's LAN. Cleverly, Mahaffey and Rogers simply used an external switch, and jury-rigged a modified Ethernet connector between the IC, their external switch, and the car's internal switch. They now had access again.
Once they had access to the internal LAN, they were able to identify over 30 services running. Two services in particular were vulnerable, because they were so out of date: an insecure DNS proxy, and an insecure mini httpd. However, these services were not useful. What was useful was the fact that both the IC and the CID were running an unsecured X11 service, with no access control. Anyone with internal LAN access could arbitrarily change displays. Tesla has now patched this.
Finally, Mahaffey and Rogers identified some services, the updater services, which eventually led them to the URL where they could download firmware. For this, they had to use the VPN keys, obtained from the memory card examined above, and the OpenVPN configuration information, from their failed earlier MiTM attempt.
The firmware was in SquashFS format, and provided much useful information. Analysis of the firmware revealed no private keys, but did reveal a shadow file for the IC. The encryption was weak, and a number of passwords were cracked. Among other observations, there was a log rotate system, that one might find in a datacenter server, and a URL that included the string "knights-who-say," and the answer back was many hundreds of the word "ni." (Tesla engineers are Monty Python fans!)
They needed to get root on both the IC and CID. They did this by observing that the CID receives a random security token every 24 hours from Tesla, which becomes the new password, and then relays this information to the IC, which stores this as plaintext. This password could be used to log into the CID, which had sudoer level access. Mahaffey and Rogers wrote a script to gather the keys every 24 hours, having OpenVPN access (so no disassembly needed), and they could maintain access. They were also able to reactivate the Ethernet port by sending a key based on the now-discovered token via UDP.
Because there were many UDP messages on the car's LAN, in the range of 500/sec, they needed to automate a way of examining these messages. That software, called tescat, is available on Github, and separates out unique messages. From this they were able to discern that messages sent to the gateway may perform only allowed actions, via a vehicle API. No raw frames from the CAN bus were on the network (which is very good, from a security point of view).
Using this information, and injecting messages, they were able to shut off the car and brake if going below 5 mph, and the screen shuts off; above 5 mph, they could only put the car into neutral and coast to a stop; the screen displayed a warning message. The driver retained control of brakes and steering.
Tesla has patched numerous vulnerabilities, including the browser and various subsystems. As Tesla can patch over the air, there's no need for car service. The OpenVPN is properly configured, but the Wi-Fi WPA system uses a static password. Overall, the Tesla security architecture is good, but individual components should have additional hardening, some of which has been addressed by Tesla patches. Mahaffey's and Roger's goal was to further the security involvement in car design and make increasingly computerized cars safe to drive.
The presentation had a partial feel of being co-opted by Tesla, possibly because of the 20 or so Tesla employees sitting in front, the 60 Minutes reporter and television crew (who were asked to leave DefCon for rules violation), and the Tesla employees who joined the presenters on stage for the last few minutes. Later, a Tesla factotum told me that not all the slides would be available.
Follow us @tomshardware, on Facebook and on Google+.
