DriveThru Car Hacking: Fast Food, Faster Data Breach

DriveThru Car Hacking: Fast Food, Faster Data Breach

Speakers: Alina, Co-founder & Security Architect, Heat Security Labs; George, Co-founder & Security Architect, Heat Security Labs

Conference: Black Hat Asia

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

Overview

This talk, presented by Alina and George from Heat Security Labs, introduces a novel and concerning attack vector: drive-thru car hacking targeting ubiquitous dash cameras. The research highlights significant, yet often overlooked, security vulnerabilities in these devices, demonstrating how they can be easily weaponized to extract highly sensitive personal data. The speakers, alongside their team (Cheping, Penny, Rush, and Ben), delve into the technical intricacies of compromising dash cams, from bypassing authentication mechanisms to exfiltrating video and audio recordings, and even sabotaging vehicle configurations.

The significance of this research cannot be overstated. Dash cams, initially seen as a simple accessory for insurance and accident documentation, are now revealed as potential gateways to a treasure trove of private information. With their widespread adoption – in Singapore, for instance, approximately eight out of ten cars are equipped with dash cams – the scale of potential compromise is immense. The presentation aims to raise critical awareness among both dash cam consumers and manufacturers about these pervasive security gaps and the urgent need for enhanced security measures in the vehicular ecosystem.

The talk goes beyond mere data theft, illustrating how compromised dash cams could potentially serve as a beachhead for lateral movement into a vehicle's broader infotainment system and even its critical Controller Area Network (CAN). This elevates the threat from a privacy concern to a potential vehicle safety and control risk, urging a re-evaluation of security postures across the automotive industry.

Background

▶ Watch: Introduction and Lego car attack demo (0:00)

The motivation for this research stems from the observed ubiquity of dash cameras, particularly in regions like Singapore, where they have become a "necessary accessory for car ownership," primarily for insurance purposes. Heat Security Labs conducted extensive reconnaissance, collecting over 1,000 dash cam SSIDs across the island. Their findings revealed that iRoad emerged as the most popular brand, accounting for 48.6% of their collected data, followed by 70 Mai at 12.5% and iDrive at 6.7%.

A key discovery during their initial research was the significant overlap in hardware and software across various dash cam brands. For example, iRoad shares a similar manufacturer with GNET in Korea, and Tonguan Electronics in China develops mobile applications for Wi-Fi connectivity used by multiple brands. Popular names like Thinkware, Black View, and Mabella were also part of their extensive testing. Furthermore, they noted that some OEM makers in Germany integrate dash cameras directly into vehicle infotainment systems, highlighting a potential for deeper integration and interconnected vulnerabilities.

The researchers tested approximately two dozen models across 15 brands. To build their attack tools, they initially acquired 20 dash cameras as a training dataset, humorously noting they could become "dash cam dealers" with their collection. They then validated their findings on 40 participants' dash cameras in a controlled, realistic environment. The attack technique developed, termed drive-thru hacking, is an advanced extension of traditional wardriving. While wardriving involves roaming for vulnerable networks, drive-thru hacking takes it a step further by specifically targeting dash cams from a stationary position, bypassing second-factor authentication, silencing voice warnings, authenticating into file storage services, dumping sensitive video and audio, and even sabotaging car configurations—all in an automated fashion. This method focuses on "low-hanging fruit" vulnerabilities, specifically default, fixed, or common passwords, ensuring a high success rate against poorly secured devices.

Key Findings

▶ Watch: Dash cam prevalence and research methodology (2:00)

The Heat Security Labs research uncovered a startling array of vulnerabilities and widespread poor security practices across the dash cam industry:

• Pervasive Default and Fixed Passwords: Out of 15 brands tested, all shipped with default passwords. A critical 14 of these brands used the same default password for every individual dash cam, while only one used randomly generated but still weak (8 lowercase alphabetical letters) passwords. Furthermore, four brands had uneditable SSID passwords, meaning anyone nearby could perpetually connect to them if the default was known.
• DNS Leakage and Man-in-the-Middle (MitM) Risks: Four brands were found to use a public domain (e.g., a .com domain) as their internal domain name. Worse, this domain was unregistered, creating a significant risk of DNS leakage and MitM attacks. The researchers registered the domain and attempted to disclose it to the manufacturer, but received no response.
• Bypass of Second-Factor Authentication (2FA) / Device Pairing:
• Direct HTTP Server Access: For dash cam model C, researchers could directly connect to the device's HTTP server and pull video recordings after connecting to its Wi-Fi network, completely bypassing the physical device pairing button.
• MAC Address Spoofing: For four brands with fixed passwords that relied on device pairing as their primary authentication, the dash cam remembered the MAC address of the trusted device. By performing an ARP scan to identify the trusted MAC address and then spoofing it, attackers could bypass 2FA.
• MFA Fatigue Attack: By continuously spamming pairing requests, the dash cam would repeatedly issue voice prompts for the user to press the Wi-Fi button. This could lead to "MFA fatigue," coercing a driver to press the button while on the road, granting the attacker full access.
• Unauthenticated Upload Endpoints and Arbitrary Command Execution: Several dash cams featured unauthenticated upload endpoints (e.g., /action/upload_file on dash cam K, or in the parent directory for model G). This allowed attackers to upload CGI-based webshells and execute arbitrary commands, leading to root access by dumping /etc/passwd and /etc/shadow files and cracking default passwords like "TINA".
• Plaintext Credentials and Insecure Protocols: Many dash cams exposed services like FTP, Telnet, and RTSP (Real-Time Streaming Protocol) with authentication. Credentials were often found in plaintext within APKs (Android Application Packages) or could be sniffed from traffic between mobile apps and the dash cam. Firmware analysis using tools like binwalk also revealed root passwords (e.g., Dash Cam L).
• Custom Protocols: Models B and O utilized custom protocols over specific ports (7777 for API, 7778 for video, 7779 for audio), which could be exploited with specific byte sequences to download media files.
• Configuration Sabotage and Denial of Service (DoS):
• Attackers could disable battery protection, causing the dash cam to continuously record until the car battery died, resulting in a DoS.
• Config files could be overwritten to change passwords, even for models with "fixed" passwords, potentially locking legitimate users out (especially for Dash Cam K which had no reset button).
• Weak network stacks on models like Dash Cam Q allowed for remote disabling of the camera by triggering a crash.
• Cloud Synchronization Vulnerabilities: Dash cam model D, which offers cloud synchronization, was found to expose public live feeds of video and audio. Anyone could view these feeds via the mobile app, revealing private conversations, routes, and even home addresses. The manufacturer's response: "a feature, not a bug," with privacy warnings buried in "optimistically written" fine print.
• Poor Security Hygiene: A concerning finding was that 5 out of 20 secondhand dash cameras purchased by the researchers came with SD cards full of recordings, highlighting a severe lack of data sanitization by previous owners.
• Low Manufacturer Engagement: Out of 15 brands, only one had a dedicated security email address. While 11 had generic contact forms, three budget cameras had no contact methods at all. Only five accepted the findings, and only one had mitigated the issue via a mobile app update at the time of the talk.

Technical Deep Dive

▶ Watch: Detailed 'Drive-Through Hacking' attack flow (4:20)

The drive-thru car hacking methodology developed by Heat Security Labs is a sophisticated, multi-stage attack flow designed for automation and efficiency. It leverages a combination of reconnaissance, authentication bypass techniques, service exploitation, and data exfiltration, culminating in advanced data processing.

The initial phase, Discovery, resembles wardriving but is optimized for stationary operation. The attackers use tools like the Flipper Zero equipped with the Marauder module to scan the environment for dash cam SSIDs. Once a target SSID is identified, a model-specific script is executed. This script attempts to connect using known default passwords, which are prevalent across 14 out of 15 tested brands. For the one brand with unique default passwords, their weak eight-lowercase-letter complexity makes them vulnerable to cracking within hours. Crucially, four brands had uneditable SSID passwords, making them perpetually accessible once the default is known.

Authentication Bypass is a critical component. For dash cam model C, direct connection to the device's HTTP server after joining its Wi-Fi network completely bypassed the advertised physical pairing requirement. For other models, particularly those with fixed passwords that relied on a physical Wi-Fi button press for pairing, the team developed two techniques:

1. MAC Address Spoofing: The dash cam remembers the MAC address of the paired device. Attackers perform an ARP scan to identify the trusted device's MAC address and then use their attacking device (e.g., a Kali Linux system on a Raspberry Pi, referred to as "Khalif Pi") to spoof that MAC address, granting unauthorized access.
2. MFA Fatigue: By repeatedly sending pairing requests to the dash cam, the device is triggered to issue continuous voice prompts (e.g., "Press the Wi-Fi button to register the smartphone three consecutive times"). This "irritating vector" aims to induce the driver to press the button, inadvertently granting access.

To maintain stealth during the attack, an additional API call is sent at the script's inception to reduce or temporarily disable voice guidance from the dash cam. This prevents the owner from noticing unusual activity. Voice guidance is restored at the end of the script.

Once connected to the dash cam's network, Service Enumeration is performed using tools like Nmap to identify open ports and running services. Common services include FTP, Telnet, HTTP, and RTSP. For authenticated services, credentials are often found in plaintext. The researchers' primary methods for credential extraction included:

• APK Analysis: Decompiling mobile applications associated with the dash cams to find hardcoded credentials for FTP, Telnet, and APIs.
• Traffic Sniffing: Monitoring communication between the official mobile app and the dash cam.
• Firmware Analysis: Downloading firmware from manufacturer websites (often without authentication) and using tools like binwalk to extract embedded file systems and uncover root or user passwords (e.g., Dash Cam L).

Some dash cams, like models B and O, utilized custom protocols over specific ports (7777 for API, 7778 for video, 7779 for audio). The researchers reverse-engineered these protocols, discovering specific byte sequences that could be sent to the API port (7777) to trigger the opening of video and audio ports for a short window, allowing for the download of media files.

Arbitrary Command Execution and Persistence was achieved on several models. Dash cam K, for instance, had an unauthenticated upload endpoint at /action/upload_file. By fingerprinting the web server, the team created and uploaded a CGI-based webshell, enabling them to run arbitrary commands like ifconfig to confirm execution. This access allowed them to dump /etc/passwd and /etc/shadow files, which revealed default passwords like "TINA" upon cracking, granting full privilege access. Similar unauthenticated upload endpoints were found on model G, making it even easier to compromise.

Beyond root access, attackers could:

• Overwrite Configuration Files: For the four brands that initially prevented password changes, the researchers found they could overwrite configuration files to set new passwords. This could be used by legitimate users to harden their devices but also by attackers to lock users out (especially problematic for Dash Cam K which lacked a physical reset button).
• Sabotage Functionality: Overwriting URL shortcut files to point to malicious links, or disabling battery protection to drain the car's battery and cause a denial of service (DoS).
• Bricking Devices: While attempting to upgrade a webshell to a reverse shell by uploading a netcat binary, one dash cam (model K) was bricked beyond salvage, highlighting the delicate nature of these embedded systems. Model Q, with its weak network stack, could be remotely disabled by triggering a crash, requiring the owner to wait for the internal battery to die before a restart was possible.

The exfiltrated video and audio recordings were then fed into an advanced Data Exfiltration and Analysis Pipeline. This pipeline leveraged several technologies:

• Python video processing packages for initial extraction.
• Machine learning for classifying and predicting road signs from video frames.
• Google Cloud Vision OCR for text abstraction from images.
• OpenAI LLMs (Large Language Models) to guess locations, derive latitude and longitude from GPS data, and map routes.
• Shazam to identify songs in audio recordings.
• OpenAI Whisper for parallel transcription of spoken audio.
• OpenAI LLMs again to summarize insights from the combined text and audio data into a text and comic form, effectively profiling individuals and extracting sensitive conversations (e.g., confidential discussions about mergers, family plans, or war news).

The researchers successfully compromised 11 out of 40 participant dash cams, primarily those similar to their training set. They noted that 65% of participants used dash cams that did not allow password changes, contributing to the high vulnerability rate.

Finally, the talk hinted at future research into lateral movement from compromised dash cams. The hypothesis involves spoofing connectivity, performing Man-in-the-Middle attacks between the dash cam app and the infotainment system, injecting exploits to compromise the infotainment system, and then moving laterally to the vehicle's CAN gateway to issue arbitrary CAN commands to the Electronic Control Unit (ECU). This represents a significant escalation of the threat, moving from data privacy to direct vehicle control.

Demo / Proof of Concept

▶ Watch: Prevalence of default and uneditable dash cam passwords (6:30)

The presentation included several compelling demonstrations and validations of their findings:

1. Initial Lego Car Teaser: George started with a miniature Lego car mounted with a dash cam using default factory configurations. He demonstrated running a script that automatically searched for the dash cam's SSID, connected to it using default settings, and displayed a live video feed from the camera. This quick demo immediately highlighted the ease of access to many devices.
2. MAC Address Spoofing for 2FA Bypass: The team showcased their "Khalif Pi" (a Kali Linux-enabled Raspberry Pi) performing an ARP scan to identify the MAC address of a trusted, paired device. They then demonstrated spoofing this MAC address to completely bypass the dash cam's second-factor authentication mechanism, gaining unauthorized access.
3. MFA Fatigue Attack: A proof of concept was shown where their script continuously spammed a dash cam with pairing requests. The dash cam responded with a robotic voice repeatedly instructing the user to "Press the Wi-Fi button to register the smartphone three consecutive times," illustrating how this could lead to driver fatigue and accidental authorization.
4. Web Shell Execution and Privilege Escalation: On dash cam K, the researchers demonstrated exploiting an unauthenticated upload endpoint. They uploaded a CGI-based web shell and executed arbitrary commands, such as ifconfig, to validate their control. They further showed dumping /etc/passwd and /etc/shadow files, leading to the cracking of the default password "TINA" and achieving root access.
5. Configuration Sabotage: The demo included disabling battery protection on a dash cam, showing how this could lead to the car battery draining overnight. They also demonstrated changing the password of a dash cam by overwriting its configuration file, even for models that supposedly did not allow password changes, effectively locking out legitimate users.
6. Remote Camera Disablement: For dash cam model Q, a script was triggered to exploit its weak network stack, causing the camera to crash. The visual cue of the dash cam's lights changing from green to blue then red effectively demonstrated a remote denial of service, with the camera becoming unresponsive until its internal battery completely drained.
7. Insights Dashboard and AI Comic: The team presented a visual "insights dashboard" generated by their LLM pipeline. This dashboard showcased extracted information such as songs playing (identified by Shazam), routes taken, and summarized confidential discussions (e.g., about a potential merger). An "AI comic" was also generated to visually summarize events from the recordings.
8. Public Live Feeds (Cloud Dash Cam): A striking demonstration involved dash cam model D, which offers cloud synchronization. The researchers showed how anyone could download the mobile app and view public live feeds from various dash cams across Singapore. This included a video showing car owners discussing payment and revealing a home address, and another of tourists discussing slimming tips, highlighting the severe privacy implications of "features" that publicly stream private vehicle interiors and conversations.

The research's exploitability was validated through an audit exercise involving 40 participants (friends and family). The tool successfully compromised 11 of these dash cams. This real-world testing confirmed that a significant number of dash cams on the road are indeed vulnerable, with 65% of participants using models that didn't even allow password changes, thus relying entirely on insecure default configurations.

Defensive Implications

▶ Watch: DNS leakage vulnerability due to unregistered domains (8:00)

The findings from the drive-thru car hacking research highlight severe security deficiencies in dash cameras and necessitate a multi-faceted defensive strategy involving both manufacturers and consumers.

For Manufacturers:

1. Adopt Secure by Design/Default: Manufacturers must integrate security from the initial design phase rather than as an afterthought. This includes ensuring strong, unique, and user-editable passwords are the default, and implementing robust security features that are active out-of-the-box.
2. Strengthen Authentication and Pairing:

• Enforce Strong Passwords: Allow users to set strong, unique Wi-Fi passwords and enforce complexity requirements.
• Secure Device Pairing: Implement robust encryption and challenge-response mechanisms for device pairing to prevent unauthorized remote connections. The current reliance on physical button presses or MAC address memory is insufficient.
• Secure APIs: Ensure all APIs are authenticated using mechanisms like API keys and that only authorized clients can connect to servers.
• Implement 2FA/MFA: For cloud-connected dash cams, multi-factor authentication should be mandatory for accessing stored data.
• Certificate-Based Pairing: Consider implementing certificate-based pairing for enhanced trust and authentication.
• Proper Password Hashing: All stored passwords must be properly hashed and salted, not stored in plaintext within APKs or firmware.
• TLS 1.2/1.3: Mandate the use of minimally TLS 1.2 or preferably TLS 1.3 for all server-client communications to ensure data in transit is encrypted.

1. Reduce Attack Surface:

