Key Lessons for Auto Manufacturers from the 2021 Tesla Hack

In 2021, researchers Ralf-Philipp Weinmann and Benedikt Schmotzle demonstrated a remote, zero-click exploit against a fully up-to-date and patched Tesla. Their method involved deploying the exploit on a quadcopter drone, requiring only proximity to a vulnerable car to execute the attack, manipulate doors, and gain control.

How do the world's best hackers unearth zero-day vulnerabilities like this? Their process usually involves three key steps:

1. Map out the attack surface.
2. Find a new vulnerability and develop an initial proof of concept exploit.
3. Weaponize that exploit.

In this blog post, we’ll talk about the methodologies and techniques involved in exploiting vehicle systems, using these three steps as a framework and using the 2021 Tesla exploit as an example. 

‍

Step One: Map Out The Attack Surface

The first step in offense is to understand the attack surface. The term “attack surface” refers to the collection of all possible points where an unauthenticated attacker might attempt to gain initial access. 

Let’s look at the attack surface for modern vehicles.

The modern car is essentially a network of computers. On this network are potentially hundreds of individual computers called electronic control units, or ECUs for short. ECUs like the NXP S32K3 are small complete computers with onboard processors, memory, and network interfaces.

Overall car architecture includes two different networks connected together via Gateway. 

The first network is the frontend network, which hosts ECUs for modern infotainment, connectivity, and telemetry—basically everything user-facing. The frontend is what actually provides the Wi-Fi hotspot, Bluetooth, and LTE services to you and to the rest of the car. Frontend ECUs communicate over Ethernet and typically run a Linux or a Linux-like system. Once you understand the frontend, you can then trace different possible attack paths from the user-facing services to ultimately taking over the car.

‍

The second on-car network is the back end, which connects more specialized ECUs like those that manage your seat belts and airbags and actually control the car. The back end typically includes the safety-critical components. ECUs on the backend often run an embedded OS like VxWorks and typically communicate using a CAN or CAN FD protocol. For example, the back end airbag ECU may want to tell the door ECU to unlock and then request the front end contact emergency services to send help to you.

The gateway connects the two different networks together and also provides some firewall capabilities, but by no means should be considered foolproof.

‍

Mapping the Attack Surface: The Tesla Hack

In the Tesla hack, the researchers focused on the central information display, or CID, running on the front end. The CID is Tesla's way of providing infotainment and telemetry and remote access to the overall car, all in one. 

The researchers focused on a CID application called connman, short for connection manager. Connman is a Linux app that provides DHCP, HTTP, whisper, and several other services. 

Connman is not a Tesla-specific program. In fact, half the automotive industry uses connman, and it's the reference implementation on automotive frameworks such as automotive-grade Linux and GenIVI.

‍

Step Two: Find a new vulnerability and develop an initial proof of concept exploit.

‍

Once researchers identified connman, they looked up known vulnerabilities, but there hadn't been one in over four years. That doesn’t mean it's safe though. The researchers just needed to find a new zero day. 

Lead vulnerability researchers use the same process used by dozens of elite hackers to find zero day vulnerabilities:

1. Look for the happy and tested code paths. Skip these. They're well tested and likely everything works. 
2. Identify untested or under-tested code. This is where the risk lies. 
3. Write tests for that untested code. 

Why write tests when looking for vulnerabilities? An exploit is just a test case for the unexpected. In particular, a proof of concept exploit needs to demonstrate that vulnerable code exists and that the vulnerable code is reachable. A test case does just that. 

Brute forcing through all the different code paths manually is expensive, error-prone, and unscalable. Instead, attackers often use dynamic analysis to automatically help them explore code and find new vulnerabilities, with coverage-based fuzzing being the most popular technique.

‍

Using Mayhem to Develop an Initial Proof of Concept Exploit

You can recreate the initial proof of concept test for the Tesla code using Mayhem. Mayhem uses advanced dynamic analysis techniques, including symbolic execution and fuzzing to automatically generate thousands of tests to identify defects in code. Mayhem handles vulnerability diagnosis, triage, reporting, and regression testing within a Docker container for scalability and reproducibility.

