Remote Exploitation of Nissan Leaf: Controlling Critical Body Elements from the Internet

Remote Exploitation of Nissan Leaf: Controlling Critical Body Elements from the Internet

Speakers: MK, Senior Security Researcher, Automotive PCA; Rad Modzman, Senior Security Researcher, Automotive PCA; Alsa Palina

Conference: Black Hat Asia

YouTube: https://www.youtube.com/watch?v=Y3fF1WUQL6s

Overview

This talk, presented by MK and Rad Modzman from Automotive PCA, details a comprehensive remote exploitation chain against a 2020 Nissan Leaf, enabling an attacker to gain full control over the vehicle's infotainment system and subsequently manipulate critical body elements from the internet. The researchers systematically uncovered and chained multiple vulnerabilities, starting with a Bluetooth-based remote code execution (RCE) on the infotainment unit, achieving persistence, bypassing secure boot mechanisms, and ultimately compromising an internal ECU responsible for CAN bus communication.

The significance of this research cannot be overstated. It demonstrates a complete end-to-end attack that transitions from a seemingly innocuous Bluetooth vulnerability to the ability to control safety-critical functions like doors, wipers, and even the steering wheel of a moving vehicle remotely. This highlights profound security deficiencies in modern automotive architectures, particularly concerning the isolation and hardening of infotainment systems from critical vehicle control networks. The findings underscore the urgent need for robust security-by-design principles, rigorous penetration testing, and effective vulnerability management across the automotive supply chain.

Background

▶ Watch: Talk Introduction: Remote exploitation of Nissan Leaf. (0:00)

The target of this extensive vulnerability research was a 2020 Nissan Leaf, a representative modern electric vehicle. Like many contemporary cars, the Leaf's architecture incorporates several interconnected Electronic Control Units (ECUs): a Gateway Unit for filtering and routing CAN packets, a Telematic Unit for cellular communication, and an Infotainment System (referred to as EV) providing various connectivity features such as Wi-Fi (client mode only), USB, Bluetooth, Apple CarPlay, Android Auto, and navigation.

To facilitate their research, the team built a dedicated test bench. Initial attempts to purchase components from eBay were hampered by "component protection," a security feature preventing units from different vehicles from communicating. To overcome this, the researchers acquired all necessary units—including the EV, gateway, Body Control Module (BCM), and instrument cluster—from a junkyard. This allowed them to assemble a functional test bench.

A crucial early hurdle was bypassing the anti-theft protection implemented in the Nissan Leaf EV. This mechanism prevents unauthorized access or theft of the head unit by locking its functionality. When the EV powers on, it must solve a special anti-theft challenge by communicating with a designated ECU over the CAN bus. Failure to receive a response results in a "green error," while an incorrect response yields a "red error." The communication involves the EV sending a function number, a seed value, a constant data blob, and a checksum. The ECU responds with the same function number, a calculation result, and its own checksum. The checksum is calculated as the sum of all bytes in the message payload, excluding the last two.

To bypass this, the researchers analyzed runtime CAN communication and discovered that the seed's maximum value was 0x20. This limited range allowed them to build a solution table mapping every possible seed to its correct challenge response. They then implemented a Python script that emulated the anti-theft ECU, providing the correct calculation results to the EV and effectively bypassing the protection, enabling them to boot any Nissan Leaf EV on their test bench.

Hardware analysis of the EV unit revealed several key components. The main CPU is an NXP i.MX 6 processor, specifically a quad-core Cortex-A9 running a Linux operating system. A Renesas RH850 microcontroller handles CAN communication, acting as an intermediary between the i.MX 6 and the vehicle's CAN buses via an SPI connection. Storage is provided by an eMMC NAND chip for the main root file system and Cypress SPI memory chips for boot images. Interestingly, the Wi-Fi and Bluetooth chip, manufactured by Alps Alpine, is located on the Human-Machine Interface (HMI) PCB rather than the main EV PCB. The i.MX 6 also has a dedicated driver for communication with the RH850. The telematic unit is connected directly to the i.MX system.

