Low Energy to High Energy: Hacking Nearby EV-Chargers Over Bluetooth
This talk demonstrates multiple vulnerabilities in electric vehicle (EV) chargers, specifically focusing on insecure Bluetooth Low Energy (BLE) provisioning and command injection flaws. The researchers exploit these weaknesses to gain unauthorized access to the underlying operating systems of JuiceBox 40, Autel MaxiCharger, and ChargePoint Home Flex devices. The findings highlight critical security oversights in IoT device design, including the lack of authentication on management interfaces and the use of dangerous functions like system() with unsanitized input. The presentation provides a practical roadmap for auditing and exploiting similar embedded systems.
How Insecure BLE Provisioning Turned EV Chargers Into Remote Shells
TLDR: Researchers at Black Hat 2024 demonstrated how insecure Bluetooth Low Energy (BLE) provisioning in popular EV chargers allows attackers to gain root access via command injection and buffer overflows. By de-authenticating a charger from its Wi-Fi network, an attacker can force the device back into a vulnerable provisioning state. This research highlights a critical failure in IoT security where management interfaces are left exposed and unsanitized, turning simple charging stations into potential entry points for network-wide compromise.
Electric vehicle infrastructure is expanding at a breakneck pace, but the security of the hardware powering this transition is lagging behind. While we often obsess over the security of the vehicle itself, the charging stations—often installed in public or semi-public spaces—are frequently overlooked. The research presented at Black Hat 2024 on the JuiceBox 40, Autel MaxiCharger, and ChargePoint Home Flex proves that these devices are essentially poorly secured Linux servers bolted to a wall.
The BLE Provisioning Trap
The core issue identified in this research is the reliance on insecure BLE provisioning. Manufacturers often use BLE to simplify the initial setup process, allowing a user to pass Wi-Fi credentials from a mobile app to the charger. However, the researchers found that this provisioning mode is often poorly implemented and, more importantly, can be triggered remotely.
By sending de-authentication frames to the charger’s connected Wi-Fi access point, an attacker can force the device to drop its connection. When the charger fails to reach its management server, it often defaults back to its provisioning state, re-enabling the BLE interface. This transition is a classic example of a "fail-open" design flaw. Once the BLE interface is active, an attacker within range can interact with the device’s management services, which often lack any form of authentication.
From Buffer Overflows to Root Shells
The researchers discovered that these chargers are riddled with memory corruption vulnerabilities. In the case of the JuiceBox 40, they identified a stack-based buffer overflow in the logging routine, tracked as CVE-2024-23938. The device uses a fixed-size stack buffer to format log messages, but it fails to validate the length of the input data before copying it. By providing a specially crafted string with multiple @t tags, an attacker can overflow the stack and overwrite the saved return address, leading to arbitrary code execution.
The Autel MaxiCharger presented a similar, albeit more subtle, issue. The researchers found a stack buffer overflow in the service handling charging control parameters, CVE-2024-23958. The device copies a Bluetooth message into a 60-byte stack buffer without checking the length. Because the device runs on a real-time operating system (RTOS) without modern protections like stack canaries or Address Space Layout Randomization (ASLR), exploitation is straightforward.
For the ChargePoint Home Flex, the vulnerability was a classic command injection. The device uses the wpa_passphrase utility to configure Wi-Fi connections. The researchers found that the input parameters for the SSID and password were passed directly to the system() function without any sanitization.
// Simplified representation of the command injection vulnerability
snprintf(command, 0x100u, "/usr/sbin/wpa_passphrase '%s' '%s'", ssid, password);
popen_res = popen(command, "r");
By injecting shell metacharacters into the password field, an attacker can execute arbitrary commands with root privileges. This is a textbook example of OWASP A03:2021-Injection.
Real-World Impact and Defensive Reality
For a pentester, these findings are a goldmine. If you are tasked with assessing a facility's security, don't just look at the corporate network. Walk the parking lot. If you find an EV charger, you have a potential pivot point into the internal network. Once you have a root shell on the charger, you can use it to sniff traffic, perform man-in-the-middle attacks on other devices, or simply use the charger's existing credentials to access cloud resources.
The researchers demonstrated that the ChargePoint Home Flex, for instance, uses an AWS IAM role to communicate with cloud services. By exploiting the command injection, they were able to query the metadata service and retrieve temporary security credentials, allowing them to list S3 buckets and potentially access sensitive data.
Defending against these attacks is difficult because the vulnerabilities are baked into the firmware. For manufacturers, the lesson is clear: stop using dangerous functions like system() and implement proper input validation. If you are a security professional working with these devices, the best defense is network segmentation. Ensure that your EV charging infrastructure is on a dedicated, isolated VLAN with no access to your critical internal assets.
What Comes Next
This research serves as a stark reminder that "smart" devices are often just "insecure" devices with a network connection. The fact that researchers could go from finding a vulnerability to a full exploit in just 12 hours on the ChargePoint device should be a wake-up call for the entire industry.
If you are auditing IoT devices, start by looking at the provisioning process. How does the device handle the transition between states? Does it revert to a default, unauthenticated mode when it loses connectivity? These state transitions are where the most interesting bugs are hiding. Don't assume that because a device is "industrial" or "commercial" that it has undergone a rigorous security review. Often, the opposite is true. Keep digging, and keep testing the assumptions that manufacturers make about their own security.
Vulnerability Classes
Target Technologies
Attack Techniques
OWASP Categories
All Tags
Up Next From This Conference
Similar Talks

Kill List: Hacking an Assassination Site on the Dark Web

Hacking Apple's USB-C Port Controller




