Double Tap at the Blackbox: Hacking a Car Remotely Twice with MiTM

Double Tap at the Blackbox: Hacking a Car Remotely Twice with MiTM

Speakers: [Speaker's name not provided in transcript, identified as "I'm in from 360 vulnerability research institute"], [Co-speaker's name not provided in transcript, identified as "specialized in mobile security"]

Conference: Black Hat Asia

YouTube: https://www.youtube.com/watch?v=KLvWZJumBVQ

Overview

This talk, "Double Tap at the Blackbox," by researchers from the 360 Vulnerability Research Institute, delves into the sophisticated process of remotely compromising a connected vehicle twice, using only man-in-the-middle (MiTM) techniques and without prior hardware access or extensive knowledge of the target system. The presentation outlines two distinct attack chains that leverage common software vulnerabilities and implementation flaws to gain deep control over a popular Chinese automotive brand. The "double tap" signifies the successive remote exploitation, while "blackbox" emphasizes the limited initial information the researchers had—no hardware, no firmware, just a rented car and an app from the store. This research is particularly significant for its demonstration of how high-impact automotive vulnerabilities can be discovered and exploited with relatively low cost and resource investment, challenging the perception that car hacking requires highly specialized hardware and deep insider knowledge. It highlights critical security shortcomings in both application update mechanisms and secure communication protocols within the automotive industry.

The speakers meticulously detail how they first achieved a low-privilege remote shell through an unencrypted app update channel, then escalated privileges to root using a combination of legacy kernel vulnerabilities. Subsequently, they uncovered a second, independent MiTM flaw in the vehicle's HTTPS communication, allowing them to decrypt and forge car control commands. This work underscores the urgent need for robust security practices across the entire software supply chain for connected vehicles, from app development to backend communication, and the critical importance of timely patching for known vulnerabilities.

Background

▶ Watch: Introduction and the Tinfu Cup anecdote (0:00)

The automotive cybersecurity landscape has seen increasing attention in recent years, with high-profile incidents demonstrating the potential for devastating impacts. While elite teams like Senactive have garnered significant acclaim for their "triple pwn" of Tesla vehicles at events like Pwn2Own, their methods often rely on extensive hardware access, deep reverse engineering, and the ability to maintain root shells across firmware updates. This approach, while effective, sets an extremely high technical and financial bar, making such research inaccessible to many. The speakers highlighted that Tesla, despite its prominence, represents only 5-10% of the global market, leaving the security posture of the remaining 90% largely unexamined through similarly rigorous, yet resource-intensive, methods.

The motivation for this research stemmed from a challenge at the 2021 TinFu Cup, a Chinese version of Pwn2Own, where the researchers were tasked with finding vulnerabilities in a top-10 automotive brand in China. With only 15 days, no prior knowledge, and no physical access to the car's hardware, they faced significant constraints. Traditional car hacking methods, involving purchasing and disassembling infotainment systems (costing $100-$2000 with no boot guarantee, and often yielding outdated or defective units) or renting cars (which prevents destructive analysis), were deemed impractical for their "blackbox" scenario. Their goal was to find "extremely easy approaches to pwn it" that would "save the researchers' wallet" and allow for rapid, remote exploitation. This context sets the stage for their focus on software-level vulnerabilities accessible without physical tampering, specifically through network-based attacks. The existence of an overheard conversation at a standard meeting, hinting at an OEM's vehicles being compromised for TinFu Cup, further fueled their determination, despite the OEM's subsequent attempt to block their presentation.

Key Findings

▶ Watch: Affordable car hacking research methods (4:00)

The research yielded several critical findings, demonstrating a multi-stage, remote compromise of a modern connected vehicle:

1. Unencrypted App Update (MiTM 1): The initial entry point was a glaring security oversight: a vehicle control application distributed via an app store updated its components over HTTP without any SSL/TLS encryption. This allowed a local man-in-the-middle attacker to intercept the update traffic and inject a malicious application, effectively gaining a low-privilege remote shell on the vehicle's infotainment system.
2. Hidden Factory Mode and Authentication Bypass: Through reverse engineering the downloaded application, the researchers discovered hidden factory mode functionalities accessible via specific dialer codes (e.g., #9925111# for OS version). While these modes often required authentication, the "encryption" algorithm for the secret code was merely a simple series of additions and multiplications based on device-specific IDs, making it trivial to reverse engineer and bypass. This granted access to advanced system settings, including the ability to enable ADB (Android Debug Bridge), albeit still at a low privilege level (UID 2000).
3. Privilege Escalation Chain:

• Dirty Cow (CVE-2016-5195) for System Privilege: Faced with a low-privilege ADB shell and a read-only root file system, the researchers leveraged the well-known Dirty Cow vulnerability. They identified that the log service binary, unlike other user-facing applications, ran with system privilege. By exploiting Dirty Cow's arbitrary file write capability, they overwrote the log service binary with their own shellcode, thereby achieving a system-level shell.
• CVE-2015-1805 for Root Privilege: With system privilege, they could then read kernel symbols to determine the necessary offsets. This allowed them to successfully exploit CVE-2015-1805, a time-of-check to time-of-use (TOC/TOU) vulnerability in the pipe_iov_copy_to_user function, to achieve a root shell on the infotainment system. This completed the full privilege escalation chain, granting full control over the car's operating system.

1. Flawed HTTPS Certificate Validation (MiTM 2): Even after the manufacturer patched the initial HTTP update vulnerability by moving to HTTPS, the researchers discovered a second, independent MiTM vulnerability. The vehicle's application implemented a custom X.509 Trust Manager that failed to properly validate server certificates. Specifically, it trusted user-signed certificates in addition to manufacturer-signed ones, and its checkServerTrusted function did not adequately verify the authenticity of the presented certificate chain. This allowed an attacker in the same network (e.g., via ARP spoofing) to present a self-signed certificate, decrypt the seemingly secure HTTPS traffic (likely MQTT over TLS), and forge car control commands.
2. Remote Car Control: By analyzing the decrypted HTTPS/MQTT traffic, the researchers reverse-engineered the structure of car control commands (e.g., serviceType, messageType, commandType, commandValue). This enabled them to send arbitrary commands to lock/unlock doors, open/close windows, or control other vehicle functions remotely.

In essence, the "double tap" refers to these two distinct remote MiTM attack vectors, both leading to full car control, demonstrating a profound lack of secure-by-design principles in the target vehicle's software ecosystem.

Technical Deep Dive

▶ Watch: First exploit: MITM on app update for remote shell (6:40)

The technical execution of the "double tap" involved a meticulous multi-stage approach, combining initial access, privilege escalation, and protocol analysis.

First Exploit Chain: From HTTP MiTM to Root

The initial compromise began with an opportunistic man-in-the-middle (MiTM) attack. The researchers observed that one of the target vehicle's applications, available on the app store, performed updates over plain HTTP. This is a critical vulnerability as HTTP traffic is unencrypted and unauthenticated, making it susceptible to interception and manipulation. By placing themselves in a position to intercept the vehicle's network traffic (e.g., via ARP spoofing on the same Wi-Fi network), they could hijack the update request. Instead of serving the legitimate app update, they injected a malicious APK, effectively installing a remote shell on the infotainment system. This initial shell provided only low privileges, typically running under a standard Android user ID (UID 2000), insufficient for critical car control.

With this low-privilege access, the researchers downloaded and reverse-engineered the application's APKs. Their investigation quickly uncovered interesting strings related to a "factory" mode. This hinted at hidden diagnostic or configuration functionalities. Through static analysis of the code, they identified specific dialer codes, formatted as #XXXXX#, that could be input via the Bluetooth phone application. One such code, 9925111, directly triggered the display of the operating system and hardware versions. Another, 9387141, was linked to system settings, but initially appeared to do nothing.

Further reverse engineering revealed that the 9387141 function was protected by an authentication mechanism. The code implemented a custom "encryption" logic, identified by strings like A2 input check, which compared the user's input against a dynamically generated "secret code." Crucially, this wasn't a robust cryptographic algorithm but a simplistic series of addition and multiplication operations based on unique device identifiers and hardware versions. Such a weak scheme is trivial to reverse engineer. The researchers quickly cracked this custom "encryption," obtaining the correct secret code to activate the full factory mode.

Gaining access to factory mode was a significant step. It exposed features like console services, log services, and, importantly, the ability to enable ADB (Android Debug Bridge). While ADB provided a more convenient interface for interaction, the shell it offered still operated at the low privilege level (UID 2000). To gain control over critical car functions, root privilege was required.

The infotainment system's kernel was identified as being quite old, leading the researchers to explore well-known, albeit dated, kernel vulnerabilities. Two candidates emerged:

1. CVE-2015-1805: A time-of-check to time-of-use (TOC/TOU) vulnerability in the pipe_iov_copy_to_user function, allowing for arbitrary memory writes and potential root access. However, exploiting this requires knowing kernel offsets, which are typically derived from kernel symbols, inaccessible without higher privileges.
2. Dirty Cow (CVE-2016-5195): An arbitrary file write vulnerability that could potentially allow modification of system binaries. The challenge with Dirty Cow in a vehicle context is that most user-facing applications run with low privileges, and system binaries are often located on a read-only file system, making persistent modification difficult or impossible across reboots.

The breakthrough came from a clever combination of these two. The researchers realized that while the main system binaries were read-only, certain services running with higher privileges might have writable temporary or runtime components. Specifically, they identified that the log service on the infotainment system ran with system privilege (a higher UID than a regular app, typically UID 1000). By exploiting Dirty Cow, they could perform an arbitrary file write to overwrite the log service's binary with their own custom shellcode. When the log service was subsequently invoked (or rebooted), it would execute their malicious code, granting them a system-level shell.

With system privilege, the critical hurdle for CVE-2015-1805 was overcome. They could now read kernel symbols and determine the necessary offsets. The CVE-2015-1805 vulnerability specifically arises in the pipe_iov_copy_to_user function within the kernel. This function copies data to user-space memory buffers, represented by iov_base pointers. The vulnerability is a classic TOC/TOU:

• Time of Check: The kernel first checks if all iov_base memory addresses are writable.
• Time of Use: If they are, it proceeds to write data into these buffers.

The exploit involves setting all iov_base addresses as writable initially. However, between the check and the use, a malicious attacker can modify some of these iov_base addresses to point to unwritable memory or to arbitrary kernel addresses. When the kernel attempts to write to an unwritable address, an error occurs, and the procedure is reset. Crucially, the pointer to the iov_base has already advanced to the next one, but the write operation attempts to write the same length of data as before. This allows an attacker to overflow the intended buffer and write to an arbitrary kernel address, ultimately leading to root privilege.

Once root was achieved, controlling car functions became straightforward. The Android platform, common in infotainment systems, uses Binder for inter-process communication. Car control commands are typically sent as CAN (Controller Area Network) messages via specific Binder interfaces to the vehicle's ECUs (Electronic Control Units). The researchers could now program these commands using Python or Java, sending them through the system with full privileges to manipulate car functions like door locks, windows, and trunk.

Second Exploit Chain: HTTPS MiTM for Remote Car Control

Even after the manufacturer patched the initial HTTP vulnerability by implementing HTTPS for app updates and other communications, the researchers discovered a second, independent MiTM vector. This time, the flaw was not in the presence of encryption but in its implementation. HTTPS relies on SSL/TLS certificate validation to ensure the authenticity of the server. Common implementation errors, such as neglecting certificate errors in WebViewClient.onReceivedSslError, lax validation in custom HostnameVerifier methods, or insecure setHostnameVerifier calls, can undermine this security.

In this specific case, the vehicle's application used a custom X.509 Trust Manager with two critical flaws:

1. Trust Anchor Expansion: The system was configured to trust not only certificates signed by the manufacturer or those within the system's default trust store but also user-signed certificates. This meant an attacker could generate their own self-signed certificate.
2. Flawed checkServerTrusted: The checkServerTrusted function, which is supposed to rigorously verify the certificate chain presented by the server, was implemented incorrectly. It failed to adequately verify that the certificate was signed by a trusted authority or that it belonged to the expected server. It effectively trusted any certificate presented.

These two flaws meant that an attacker in the same network segment as the car (e.g., via ARP spoofing) could intercept HTTPS traffic. When the car's client attempted to establish a secure connection with the cloud server, the attacker could present their self-signed certificate. Due to the flawed trust manager, the client would accept this malicious certificate, allowing the attacker to establish an encrypted tunnel with the client and a separate, legitimate tunnel with the actual cloud server. The attacker could then decrypt all traffic passing through, including the MQTT messages used for car control, and re-encrypt it for the legitimate server. This effectively created a transparent MiTM proxy.

By decrypting the MQTT traffic, the researchers could analyze the structure of the car control commands. They found them to be relatively simple, consisting of a random message ID, the car's VIN (Vehicle Identification Number) as the target ID, and four key-value pairs: serviceType, messageType, commandType, and commandValue. Examples provided included specific combinations of these values to open windows or the trunk. With this knowledge, the attacker could forge arbitrary control commands and inject them into the communication stream, achieving remote control over the vehicle's functions even when the manufacturer believed the communication was secure via HTTPS.

Demo / Proof of Concept

▶ Watch: Attempting to unlock system settings with a secret code (10:00)

The talk included two compelling demonstrations, showcasing the practical impact of each exploit chain.

For the first exploit chain, the researchers demonstrated the full remote root compromise. The scenario began with the car in a locked, unbooted state. Crucially, the Wi-Fi module remained active even when the vehicle's main systems were off, providing a persistent network entry point for the MiTM attack. The researchers initiated the exploit remotely. After a brief period, indicating the successful execution of the full privilege escalation chain (HTTP MiTM -> low-privilege shell -> factory mode bypass -> Dirty Cow for system privilege -> CVE-2015-1805 for root), the car's doors were observed to unlock and open. This vividly illustrated the ability to gain complete, unauthorized control over fundamental vehicle functions remotely.

The second exploit chain demonstration focused on the HTTPS MiTM vulnerability, showcasing remote control capabilities without the need for root access on the infotainment system itself. In this scenario, the researchers, positioned within the same network as the vehicle, intercepted the encrypted HTTPS/MQTT traffic. Leveraging the flawed certificate validation, they decrypted the communication. They then forged specific car control commands based on their analysis of the MQTT message structure. The demonstration showed them remotely activating the car's lights, rolling down the windows, and opening the trunk. This confirmed that even with HTTPS supposedly securing the communication, the implementation flaws allowed an attacker to bypass encryption and issue arbitrary commands, underscoring the severity of the certificate validation vulnerabilities.

Both demonstrations effectively validated the researchers' findings and highlighted the real-world implications of these vulnerabilities for vehicle security.

Defensive Implications

▶ Watch: Uncovering the authentication logic for factory mode (10:20)

The findings presented in "Double Tap at the Blackbox" carry significant defensive implications for automotive manufacturers, suppliers, and the broader connected vehicle ecosystem. The lengthy vulnerability lifecycle observed in this research is particularly alarming:

• The first vulnerability, discovered in September 2021 on a model released in 2018, was only fixed in early 2022, with the model potentially discontinued by 2023.
• The second vulnerability, discovered in October 2024 (likely a typo in the transcript, given the talk year; presuming October 2021 or 2022) on models B and C, was fixed in January 2025.

These timelines are considerably longer than those typically seen in consumer electronics (e.g., iOS, Android, Windows), leaving vehicles exposed to known threats for extended periods.

Key defensive actions include:

1. Strict Enforcement of HTTPS/TLS: All communication channels, especially those involving application updates or remote vehicle control, must use HTTPS/TLS with strict certificate validation. This means:

• Eliminating HTTP for updates: Never use plain HTTP for delivering software updates.
• Robust X.509 Trust Manager Implementation: Custom trust managers must be meticulously implemented to reject self-signed or untrusted certificates. The checkServerTrusted function must thoroughly verify the entire certificate chain against a trusted set of root CAs.
• Hostname Verification: Ensure the hostname in the certificate matches the expected server hostname.
• Certificate Pinning: Consider implementing certificate pinning to restrict trusted certificates to a very specific set, making MiTM attacks much harder even if a CA is compromised.

1. Secure Factory Mode Implementation: While factory modes are necessary for diagnostics and manufacturing, they must be:

• Strongly Authenticated: Authentication mechanisms should use robust, standard cryptographic algorithms (e.g., AES with proper key management), not easily reversible custom schemes. Keys should be securely stored and provisioned, ideally in Hardware Security Modules (HSMs) or Trusted Execution Environments (TEEs), not directly in the system where they can be extracted after initial compromise.
• Privilege Restricted: Factory mode features, especially those enabling debugging tools like ADB, should be highly restricted and require strong multi-factor authentication, ideally tied to physical presence or specific, secure provisioning processes. The addition of public key verification for ADB in later patches is a good step but must be robustly implemented.
• Audit Logging: All access attempts and actions within factory mode should be meticulously logged to a secure, tamper-proof location.

1. Prompt Patching and Kernel Updates: The reliance on old kernel versions (e.g., vulnerable to CVE-2015-1805 and Dirty Cow) highlights a critical weakness. Automotive manufacturers must:

• Regularly Update Kernels: Implement a robust process for regularly updating the Linux kernel and other core operating system components to patch known vulnerabilities.
• Accelerate Patch Delivery: The slow patch cycle must be drastically improved. Over-the-air (OTA) update mechanisms need to be secure, reliable, and capable of deploying critical security patches quickly across the entire fleet.
• Vulnerability Management: Implement comprehensive vulnerability scanning and management programs across all software components, including third-party libraries and open-source contributions.

1. Principle of Least Privilege: All applications and services should run with the absolute minimum privileges required for their function. The fact that the log service ran with system privilege, allowing Dirty Cow to escalate, is a clear violation of this principle. Granular permissions and robust sandboxing are essential.

1. Secure Software Development Lifecycle (SSDLC): Integrate security considerations at every stage of the development process, from design and architecture review to testing and deployment. This includes:

• Threat Modeling: Proactively identify potential attack vectors.
• Security Testing: Conduct regular penetration testing, fuzzing, and code reviews.
• Supply Chain Security: Vet the security practices of all tier-one and tier-two suppliers.

The researchers' call for community contribution and an open-source tool to identify MiTM vulnerabilities underscores the need for democratizing security research in the automotive space to collectively raise the bar.

Key Takeaways

• Remote Car Hacking is Achievable with Limited Resources: This research demonstrates that sophisticated remote control of vehicles can be achieved without expensive hardware or deep insider knowledge, relying on common software vulnerabilities and network-based attacks.
• Man-in-the-Middle (MiTM) is a Pervasive Threat: Both unencrypted communication (HTTP) and flawed HTTPS implementations (certificate validation bypasses) pose significant MiTM risks, allowing attackers to intercept, decrypt, and forge critical vehicle commands.
• Legacy Kernel Vulnerabilities Persist: Older kernel versions in infotainment systems create a fertile ground for privilege escalation, as demonstrated by the effective use of Dirty Cow (CVE-2016-5195) and CVE-2015-1805 to gain root access.
• Flawed Cryptographic Implementations Undermine Security: Even when security mechanisms like HTTPS are in place, weak or incorrect implementations (e.g., simple "encryption" for factory mode, trusting user-signed certificates) render them ineffective.
• Automotive Patching Cycles are Dangerously Slow: The extended period between vulnerability discovery and patch deployment in the automotive sector leaves a vast attack surface exposed for years, highlighting an urgent need for more agile security response mechanisms.
• Secure Development Practices are Crucial: Strict adherence to principles like least privilege, thorough input validation, robust authentication, and comprehensive SSL/TLS validation are non-negotiable for connected vehicle security.

About the Speaker(s)

The primary speaker, whose name was not explicitly stated in the transcript but identified as "I'm in from 360 vulnerability research institute," is a security researcher specializing in connected vehicle security. This individual is also known as a "forchain exploiter" of the BlackBerry QNX system, which is noted as the "most popular automotive operating system." The speaker is actively involved in both industry and academia within the cybersecurity domain.

The co-speaker, also unnamed in the transcript, is described as specializing in mobile security. Their expertise lies in "customizing AOSP (Android Open Source Project) to bypass application protections," indicating a deep understanding of Android system internals and application security.