Key Findings

▶ Watch: Examining Nissan Leaf's anti-theft protection implementation. (2:52)

The research uncovered a series of critical vulnerabilities that, when chained together, provided full remote control over the Nissan Leaf:

1. Multiple Stack-Based Buffer Overflows in Bluetooth: The infotainment system's proprietary Blue Dragon evolution Bluetooth stack was found to be vulnerable. Despite ASLR being nominally enabled, Bluetooth libraries were loaded at fixed addresses, rendering ASLR ineffective. Crucially, stack canaries were disabled for all Bluetooth libraries. Attackers could exploit these overflows, particularly in the handsfree_parse_response function, to achieve arbitrary code execution as root.

1. Kernel Compression and Debugging Bypass: The researchers discovered a custom LZ77 compression algorithm used for the Linux kernel image. By reverse engineering the U-Boot bootloader and emulating its decompression routine, they extracted the kernel. They then identified and disabled a custom kernel driver, XC H&D (exception handler driver), which was configured to reboot the system upon catching SIGTRAP signals, thus hindering debugging efforts.

1. Persistence through Secure Boot Bypass: To maintain access across reboots, the team explored several persistence mechanisms. While a symlink trick could enable SSH, a more robust solution involved bypassing the i.MX High Assurance Boot (HAB) secure boot chain. Instead of exploiting a complex stack overflow in HAB, they opted for a simpler method: modifying the Device Tree Blob (DTB) to include the dm-verity.ignore_corruption boot argument. This allowed them to modify the root file system at will, injecting their code into startup scripts.

1. Data Exfiltration via DNS Tunneling: Once persistence was established, the telematic unit was leveraged for internet connectivity. Observing that DNS requests were not filtered, the researchers used dnscat2 to establish a stealthy command-and-control (C2) tunnel over DNS, allowing them to control their persistent code on the EV from anywhere.

1. Renesas RH850 Firmware Vulnerability and CAN Bus Control: The team identified a stack overflow vulnerability within the RH850 microcontroller's firmware, specifically in the net_broadcast service, which communicates over the NxC (Network Communication) interface. Exploiting this vulnerability allowed them to achieve code execution on the RH850. With code execution on the RH850, they gained the ability to send arbitrary CAN messages.

1. CAN Gateway Filtering Failure: A critical flaw was found in the vehicle's gateway unit. Despite its role in filtering CAN traffic, diagnostic CAN messages with specific UDS (Unified Diagnostic Services) IDs were permitted to pass from the infotainment system to critical CAN buses, including the vehicle, ADAS (Advanced Driver-Assistance Systems), and chassis buses. This bypass allowed the attackers to send UDS commands directly to various ECUs.

1. Remote Manipulation of Critical Body Elements: By capturing UDS commands using a commercial diagnostic tool (CONSULT-III), the researchers identified specific commands that could manipulate safety-critical vehicle components. Chaining all these vulnerabilities, they demonstrated the ability to remotely control elements such as doors, wipers, the horn, and even the steering wheel of a Nissan Leaf from the internet.

Technical Deep Dive

▶ Watch: Python script to bypass Nissan Leaf anti-theft. (4:00)

The attack chain commenced with the Bluetooth stack on the Nissan Leaf EV. The infotainment system utilizes a proprietary Blue Dragon evolution stack, implemented as a 32-bit ARM ELF executable running with root permissions. While PIE (Position-Independent Executables) and ASLR (Address Space Layout Randomization) mitigations were theoretically enabled, the researchers discovered that all Bluetooth libraries were loaded at fixed, predictable addresses, effectively nullifying ASLR. Furthermore, stack canaries were disabled for all these libraries, a critical oversight.