• SSID Control: Allow users to turn off SSIDs or switch them to non-broadcast mode to make devices less discoverable.
• Minimize Open Ports/Services: Only expose necessary services and ensure they are properly secured and authenticated. Remove or disable insecure protocols like FTP and Telnet.
• Threat Modeling: Conduct thorough threat modeling exercises to identify potential attack scenarios and vulnerabilities proactively.

1. Secure Firmware Updates:

• Over-the-Air (OTA) Updates: Provide firmware updates securely over-the-air via encrypted channels.
• Authenticated Downloads: Make firmware downloads from websites available only to authenticated customers to prevent unauthorized access and analysis by attackers.
• Proactive Notifications: Prompt users through the mobile app about security-related firmware updates.

1. Improve Responsible Disclosure and Collaboration:

• Dedicated Security Contact: Establish a dedicated security email address or contact form for researchers to report vulnerabilities (as only 1 of 15 manufacturers had one).
• Vulnerability Disclosure Programs (VDPs) / Bug Bounty Programs (BBPs): Implement VDPs or BBPs to incentivize researchers to find and report vulnerabilities responsibly.
• Industry Collaboration: Partner with OEMs, automotive manufacturers, regulators, and the broader cybersecurity community to strengthen the overall security posture of the vehicular ecosystem.

For Consumers:

1. Change Default Passwords Immediately: If your dash cam allows password changes, always change the default password to a strong, unique one.
2. Be Aware of Privacy Settings: Understand your dash cam's privacy settings, especially for cloud-connected models. Be extremely cautious about enabling "public live feeds" or similar features, as they can expose highly personal information.
3. Update Firmware Regularly: Ensure your dash cam's firmware is kept up-to-date, as manufacturers may release patches for security vulnerabilities.
4. Exercise Caution with Secondhand Devices: Be aware that secondhand dash cams may contain previous owners' sensitive recordings. Always format the SD card and reset the device to factory settings.
5. Consider SSID Broadcasting: If your dash cam allows it, disable SSID broadcasting to make it less visible to casual scanners.

The research underscores that while individual vulnerabilities might appear low in severity, when chained together, they can lead to a complete compromise of a dash cam, remote root access, and potential lateral movement into critical vehicle systems. This necessitates a collective effort to improve security from design to deployment and ongoing maintenance.

Key Takeaways

• Ubiquitous and Insecure: Dash cameras are widely adopted but suffer from severe, widespread security vulnerabilities, making them easy targets for attackers.
• Default Passwords are a Major Flaw: A significant number of dash cams ship with easily guessable, fixed, or unchangeable default passwords, providing an immediate entry point for attackers.
• Beyond Data Theft: "Drive-thru hacking" allows not only for the exfiltration of sensitive video, audio, and location data but also for device sabotage, including disabling battery protection, bricking devices, and locking out legitimate users.
• Authentication Bypass is Common: Physical pairing mechanisms and basic Wi-Fi passwords are often circumvented through techniques like MAC address spoofing, direct HTTP server access, or MFA fatigue attacks.
• Privacy Compromised by Design: Some cloud-connected dash cams expose public live feeds, revealing private conversations, routes, and home addresses, often marketed as a "feature" rather than a privacy risk.
• Potential for Lateral Movement: Compromised dash cams could serve as a beachhead for further attacks, potentially enabling lateral movement into a vehicle's infotainment system and critical CAN network, posing risks to vehicle control.
• Urgent Need for Manufacturer Action: Manufacturers must adopt a secure by design/default approach, implement robust authentication (including 2FA/MFA), secure firmware update mechanisms, and engage with security researchers through dedicated channels and vulnerability disclosure programs.

About the Speaker(s)

Alina is the co-founder of Heat Security Labs and identifies herself as a "car person." She is a security architect and played a pivotal role in leading this research, focusing on the broader implications of dash cam vulnerabilities.

George is also a co-founder of Heat Security Labs and describes himself as a "Lego person," perhaps alluding to his methodical approach to breaking down complex systems. He is also a security architect and a key speaker in this presentation, showcasing the technical demonstrations and findings.

They were supported by a dedicated team including Cheping, Penny, Rush, and Ben, whose contributions were instrumental in conducting this in-depth research. Alina and George's combined expertise in security architecture and their passion for uncovering overlooked vulnerabilities made this comprehensive investigation into dash cam security possible.