By Vit Sembera (Senior Threat Researcher, Automotive)
At Pwn2Own Automotive 2024, researchers from Synacktiv, David Berard and Vincent Dehors, delivered another impressive demonstration, continuing their streak of successful hacks against Tesla’s in-vehicle infotainment (IVI) system, which started at Pwn2Own Vancouver 2022. This time, they executed a two-bug chain to compromise Tesla’s IVI system by breaching the vehicle’s LTE connectivity card, a crucial component running on a Linux-based platform. This vulnerability allowed them to execute a remote code execution (RCE) attack, leading to a takeover of Tesla’s communication system.
Exploiting the connectivity card
In their presentation at OffensiveCon 2024, “0-Click RCE on the Tesla Infotainment Through Cellular Network,” the Synacktiv researchers revealed how they targeted Tesla’s LTE connectivity card, uncovering several critical weak points that granted them root-level access:
- The UART port had root access enabled.
- The root file system was mounted in read/write mode.
- A vulnerability in the AT command handler allowed them to inject arbitrary commands.
- A race condition in the iptables firewall sometimes caused it to be inactive, providing an open window for attack.
By leveraging these vulnerabilities, the researchers developed a sophisticated exploit chain. They mimicked a cellular network base station and manipulated connectivity checks, which allowed them to reboot the card or inject commands when the firewall was down. They ultimately disabled the firewall permanently and gained remote access via SSH.
Digging into the IVI system
The next stage of the attack targeted Tesla’s IVI system, which runs Ofono, open-source telephony software designed to handle mobile network communication. Tesla customized Ofono with a plug-in for communicating with the LTE connectivity card, but this plug-in contained a heap buffer overflow vulnerability. Synacktiv employed advanced techniques such as heap shaping and return-oriented programming (ROP) within the system’s libc to exploit the flaw. The researchers also bypassed the XPIN security module, exploiting a memory mapping bug to avoid detection.
Escaping the sandbox
Ofono’s daemon, a background process responsible for managing mobile network communication, was heavily sandboxed with security measures such as MiniJail, SecComp, AppArmor, and iptables. However, since the daemon had network admin privileges, the researchers were able to modify network configurations and forward packets through the IVI system to Tesla’s security gateway, allowing them to bypass these sandbox protections.
Security takeaways
Synacktiv’s two-bug exploit chain was impressively complex, once again showcasing the team’s expertise in breaching even the most secured systems. However, the vulnerabilities they exploited were the result of common security oversights:
- Improper validation of input commands enabled RCE on the connectivity module.
- Inadequate buffer size allocation led to the heap buffer overflow in Tesla’s custom Ofono plug-in.
- Although Tesla’s system included strong hardening measures, including sandboxing and firewalls, misconfigurations and improper implementation ultimately made this breakthrough possible.
These security takeaways emphasize that even highly secured systems can still fall to well-crafted exploitation chains, especially when small vulnerabilities are overlooked and remain unaddressed.
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.
