Full Report
This is just a bunch of slides but a ton can still be learned from it. The target is an In-Vehicle Entertainment system that has things like Amazon Alexa and things built into it. The first part of the process was getting the code off of it to reverse engineer and getting a debuggable environment. The flash chip was a BGA eMMC chip. So, they used a hot air reworking station to remove the chip, popped it into an adapter and got the firmware off of it. To get a debuggable environment, they reverse engineered a bunch of settings for a secret debug menu and added a missing 0-ohm resistor but were shut out by a good password they couldn't crack. Eventually, they just live patched the running memory of the chip to change /etc/shadow to get a shell. They also tried reprogramming the chip but bricked one of their devices trying to do this. The device had an insecure HTTPs certificate handling on a request to api.sports.gracenote.com. By hosting a malicious DHCP server with attacker controlled DNS, they could interact with this service. On this server, there was a directory traversal arbitrary write vulnerability that allowed for writing arbitrary files. Most of the system contained a read-only filesystem. Many of the mounts were even noexec. They found that the file pkcs11.txt allowed for the configuration of shared objects with a file path. Additionally, there was a mounted USB that was missing the noexec flag. Using this configuration file, it was possible to load arbitrary .so/code> libraries. Of course, they could write this library to the USB. The only problem was that this wasn't changed right away; it was set at boot time of the device. Eventually, they found that by writing to /usr/local/bin/Media in a particular way the device would reboot. To go to root, they used an n-day kernel exploit. The rules of Pwn2Own are weird to me. How would the car be listening to this malicious DNS server in the first place to launch this exploit? It doesn't seem very realistic to me... Then, they have to perform the reboot themselves because no user interaction is allowed once the exploit starts. Regardless, a cool bug and a fun story on reverse engineering!
Analysis Summary
# Vulnerability: In-Vehicle Entertainment System Chain Exploit Leading to Arbitrary Code Execution
## CVE Details
- CVE ID: Not provided in the source material. (Likely multiple vulnerabilities chained together)
- CVSS Score: Not provided in the source material.
- CWE: Multiple identified, including Insecure Certificate Handling, Directory Traversal, Arbitrary File Write, and Insecure Shared Object Loading configurations.
## Affected Systems
- Products: In-Vehicle Entertainment (IVE) system (specific vendor not named, but implied to be related to Pioneer based on OS modification notes).
- Versions: Not specified.
- Configurations: Devices where firmware extraction was possible, which allowed access to debug settings, and devices making requests to `api.sports.gracenote.com`.
## Vulnerability Description
The attack chain was initiated by gaining physical access to extract the firmware via an eMMC chip. Researchers then achieved a debug shell through **live memory patching** to bypass a strong password protecting the debug menu.
The primary remote-exploitable chain involved:
1. **Insecure HTTPS Certificate Handling:** The system had an issue trusting certificates for requests directed to `api.sports.gracenote.com`.
2. **Network Misconfiguration:** By controlling the DHCP/DNS of the vehicle network, the attacker could redirect this traffic to a malicious server.
3. **Directory Traversal & Arbitrary Write:** The server hosting the destination endpoint (`api.sports.gracenote.com`) had a directory traversal vulnerability allowing arbitrary file writes, constrained because most of the filesystem was read-only and `noexec`.
4. **Code Execution Chain:**
* Researchers identified a configuration file, `pkcs11.txt`, which allowed specifying paths for shared objects (`.so` files).
* They leveraged a mounted USB drive, which lacked the `noexec` flag, to store the malicious library.
* By writing the malicious configuration to `pkcs11.txt` (using the arbitrary write), they convinced the system to load the remote library on the next boot cycle.
* A final step involved a specific file write to `/usr/local/bin/Media` to force a necessary reboot, allowing the malicious code to load.
* The chain culminated with the exploitation of an **n-day kernel exploit** post-reboot to achieve root access.
## Exploitation
- Status: Successfully demonstrated in a **Proof of Concept (PoC)** competition setting (Pwn2Own Automotive 2024).
- Complexity: High (Requires physical access for initial firmware setup/debugging, followed by a complex, multi-stage remote exploit chain that depends on specific network interactions and timing).
- Attack Vector: Hybrid (Starts with **Physical** access required for initial setup/debugging capability, followed by **Network** vector for the remote chain).
## Impact
- Confidentiality: High (Gained capacity to exfiltrate data like location, contacts, and call history).
- Integrity: Full system compromise (Root access achieved).
- Availability: Localized Denial of Service observed during testing (bricked one device during reprogramming attempts, and a controlled reboot was necessary for the final payload execution).
## Remediation
### Patches
- No specific vendor patches or associated CVEs were provided in this summary. Patches would need to address:
* Insecure certificate validation logic for external service calls.
* The directory traversal/arbitrary write vulnerability on the backend service (`api.sports.gracenote.com`).
* Correct permission settings (`noexec`) on all mounted filesystems, especially removable media.
* Removal of insecure shared object configuration paths like those dictated by `pkcs11.txt`.
### Workarounds
- Restricting network connectivity for the IVI system if external service calls are not strictly necessary.
- Strict enforcement of file system integrity and mounting options preventing execution on non-system partitions (i.e., ensuring `noexec` is enforced on USB mounts).
- Monitoring for unexpected outbound connections to known service endpoints based on configuration files.
## Detection
- **Indicators of Compromise (IoCs):**
* Unexpected outbound network requests or certificate validation failures related to `api.sports.gracenote.com`.
* Presence of arbitrary `.so` files on connected USB drives immediately following boot.
* Changes or presence of files like `pkcs11.txt` pointing to external/removable paths.
* Unusual write activity to `/usr/local/bin/Media`.
- **Detection Methods and Tools:**
* Integrity Monitoring (FIM) on critical configuration files and system binaries.
* Network traffic analysis monitoring for TLS handshake anomalies or certificate errors directed at the Gracenote API endpoint.
## References
- Vendor Advisories: None provided. (This was a Pwn2Own zero-day disclosure process).
- Relevant links - defanged:
* Talk Slides: `hxxps://www.nccgroup.com/media/c0rhq34v/pioneering-zero-days-at-pwn2own-automotive-2024.pdf`
* Exploit Demo Video: `hxxps://vimeo.com/1062015713`
* Original Post: `hxxps://www.nccgroup.com/research/insomnihack-pioneering-zero-days-at-pwn2own-automotive-2024/`