Smile, You’re Being Watched: Penetration Testing Insights on Vehicle Privacy Risks

Modern vehicles have evolved into complex interconnected systems, essentially turning them into mobile computing hubs that collect, process, and exchange enormous amounts of data. This data pool includes private and sensitive data, such as real-time and historical geolocation information, contact details, etc. With the addition of vehicle microphones, cameras, and various other sensors into the mix, the risk of privacy breaches rises significantly.

Although the In-Vehicle Infotainment system (IVI) carries a significant portion of the privacy risk, it is not an isolated component. Data also flows between various Electronic Control Units (ECUs) and even reaches external servers, meaning the attack surface for potential breaches spans across the entire vehicle system. In this blog, we share three case studies highlighting privacy issues and related implications discovered by our PlaxidityX research team in penetration tests conducted on vehicles.

“Google, Reveal Everyone’s Location”

Although not directly related to the vehicle itself, the first case highlights broader data risks – namely, if vehicle data is transmitted to external servers, the vehicle’s own security is not the only concern. Who needs to worry about the data in the car when it is sent to the servers?

During our testing, we intercepted the data traffic between the vehicle and the internet, searching for a needle in a haystack – one potentially exposed communication channel. We identified a communication channel linking the vehicle and a proprietary OEM server that used an unsecured protocol.

Although the data was not transferred in plain text, the port scan on the server’s IP revealed an open API that did not require authentication. But that wasn’t all. We discovered a password-protected web interface, which we eventually breached using a brute force attack. Once inside, we could view live locations of all of OEM’s vehicles in the country, along with their VIN and model. Well, who wouldn’t want their personal data performing a world tour 😊? Even better, by design, we can ask the API to find vehicles in specific locations. While you might think such sites are not common, only a few months ago, another similar use case was published by Sam Curry.

These flaws not only expose the location of an individual vehicle but also potentially reveal the operational logistics of an entire fleet. As a rule, this information should not even be saved. Unanonymized VIN-model-location information on all the vehicles is a privacy violation. Here, the external interface channels were vulnerable, underscoring the need for holistic vehicle cybersecurity testing at a system level.

Sometimes, there is a good reason to save this information in the vehicle, but what happens then? That leads us to the next use case.

“Vehicle, Snap a Selfie and Share It”

In today’s digital age, sharing selfies on social media is the norm. If you’ve ever tried to take a selfie in the vehicle, you know it’s not always easy. Not to worry, vehicles are starting to be equipped with built-in selfie cameras. But as with any new technological feature, these cameras introduce their own set of security and privacy risks.

In this case study, we examined a vehicle that featured an integrated selfie camera. We gained access to the IVI system, where we discovered an unprotected MQTT service. By experimenting with the IVI’s interface functionalities, we observed that capturing a picture triggers a broadcast message via MQTT. Further exploration of the camera mechanisms revealed that we could also use this channel’s messages to control the vehicle’s camera.

Leveraging additional access through the Telematics Control Unit (TCU) and gateway, we established a reverse shell connection to our servers. This allowed us to send remote commands to the vehicle, asking it to capture images and send them back to our servers – all without the user’s consent or even awareness.

If capturing images required a constant physical connection to the IVI, it would still be an issue – but with very limited possibilities and no privacy implications. However, by exploiting issues across other ECUs and the overall vehicle ecosystem, we were able to execute these commands remotely, increasing the feasibility and privacy risk for vehicle users. It is also worth mentioning that this service was unprotected (i.e., not encrypted). If transferring and saving private information is absolutely necessary, this use case highlights the importance of encrypting private information.

“Siri, Take My Data”

Our smartphones have become indispensable. From calls and messaging to navigating, gaming, and even payments, smartphones are amazing tool that have an app for everything – including even controlling our vehicles. As technology advances, automakers are transitioning from traditional car keys to digital keys and mobile applications for vehicle control and monitoring, thus introducing new risks. In this project, we examined the communication between the vehicle and its owner’s mobile app. Although the OEM ensured that all the communication with the vehicle was encrypted properly, it was still insufficient to prevent unauthorized access.

Starting with standard attack techniques, we first accessed the vehicle’s Wi-Fi network and located an unsecured debug interface on the TCU. Through this entry point, we connected the vehicle to our server, establishing a remote connection. Inside the system, we found that the owner’s mobile app communicated over the MQTT protocol. MQTT is an IoT publish-subscribe system: i.e., a publisher posts messages to specific channels, and anyone with the correct credentials and certificates can subscribe and receive those messages.

Our goal was to subscribe to the vehicle app’s channel and receive the live data. While investigating the TCU, we found that the data was encrypted and forwarded to the IVI, to which we had no debug access. Therefore, we set out to obtain the necessary credentials and certificates so we could subscribe directly from the TCU to the channel. We disconnected the IVI, which we believed contained the required data, and probed its external flash-memory pins to read the contents. Further analysis showed that the username, password, and certificates were stored unencrypted on the flash rather than in secure memory, enabling us to extract them. Armed with these credentials, we successfully subscribed to the MQTT server from the TCU.

Once we successfully subscribed to the MQTT server, we uncovered sensitive and private information, including the vehicle’s location, current speed, and navigation data. We also found messages containing cloud information, tokens, URLs, and other confidential data. This case, uncovering privacy implications of an unrelated attack, shows that encryption on its own is not a silver bullet – true data protection depends on securing the entire vehicle ecosystem.

“PlaxidityX, Please Help Mitigate These Issues”

Vehicles increasingly operate as interconnected computing platforms, enabling real-time data exchange with backend servers, mobile apps, and cloud services. While this connectivity offers significant benefits, it also broadens the potential attack surface, opening new attack vectors for cyber threats and privacy breaches. Robust security measures are, therefore, essential.

Based on our real-world experience working with OEMs, here are some best practices designed to help secure your automotive systems:

• Encrypt all external communication: Ensure that data transmitted between your vehicle and backend servers is fully encrypted to prevent unauthorized interception.
• Robust Authentication: Implement proper authentication on the communication and backend servers and APIs to protect vehicle-to-backend communication to reduce the risk of unauthorized access.
• Complex Credentials: Enforce high-complexity password requirements and avoid predictable or easily guessed credentials to prevent brute-force attacks.
• Secure private keys and credentials storage: Store private keys and credentials in secured and controlled environments such as a hardware security module (HSM).

Final Thoughts

In an era where ECUs can serve as potential entry points for cyber attacks and where vehicles generate and collect more data than ever, privacy risks are at an all-time high. Protecting the privacy of vehicle users and ensuring the integrity of connected systems must be prioritized, not as an isolated component issue but as an integrated effort through the entire vehicle. Comprehensive vehicle-level penetration testing is one effective method to uncover and mitigate these risks. By simulating real-world attack scenarios across the full system, this type of testing will not only identify individual weaknesses but also expose the interdependent risks that might otherwise remain undetected.

*The penetration testing described here was conducted in collaboration with Erez Alfasi, Omer Mayraz, and Ilya Dubnov, who uncovered many of the vulnerabilities highlighted in this blog.

About PlaxidityX Research Group

Harnessing decades of cyber security and automotive expertise, the PlaxidityX Research Group has extensive experience working with OEMs and Tier 1s in dozens of penetration testing and research projects to verify and elevate their cyber security posture, and help them comply with UNR 155, UNR156 and ISO-21434 regulations. With an unparalleled understanding of automotive architectures, protocols and standards, the PlaxidityX Research Group provides a comprehensive set of automotive cyber security services, including Automotive Penetration Testing, TARA and Cyber Security Architecture Design, and UNR 155 and ISO 21434 Cyber Security Compliance.