Utilizing multiple CPU cores, Docker enables Mayhem to scale its analysis. Accuracy is ensured by checking proof of concept exploits in the exact Docker environment used for analysis, eliminating false positives. Simply provide Mayhem with your Docker container location and click Go.

Mayhem allocates a worker node for analysis, identifies tested code, and generates new tests, progressively increasing code coverage. In fact, we've had one customer use Mayhem to meet up to 80% of their compliance-required coverage needs on applications. When a vulnerability is detected, Mayhem triages the bug, records the proof of concept exploit, and, upon patch creation, replays the exploit to ensure effective resolution without regressions.

‍

Developing an Initial Proof of Concept Exploit: The Tesla Hack

The Tesla hack was primarily due to a typical buffer overflow vulnerability. When connman receives a DHCP reply, it calls an uncompressed routine and copies the uncompressed data to a new buffer. However, the program does not perform sufficient bounds checking, which an attacker can use to perform a full control flow hijack exploit.

‍

Step 3: Weaponize the Exploit.

The initial proof of concept demonstrated the vulnerability but didn't provide an end-to-end exploit that owned the overall car.

To get there, the researchers had to solve at least two problems.

One problem was the connman vulnerability could only be triggered via DHCP, so the researchers needed to get the Tesla to make a DHCP request to a device they controlled. They discovered Teslas will automatically attach to any Tesla service access point and solved the DHCP problem by impersonating that access point on their quadcopter drone.

Second, connman was built with several application security defenses enabled, such as address space layout randomization and stack cookies. These defenses make it more difficult to initially weaponize a proof of concept into a full system hijack. 

The researchers were able to bypass these mitigations by finding and utilizing several other low severity vulnerabilities. For example, they found a way to bypass stack canaries and another vulnerability they could use to leak address space layout randomization secrets.

The Full Tesla Exploit

The drone advertises a fake Tesla service access point using credentials scraped from the underlying firmware. When the Tesla attaches to the drone, the car requests a DHCP address, and the drone provides a malicious reply. The malicious reply exploits the connman vulnerability and creates a remote shell back to the drone. At that point, the drone can send arbitrary commands to the car, like to open the doors.

Game over.

‍

Takeaways from the Tesla Hack

The 2021 Tesla hack illustrates three takeaways:

1. The safety-critical parts of the system are usually not the entry point.

Instead, attackers compromise something else and then pivot to the safety-critical components. Therefore, if we want to secure our vehicles and our cyber-physical systems, we need to identify those entry vectors and spend more time checking them. In cars, that empirically means we should focus more attention on infotainment and telemetry.

‍

2. “Test like a hacker”.

Application security programs should have two parts: a reactive component that detects known vulnerabilities, like an SBOM, and a proactive component like Mayhem that finds unknown vulnerabilities. The proactive component is the part of your application security testing that “tests like a hacker” to find the “zero day” vulnerabilities in your systems.

‍

3. Defenders have advantages over attackers.

Attackers have to map out the attack surface from scratch, reverse engineer firmware, and figure out how to circumvent exploit mitigations. Defenders don't need to do all that. As defenders, we know what's exposed on the network, and we have better access to the code we put on our systems. 

We should take advantage of this by spending our time building better CI/CD pipelines, doing more software in the loop testing, and putting more time into finding new vulnerabilities and squashing them before attackers.

‍

Proactive Cybersecurity for Connected Vehicles

By dissecting the three key steps involved in the Tesla exploit—mapping out the attack surface, discovering a new vulnerability, and weaponizing the exploit—we gain valuable insights into the methodologies of elite hackers. 

The Tesla hack also highlights the importance of proactively testing systems for both known and unknown vulnerabilities. Employing advanced tools like Mayhem for dynamic analysis along with a tool that detects known vulnerabilities, such as an SBOM, and fortifying defenses against potential entry points provides a robust security strategy. Ultimately, understanding the attack surface and leveraging our inherent advantages as defenders can empower us to stay ahead of emerging threats, build robust cybersecurity frameworks, and ensure the safety of connected vehicles.