Advancing Vulnerability Discovery Amid Automotive Innovation: A Tale of Two EV Charger Vulnerabilities

January 19, 2024
Advancing Vulnerability Discovery Amid Automotive Innovation: A Tale of Two EV Charger Vulnerabilities

By Jonathan Andersson (Senior Manager – Security Researcher, Zero Day Initiative)

In this two-part blog series, we examine three scenarios that highlight the significance of vulnerability discovery and shed light on the potential cyberthreats if vulnerabilities are not promptly addressed. In this first installment, we delve into two of those scenarios as we detail the work done in the realm of electric vehicle (EV) chargers by researchers from Trend Micro’s Zero Day Initiative (ZDI) program, VicOne’s co-host for the first-ever Pwn2Own Automotive.

Home charger firmware extraction

In this first scenario, we demonstrate how we can extract the firmware from a home EV charger that we have physical access to. This is important to examine because extracting the firmware is the first step toward performing deeper research into a device and discovering its security flaws.

Firmware is typically stored in a persistent memory device like a NAND. Therefore, the extraction process involves reading and copying the firmware image stored in the device’s memory. To do so, we use JTAG, an industry standard and widely used protocol found in printed circuit boards. JTAG has direct access to a device’s memory, and it could allow a researcher (or potential attacker) to bypass any protection mechanisms like encryption and authentication.

Physical access to the device is necessary for this scenario. With access to the device, we locate the Atmel CPU, a serial console, the NAND flash, and the JTAG debug port. We are also able to gather all of the information that we need to extract the firmware. We note key information from the bootloader and the Linux console, where we get the start and end addresses in NAND of each partition.

Figure 1. The firmware extraction process

Figure 1. The firmware extraction process

Using JTAG tools, we are able to communicate with the charger. As shown in Figure 2, we first use the JTAGulator to verify the JTAG interface and find out the individual pin functions.

Figure 2. The JTAGulator attached to the target unit

Figure 2. The JTAGulator attached to the target unit

We then use the JLink tool to interface debug software tools with the target CPU. This tool is important because debug software can be used to start and halt processors, set breakpoints in the execution, and view or set memory and CPU register values. Ultimately, the debugger allows us to essentially manipulate the target’s CPU and extract the firmware.

Figure 3. The JLink debugger connected to the target unit

Figure 3. The JLink debugger connected to the target unit

From this point, we use all of the information we have collected to control execution of the nand_loadimage function in the bootloader. When the CPU hits the specific breakpoints, registers are manipulated to cause the bootloader to copy the firmware in NAND to a buffer in SRAM, where the JTAG tool saves it to a file for further analysis.

We have audited six EV chargers, and none have used firmware encryption and only a few have made any attempt to disable or obfuscate JTAG access. Both security strategies must be used to close this security gap.

Privilege escalation exploit

The second scenario shows a case of local privilege escalation exploit on an EV charger controller. The goal is to see if a local user account would be able to gain root access.

Figure 4. The vulnerability exploit process

Figure 4. The vulnerability exploit process

The device used in this scenario ships with a local user account. This local user account can run a script that exports a system report, which runs as root.

Figure 5. The EV charger controller

Figure 5. The EV charger controller

The export script does not check the destination path, nor does it set correct permissions on the export file, so the local user can overwrite the file. This allows us to select a script and choose one in the “sudo” allow-list as the destination. Any commands written to the destination file can then be run as the root user.

Figure 6. The local user gains root access

Figure 6. The local user gains root access

As with the first scenario, this can be prevented by implementing basic security measures or steps — in this case, better auditing of system scripts and security permissions.

The relevance of vulnerability discovery

These two scenarios offer a glimpse at the kind of vulnerability discoveries that will be showcased at Pwn2Own Automotive. The vulnerability disclosures from such discoveries serve to reduce the chances of the vulnerabilities leading to real-world problems for the automotive industry. They give vendors the time and opportunity to work with the security researchers who discovered them in order to address the flaws in their systems.

Putting security first has never been more essential for the automotive industry as it navigates a new era of mobility. The automotive industry is faced with a unique situation where even commonplace cyberthreats and vulnerabilities can have unprecedented consequences, particularly on road safety.

The impact of automotive vulnerabilities is the theme we explore in the second half of this series, which discusses VicOne’s demonstration of a vehicle API attack scenario.

VicOne and ZDI researchers will demonstrate these scenarios live at the inaugural edition of Pwn2Own Automotive, happening from Jan. 24 to 26, 2024, at Automotive World in Tokyo Big Sight, Japan.

Our News and Views

Gain Insights Into Automotive Cybersecurity

Visit Our Blog

Accelerate Your Automotive Cybersecurity Journey Today

Contact Us