The vulnerability was located in the Hands-Free Profile (HFP), which manages audio calls. Specifically, the function handsfree_parse_response (a decompiled representation) was responsible for parsing AT commands. When processing an "Android comment response" with a "prop" operation, the function used get_parameters to extract parameters. It then copied the first parameter into a stack buffer (params) using memcpy. Crucially, while a lower bound validation was present, there was no upper bound validation for the parameter length (prop_lens). This allowed an attacker to send an oversized parameter, leading to a stack-based buffer overflow. The researchers also identified similar overflows in other Android comment response operations, "audio source" and "VDS," indicating multiple points of failure.

Exploitation of this stack overflow was "quite trivial" due to the absence of stack canaries. The attackers crafted a ROP (Return-Oriented Programming) chain to execute the system() function with a controlled payload. Despite some restrictions on certain bytes within the ROP payload, these did not significantly impede exploitation. To store the system() function's payload without increasing the ROP chain's complexity or violating byte restrictions, the researchers leveraged another Bluetooth profile: AVCTP (Audio Video Transmission Profile). AVCTP communication is fragmented, utilizing a global fragmentation message buffer whose address was known due to the fixed loading addresses of Bluetooth libraries. This buffer became the ideal location to store their shell command.

The system() function payload itself faced a challenge: the system's firewall, based on IPTables rules, discarded most outbound connections. However, since the Bluetooth service runs with root permissions, their ROP chain also executed as root. This allowed them to modify the IPTables rules, specifically removing the DROP rules for outbound connections. Following this, the exploit forced the power supplicant to connect to an attacker-controlled Wi-Fi access point, and then a reverse shell was launched over TCP/IP. This entire process resulted in a 100% stable root reverse shell on the EV with a "one-click" Bluetooth exploit (or "0.5 clicks" if jamming was used to force the user to open the Bluetooth pairing menu).

With root access, the researchers began exploring persistence. The system ran an old U-Boot bootloader and a Linux kernel version 3.14, with ASLR disabled. DM-Verity was in place for file system integrity control, preventing arbitrary file modification. Before tackling persistence, debugging was necessary, but GDB breakpoints caused the system to reboot. This led to the discovery of a custom kernel driver named XC H&D (exception handler driver). After extracting the compressed kernel image (which used a proprietary LZ77 variant, requiring U-Boot emulation with QEMU to decompress), they found XC H&D was designed to catch exceptions (like SIGTRAP) using K-props and J-props, triggering a system reboot. The solution was to either unregister the K-props or call the driver's exit function from a custom kernel module, which was possible due to root privileges.

For persistence, initial attempts involved exploiting logic issues in configuration files, such as enabling the SSH server via the ALD (Authorization Level Daemon) service by creating an SSH_ENABLED file. However, newer EV versions introduced Tatai_SSH_Checker_Serv, which deleted this file if the security level was too low. The researchers cleverly bypassed this by creating a symlink named SSH_DISABLED pointing to SSH_ENABLED. When Tatai_SSH_Checker_Serv attempted to touch SSH_DISABLED, it inadvertently created SSH_ENABLED through the symlink, ensuring SSH was started.

A more robust persistence method involved compromising the secure boot chain. The i.MX processor uses HAB (High Assurance Boot). While a known stack overflow vulnerability exists in HAB during CSF (Common Seconds File) certificate processing, exploiting it was deemed too complex. Instead, they found an easier way: modifying the DTB (Device Tree Blob). By injecting the dm-verity.ignore_corruption parameter into the DTB's boot arguments, they forced the system to skip hash validation errors during boot, allowing them to modify the root file system and inject their code into startup scripts (/var/script) for execution on every system boot.

For data exfiltration and C2, the EV's internet connection via the telematic unit was utilized. Observing that outbound DNS requests were not filtered, the team employed dnscat2 to establish a secure tunnel over DNS to their backend TCP server, providing stable internet control of the EV.

