Pwn the Leaf: Remote Exploitation of the Nissan Leaf via Bluetooth and CAN Bus

Modern vehicles are essentially data centers on wheels, packed with digital technologies like Wi-Fi, Bluetooth, and cellular connectivity. While these features enhance user experience, they also significantly expand the attack surface. In a recent technical presentation, security researchers from PCAutomotive revealed a full-chain remote exploit of a 2020 Nissan Leaf, demonstrating how a vulnerability in a Bluetooth profile can lead to total control over critical vehicle functions like steering and door locks.

This post explores the technical journey from initial Bluetooth pairing to bypassing secure boot and ultimately injecting malicious commands into the vehicle's internal communication network.

The Entry Point: Exploiting the Bluetooth Stack

The Nissan Leaf's infotainment system (the EV unit) runs a Linux-based operating system powered by an NXP i.MX6 processor. Connectivity is handled by a proprietary stack known as the Blue Dragon Evolution Stack. The researchers focused their analysis on the Bluetooth Hands-Free Profile (HFP), which manages audio calls.

They discovered a stack-based buffer overflow in the handsfree_parseResponse function. When the system receives vendor-specific AT commands (such as those used for Android integration), it attempts to parse the parameters without properly validating the upper bounds of the input buffer.

Technical Deep Dive: The Exploit Strategy

Because stack canaries were disabled and the shared libraries were loaded at fixed addresses, bypassing ASLR was trivial. The researchers utilized a ROP (Return-Oriented Programming) chain to call the system() function. A clever trick was used to house the payload: they stored the command string in the global fragmentation buffer of the AVCTP (Audio-Video Transmission Profile), whose address was predictable.

To trigger the exploit, an attacker needs to pair with the car. While this usually requires user interaction, the researchers demonstrated that RF jamming could be used to disconnect a user's phone, provoking them to open the Bluetooth pairing menu—the only window needed for the 'one-click' exploit to succeed.

Bypassing Vehicle Defenses and Persistence

Once root access was achieved on the Linux system, the team faced several hurdles. The first was an anti-debugging kernel driver called XCHND (Exception Handler Driver). This driver was designed to reboot the vehicle if it detected a SIGTRAP or other debugging signals. The researchers circumvented this by loading a custom kernel module to unregister the driver's k-probes.

Secure Boot and DM-Verity

The system employed High Assurance Boot (HAB) and DM-Verity to ensure filesystem integrity. To gain persistence, the team needed to bypass these. They identified a known stack overflow in the HAB's CSF (Command Sequence File) processing. By exploiting this, they forced the bootloader to accept an arbitrary Device Tree Blob (DTB). Within this DTB, they modified the kernel command line arguments to tell DM-Verity to ignore corruption. This allowed them to modify the root filesystem and ensure their malware started on every boot.

For remote control, they utilized the vehicle's Telematic unit. Since the cellular firewall did not block DNS traffic, they established a Command and Control (C2) channel using DNS-CAT2 to tunnel a reverse shell over the internet.

Jumping to the CAN Bus

Attacking the infotainment system is one thing; controlling the car is another. The EV unit communicates with a Renesas RH850 microcontroller via an SPI-based protocol called 'INC' (Inter-Node Communication). This microcontroller acts as the bridge to the CAN bus.

By reversing the RH850 firmware, the researchers found another stack overflow in the NetBroadcast service. Exploiting this gave them code execution on the RH850 itself. From here, they could send raw CAN messages to the vehicle's Gateway.

While Gateway ECUs are designed to filter malicious traffic, the researchers found that diagnostic UDS (Unified Diagnostic Services) commands were allowed to pass through to critical buses (Vehicle, ADAS, and Chassis). Using the Consult 3 dealer diagnostic tool, they sniffed the legitimate UDS commands for various body functions.

Physical Impact: Controlling the Vehicle

With the ability to inject UDS commands through the RH850, the researchers achieved remote control over:

• Mirrors and Wipers: Activating them at will.
• The Horn: Forcing it to sound.
• The Steering Wheel: Manipulating steering inputs remotely.
• Doors: Locking and unlocking the vehicle.

Mitigation and Defense

Following the discovery, the researchers coordinated with Bosch (the Tier-1 provider) and Nissan to patch these vulnerabilities. Key takeaways for automotive security include:

1. Hardening Embedded Binaries: Always enable stack canaries and PIE/ASLR.
2. Gateway Integrity: Gateways must do more than just route packets; they must inspect the context of UDS commands, especially those originating from infotainment systems.
3. Network Filtering: Cellular connections in vehicles should implement strict egress filtering, including DNS.

Conclusion

This research highlights the critical importance of defense-in-depth in automotive architecture. A single vulnerability in a peripheral service like Bluetooth, combined with weak internal security boundaries, can lead to a complete compromise of a multi-ton vehicle. As cars become more connected, the industry must move toward more robust, verified boot chains and stricter isolation between 'fun' features and 'safety' functions.