Hackers compromised Tesla charger to infect rival brands

Malware can easily spread across electric vehicles and charging points, and researchers just showed that.

Hackers from Black Hat have conducted an experiment to infect Tesla. And they succeed by compromising the charging cable.

More troublesome was the fact that the electric vehicle worm was able to jump between Tesla, Autel, and ChargePoint systems with “no human in the loop after launch.”

A security research team has demonstrated a potential worm that can move between electric vehicle chargers and cars without requiring a driver to intervene after the initial compromise.

Tobias Scharnowski, a cybersecurity researcher, detailed the demonstration in a LinkedIn post.

Malware autonomously infected the entire ecosystem

According to Scharnowski, the team was able to compromise the charger through the charging cable using SWCAN, a communication protocol carried over the Control Pilot line.

From there, the compromised charger autonomously exploited the vehicle's infotainment system over WiFi. The researchers then demonstrated a scenario in which the compromised car moved near chargers made by other manufacturers.

The vehicle's infotainment system was used to compromise an Autel MaxiCharger and a ChargePoint Home Flex over Bluetooth.

No real Teslas were infected

The demonstration was conducted in a laboratory using real Pwn2Own devices. The researchers stressed that they did not attack public chargers.

“What we did not demonstrate, and want to be explicit about: internet-wide prevalence of vulnerable versions, propagation across arbitrary vehicles or chargers, or anything approaching grid destabilization,” Scharnowski ensured.

However, the experiment highlights an increasingly important cybersecurity problem that EV ecosystem may face, as an interconnected network of charging stations, mobile applications, cloud services, and wireless protocols potentially creates new attack vectors.

The anatomy of compromise

Researchers explains, that the Tesla charging hardware uses bare-metal firmware on an ARM Cortex-M4 processor. The researchers did not have access to the original source code or debugging symbols.

That makes conventional fuzzing, an automated software testing method that injects random, invalid, or unexpected data into a program, particularly difficult.

When fuzzing directly on the device, the researchers could reportedly send only about one input every few seconds, with limited feedback beyond whether the device continued responding.

The team instead used a technique known as firmware rehosting. Rather than repeatedly testing inputs on the physical hardware, researchers recreated the relevant firmware environment in software.

This allowed them to observe basic block coverage and dramatically increase the number of inputs they could test.

According to Scharnowski, the rehosted environment could process more than 1,000 inputs per second, compared with roughly one input every few seconds on the physical device.

A signed integer contained in the firmware image header was parsed incorrectly, ultimately resulting in an out-of-bounds write to the stack during signature verification. This means that data inside the firmware file could cause the program to write beyond the memory area it was supposed to use.

That kind of memory corruption can potentially give an attacker control over a device, depending on the surrounding protections and execution environment.

The researchers said the vulnerability could be discovered through fuzzing within hours, despite having previously gone unnoticed through analysis of the binary and source code.