The final stage of the attack chain focused on gaining CAN bus access from the EV. The RH850 processor connects the i.MX system to the CAN bus via an SPI bus. The legitimate way the EV communicates with the CAN bus is through the CSM service, which sends messages over the NxC (Network Communication) interface. NxC is a point-to-point communication subsystem defined in the Bosch SDK, operating over SPI. Clients communicate with an NxC network device driver, which passes requests to an SPI block device driver. The CSM service uses specific NxC ports (e.g., for signal or request messages) to send CAN messages. These requests contain bus_type and internal_address fields, which map to predefined CAN IDs within the RH850 firmware. This legitimate interface, however, only allowed sending messages with predefined CAN IDs, not arbitrary ones.

To achieve arbitrary CAN message transmission, the RH850 firmware itself needed to be compromised. The RH850's firmware update process involves the i.MX updating it via a proprietary DNL binary format over the NxC download port, using UDS requests. The firmware is validated by a signature. The researchers obtained the RH850 firmware file and analyzed its services, each linked to an NxC port. They found a vulnerability in the net_broadcast service. Its request processing involved a callback that copied input data into a stack-allocated buffer in a loop. Crucially, this loop was only limited by the packet size, not the stack buffer's capacity, leading to a stack overflow. This overflow could overwrite the saved Link Register (LR), which acts as the return address in the RH850's ARM architecture.

Exploiting this on the RH850 was straightforward: no ASLR or stack canaries were present. Shellcode was placed in global memory (using a "delta request" over NxC), and the LR was overwritten with the shellcode's address. A challenge arose because the CSM service constantly used the net_broadcast port. Killing CSM would trigger a watchdog and reboot the EV. The solution was to inject their exploit code directly into the CSM service, which was possible due to having root access and having disabled signal handlers in the kernel. With code execution on the RH850, they could now send arbitrary CAN messages.

Finally, the team tested the CAN gateway rules. By brute-forcing CAN IDs, they discovered that CAN messages with diagnostic IDs (UDS) could be passed from the EV to critical buses such as the vehicle, ADAS, and chassis buses, bypassing the gateway's filtering. To identify specific UDS commands, they used a CONSULT-III tool, capturing its USB traffic while controlling various car elements. This yielded a list of UDS commands for manipulating mirrors, doors, wipers, the horn, and the steering wheel. With arbitrary CAN message sending capability on the RH850 and knowledge of these UDS commands, they could now remotely control these critical body elements from the internet.

Demo / Proof of Concept

▶ Watch: Deep dive into Nissan Leaf EV hardware architecture. (4:18)

The researchers provided a compelling video demonstration of their attack chain on a real Nissan Leaf in their lab. They developed a custom server and user interface for remote vehicle control, showcasing the end-to-end capabilities of their exploit.

The demonstration highlighted several critical functionalities they could control:

• GPS Tracking: Displaying the vehicle's real-time location.
• Infotainment Defacement: Altering the content displayed on the car's screen.
• Audio Recording and Playback: Recording ambient audio inside the vehicle and playing it back through the car's speakers or downloading it.
• Screenshot: Taking screenshots of the infotainment display.
• Body Controls: Remotely activating the car's horn, folding and unfolding the side mirrors, operating the windshield wipers, and even controlling the steering wheel.

The video clearly illustrated the progression from gaining initial access to the infotainment system to ultimately manipulating safety-critical physical components of the vehicle, underscoring the severe implications of their findings. The demonstration concluded with the team reiterating that all actions were performed for demonstration purposes only.

Defensive Implications

▶ Watch: Bluetooth stack analysis: Blue Dragon and ISLR bypass. (6:38)

The findings from this research present a stark reminder of the security challenges in modern automotive systems and offer several key defensive implications for both manufacturers and tier-one suppliers:

1. Robust Input Validation on All Interfaces: The Bluetooth stack vulnerabilities stemmed from insufficient input validation. All external and internal communication interfaces, especially those handling vendor-specific protocols like AT commands, must implement strict length and content validation to prevent buffer overflows and other memory corruption issues.

