By Omar Yang (Senior Threat Researcher, Automotive)
At BlackHat USA 2024, security researchers from Computest Sector 7 presented their findings on the various electric vehicle (EV) charger vulnerabilities they discovered during the inaugural Pwn2Own Automotive competition, held by VicOne with the Zero Day Initiative (ZDI) in January 2024. In this blog entry, we focus on the technical details of the JuiceBox 40 smart EV charging station vulnerability CVE-2024-23938 and its security implications for the automotive industry. (Computest Sector 7’s discovery of CVE-2024-23938 was designated a “collision” at Pwn2Own Automotive as it had been previously exploited by and thus credited to another team, Synacktiv.)
Hacking the JuiceBox 40
The first step of hacking a device is always reconnaissance, which involves gathering information about the target. One approach is to “tear down” or physically open the device and check for chips and interfaces. Another method is using open-source intelligence (OSINT) to find pertinent information available online.
The Computest Sector 7 researchers initially examined the JuiceBox 40’s interfaces, or the “attack surface,” from a cybersecurity standpoint. These were also identified by the ZDI’s pre-Pwn2Own Automotive blog post, which provided a detailed look at the EV charger targets in the competition.
According to the JuiceBox 40’s specifications, the device has Wi-Fi for interacting and offering services such as charging scheduling and usage statistics. It also features Bluetooth Low Energy (BLE) to set up the Wi-Fi connection.
During reconnaissance, the researchers found out that someone had already shared a fix of a seemingly nonfunctional JuiceBox 40 via Telnet on port 2000. The fact that the device exposed a web admin interface accessible by other devices on the same network allowed them to gather even more information. For example, they used the command get system.version to learn that the device was running Silicon Labs’ Gecko operating system (OS) and identify its specific version, as shown in Figure 1. The admin interface also provided a set of commands to configure the system log format, leading them to discover the first vulnerability.
Figure 1. The JuiceBox 40’s web admin interface and the available set of commands
Source: Computest Sector 7’s Black Hat USA 2024 presentation material
After knowing the device’s OS and version, the team discovered that the firmware was also available for download. This was a crucial step, as having access to the firmware allowed them to conduct further analysis, such as disassembling the binary to look for critical functions or using tools to crack login credentials.
A classic stack-based buffer overflow
The Gecko OS provides a template for setting log formats, including tags such as timestamp, SSID, host, port, and MAC address. The template has a 32-character limit, including a NULL byte for termination. Each tag, such as @t for the timestamp, uses two characters, allowing a maximum of 15 tags per template. When the @t timestamp tag is used, it outputs 23 bytes into the message buffer, meaning 15 timestamp tags would generate 345 bytes. However, the buffer is only 192 bytes long. This vulnerability was uncovered through firmware analysis, which helped the team locate the function responsible for handling the message format.
The template in Figure 2 is the content within the square brackets. In this example, when the device disconnects from Wi-Fi, it logs a message that might read as “2024-08-08 | 12:35:00: : Bye for now”, as illustrated in Figure 3. (The date and time here are randomly selected for illustration purposes only.)
Figure 2. A tag usage example from the Gecko OS documentation
Source: Silicon Labs’ Command API documentation
Figure 3. A classic buffer overflow caused by using multiple tags in the message format
When the message format is set using multiple tags, such as by typing the command Set system.msg wlan_leave "[@t@t@t@t@t@t…]", it will cause the message to overflow the output buffer — a classic stack-based buffer overflow vulnerability.
This vulnerability could be further exploited by crafting specific messages to achieve arbitrary code execution. If the overflow affects adjacent memory, it could alter the return address of function calls. An attacker could then redirect execution to a location where they have injected instructions. By controlling the program counter and injecting malicious code, they could execute arbitrary commands.
Breaking down CVE-2024-23938
CVE-2024-23938 can be broken down as follows:
- The vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Silicon Labs’ Gecko OS. An attacker must be on the same network as the JuiceBox 40 to exploit this vulnerability and enable the execution of any code on the target machine.
- Authentication is not required to exploit the vulnerability. Unlike most systems where some form of authentication is required to log in, this vulnerability can be exploited without any credentials.
- It exists within the debug interface. Typically, user authentication would be required to connect to the debug interface on port 2000 of the device’s IP address.
- The vulnerability resulted from the lack of proper validation of the length of user-supplied data before copying it to a stack-based buffer. Specifically, the timestamp tag can exceed the predefined buffer length, leading to a stack-based buffer overflow.
- An attacker can exploit this vulnerability to execute code within the context of the device. By leveraging the buffer overflow, the attacker can progressively gain the ability to execute arbitrary code.
What happens in a deauth attack
During the Pwn2own Automotive competition, the “network-adjacent” attack chain was assumed as the participants set up the network environment. However, in the real world, such an attack cannot proceed if the attacker is not on the same network as the target device. This is where a deauthentication (or deauth) attack comes into play.
A deauth attack involves an attacker impersonating a station and sending “I’m going offline” to its access point. The attacker spoofs the target device’s basic service set identifier (BSSID) and sends a deauthentication frame to the access point (AP). This causes the device to disconnect from the AP and attempt to reconnect.
In the Open Systems Interconnection (OSI) network stack, the packets are encrypted but only at Layer 3 and above. MAC addresses, which are found at Layer 2, are not encrypted. As a result, performing wireless packet sniffing can easily reveal these addresses, making it possible to carry out deauth attacks.
Figure 4. A death sequence diagram: An attacker can spoof the victim’s MAC address to force the victim’s device offline.
While the target device attempts to reconnect to the AP, the attacker can sniff the “seed” or packets used to establish secure connections transmitted from the device. With this information and tools such as rainbow tables, the attacker can crack the AP’s password and gain access to the same network.
Figure 5. Upon obtaining the credentials, the attacker can join the WLAN and target the EV charger. Additionally, the attacker can access other devices on the same network.
In another scenario, if an attacker knows the AP’s information, they can set up a duplicate AP and trick the target device into connecting to it. This allows the attacker to perform a man-in-the-middle (MITM) attack.
Figure 6. An attacker can intercept and modify the messages exchanged between the device and the cloud by setting up a duplicate AP or leveraging the BLE service to make the device connect to it.
The JuiceBox 40 is equipped with BLE, which remains active for Wi-Fi provisioning when the device is not connected to Wi-Fi. This BLE service allows users to retrieve stored credentials or set a new service set identifier (SSID). While this feature is convenient for users setting up the EV charger, it also presents a vulnerability that attackers can exploit to gain access to the device.
Security implications
Silicon Labs has released a security advisory related to CVE-2024-23938 stating that the Gecko OS has reached its end of life (EOL), so no fix will be offered.
This approach is relatively common in vulnerability management, as vendors often assume that once software is no longer actively supported, it is no longer widely used. By declaring software EOL, vendors signal to users that the product will no longer receive updates, including security patches, which encourages them to transition to supported versions or even alternative solutions. This practice is generally intended to prioritize resources for maintaining and securing actively supported products.
Be that as it may, if CVE-2024-23938 had not been discovered, attackers might have been able to leverage it to perform a Wi-Fi deauth attack, potentially taking over the EV charger. This could lead to potential damage to both the charger and even the vehicle by intentionally overcharging or adjusting the charging parameters. Attackers could also encrypt access to the device and demand a ransom or gain access to the victim’s local network to compromise other devices. On a larger scale, if multiple chargers in a given area were compromised, attackers could overload the power grid by simultaneously activating the chargers.
The discovery of CVE-2024-23938 underscores these broader security implications for the automotive industry:
- Most end users assume that newer technologies, such as EVs and their charging stations, are inherently more secure. However, like other EV charger vulnerabilities discovered at Pwn2Own Automotive, this vulnerability does not require sophisticated exploitation.
- For electric vehicle supply equipment (EVSE) vendors, finding vulnerabilities during production is costlier than catching them in the design and development phases. This could slow down the development of newer products, as existing issues would need to be addressed first.
- Understanding this vulnerability’s broader implications could drive the advancement of applicable regulations and standards, leading to more secure EV chargers and their supporting infrastructure.
A background on responsible disclosure timelines
Most might wonder why there is often a delay from the time the ZDI announces that a team has successfully hacked or “pwned” a device or software at Pwn2Own events until the subsequent publication of the techniques used in the hacks. This delay is part of the coordinated vulnerability disclosure (CVD) process, which is designed to manage zero-day vulnerabilities more responsibly.
In the 1990s, only a few hackers actively hunted for vulnerabilities, and many vendors were unprepared to handle them. Both white hat hackers and vendors had concerns, such as, “Are hackers submitting vulnerabilities in exchange for benefits?” or “Will the vulnerabilities be fixed, or will the submission be a waste of time?” It came to this compromise: Hackers first submit the vulnerabilities to the vendors, who then release a patch and publicly acknowledge the hackers for their discovery.
According to the ZDI’s disclosure policy, a submitted vulnerability is disclosed once a patch is available or after a certain period if the vendor is unresponsive. This approach prevents or lowers the risk of vulnerability exploitation by either resolving the issue or making the public aware of a threat that has no known fix. This explains the time gap between the initial submission of vulnerabilities and the detailed disclosure.
