By Vit Sembera (Senior Threat Researcher, Automotive)
Two stack-based buffer overflow vulnerabilities discovered in the Autel Maxicharger electric vehicle (EV) charger during Pwn2Own Automotive 2024 again shed further light on serious coding security lapses. Although they’ve been patched, the vulnerabilities, CVE-2024-23967 and CVE-2024-23957, underscore how improper input data validation could expose critical systems such as EV chargers to remote code execution.
CVE-2024-23967: Base64 decoding vulnerability
CVE-2024-23967 was discovered by researchers from Computest Sector 7 in version 1.32 of the Autel MaxiCharger firmware. The vulnerability stems from improper handling of Base64-encoded data, which is decoded into a fixed-size stack buffer without checking the size of the incoming data. As a result, an attacker can exploit this flaw by sending oversized data, leading to a buffer overflow and enabling remote code execution.
This oversight highlights a basic coding mistake: failing to validate both the size and the content of the input data. Implementing proper input validation would have prevented this vulnerability by ensuring that the decoded data fits within its allocated buffer.
CVE-2024-23957: Hex string decoding vulnerability
The second vulnerability, CVE-2024-23957, was discovered by Midnight Blue/PHP Hooligans in the same version 1.32 firmware. The vulnerability arises when the system processes large hex strings sent by an attacker. The hex string is decoded into a fixed-size stack buffer without any bounds checking, which allows for a buffer overflow that could similarly lead to remote code execution and a full compromise of the device.
Are firmware patches enough?
Autel has addressed both of these vulnerabilities in version 1.35 firmware of the Autel MaxiCharger firmware.
While it’s commendable that Autel acted swiftly to patch these vulnerabilities, their approach in fixing them raises some concerns. Quick fixes might prevent exploitation in the short term, but without a systemic overhaul of the coding practices that allowed these flaws in the first place, similar issues are likely to reappear.
Both vulnerabilities share a common cause: the lack of proper input validation. By failing to implement checks on the size and the structure of incoming data, the Autel firmware remained susceptible to classic buffer overflow attacks. These fundamental coding issues should have been addressed at the core level of the system, rather than being patched on a case-by-case basis.
The problem with reactive security
CVE-2024-23967 and CVE-2024-23957 highlight the dangers of relying on a reactive security approach. Waiting for vulnerabilities to be discovered and publicly disclosed before taking action is neither sustainable nor safe, especially in critical systems such as EV chargers and the connected infrastructure that supports them.
Proactively building security into the development lifecycle, including robust input validation and thorough code reviews, is essential to preventing classic buffer overflows from arising. As the automotive industry continues to evolve toward greater connectivity, the security of its infrastructure — down to components like EV charging stations — becomes increasingly vital.
The lessons learned from these Autel MaxiCharger vulnerabilities discovered at Pwn2Own Automotive 2024 should serve as a wake-up call for vendors and developers alike: Security must be integrated from the outset, not addressed as an afterthought.
For more information on these vulnerabilities and insights into the reverse-engineering techniques used to uncover them and details on how Autel patched them, read the relevant blog entry by the Zero Day Initiative (ZDI), VicOne’s co-host for Pwn2Own Automotive and partner in vulnerability discovery and disclosure.
We also provided security takeaways from CVE-2024-23959 and CVE-2024-23958, the other Autel MaxiCharger vulnerabilities discovered at Pwn2Own Automotive 2024, in a previous blog entry.
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.