1. Effective Memory Safety Mitigations: The absence of stack canaries and the ineffective implementation of ASLR (due to fixed library loading addresses) were critical enablers for exploitation. Manufacturers must ensure that all executable components, especially those processing untrusted input, are compiled with robust memory safety mitigations such as stack canaries, ASLR/PIE, and Data Execution Prevention (DEP), with randomized base addresses effectively enforced.

1. Strengthened Secure Boot and DM-Verity: The bypass of secure boot via DTB modification and dm-verity.ignore_corruption highlights weaknesses in the integrity protection mechanisms. Secure boot chains must be meticulously implemented to prevent any unauthorized modification of boot-critical components, including the DTB. DM-Verity should be configured to prevent bypasses and ensure that file system integrity is non-negotiable.

1. Strict CAN Gateway Filtering: The gateway's failure to filter diagnostic UDS messages from the infotainment unit to critical CAN buses is a severe design flaw. Gateways must operate on a principle of least privilege, with explicit, highly restrictive rules for what traffic can pass between different security domains. Diagnostic commands, particularly those affecting critical vehicle functions, should require multi-factor authentication and only be accessible through trusted, physically isolated diagnostic ports or highly secured and audited remote channels.

1. Hardening of ECUs: The Renesas RH850 microcontroller's firmware was vulnerable to a stack overflow. All ECUs, regardless of their perceived criticality, must undergo thorough security assessments. Firmware should be developed with memory safety in mind, employing mitigations like stack canaries and potentially even micro-kernel architectures or isolated execution environments where feasible. The NxC interface handlers must also implement strong input validation.

1. Principle of Least Privilege for All Processes: The Bluetooth stack running with root permissions allowed the attackers to modify firewall rules. Processes should run with the absolute minimum necessary privileges. Network access, especially outbound connections, should be strictly controlled by firewall rules that cannot be easily circumvented or modified by potentially compromised user-space applications.

1. Supply Chain Security and Transparency: The involvement of a tier-one supplier (Bosch) in developing components vulnerable to attack underscores the need for greater transparency and collaboration across the automotive supply chain. Manufacturers need better visibility into the security posture of components from their suppliers, and suppliers must be able to track and communicate which vehicle models incorporate vulnerable components. This includes comprehensive vulnerability disclosure and patching processes that span multiple vendors and vehicle models.

1. Physical and Logical Segmentation: Critical vehicle networks (e.g., powertrain, chassis, safety systems) must be physically and logically segmented from less critical networks (e.g., infotainment). Communication between these domains should only occur through hardened gateways that enforce strict security policies.

Key Takeaways

• A 2020 Nissan Leaf was found to be vulnerable to a full remote exploitation chain, allowing internet-based control of critical vehicle functions.
• The initial compromise leveraged multiple stack-based buffer overflows in the proprietary Blue Dragon evolution Bluetooth stack, achieving root code execution on the infotainment system due to disabled stack canaries and ineffective ASLR.
• Persistence across reboots was established by bypassing the i.MX High Assurance Boot (HAB) secure boot mechanism, specifically by modifying the Device Tree Blob (DTB) to ignore DM-Verity corruption.
• Further exploitation involved a stack overflow vulnerability in the Renesas RH850 microcontroller's firmware, granting arbitrary CAN message sending capabilities.
• A critical flaw in the CAN gateway allowed diagnostic UDS messages from the compromised infotainment system to reach safety-critical vehicle buses (vehicle, ADAS, chassis).
• The attack culminated in the ability to remotely manipulate physical vehicle elements such as doors, wipers, horn, and steering wheel, underscoring severe safety implications.

About the Speaker(s)

The research was presented by MK and Rad Modzman, both Senior Security Researchers at Automotive PCA. Automotive PCA is a company specializing in vulnerability research and penetration testing services across various industries, including the automotive sector. Alsa Palina was also acknowledged as part of the research team and was present at the talk. Their work demonstrates deep expertise in embedded systems, automotive security, and exploit development.