Inside Dash Cam Custom Protocols and Discovered 0days

Inside Dash Cam Custom Protocols and Discovered 0days

Speakers: Hyo Jin Lee, Hanryeol Park

Conference: DEF CON 32

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

Overview

This presentation, "Inside Dash Cam Custom Protocols and Discovered 0days," delivered by Hyo Jin Lee and Hanryeol Park, delves into the often-overlooked security landscape of modern dash cameras. The talk highlights the rapid growth of the global dash cam market, projected to reach a value of $4.03 billion in 2023 with a compound annual growth rate of 9.6% from 2024 to 2030. While this growth is driven by increased convenience and connectivity features like Wi-Fi and cloud integration, the speakers underscore a critical security deficit: a mere three CVEs reported in the past three years for an entire product category now integral to millions of vehicles.

The researchers, from Zien, an Xiot Security Convergence Company, aim to raise awareness about the inherent security risks in these ubiquitous devices. Their work involved a comprehensive analysis of nine different dash cam models—four from Korea, one from China, and four built-in OEM devices. Through this extensive research, they uncovered multiple zero-day vulnerabilities across various categories, ranging from shell script execution flaws to stack buffer overflows, OS command injection, and improper authentication in custom communication protocols. The presentation not only details their methodology for firmware acquisition and binary analysis but also outlines specific attack scenarios and provides actionable recommendations for manufacturers to bolster device security. This research is crucial for enhancing the security posture of a rapidly expanding market that, despite its critical role in vehicle safety and evidence collection, remains significantly underexamined from a cybersecurity perspective.

Background

▶ Watch: Talk Introduction and Agenda Overview (0:00)

The evolution of dash cams has moved beyond simple SD card storage to embrace sophisticated network connectivity, enabling features like remote access, live view, and cloud storage. This technological shift, while enhancing user convenience, has simultaneously expanded the attack surface for these devices. Despite this increased complexity and the critical data they handle, dash cams have historically received minimal attention from the security research community, as evidenced by the alarmingly low number of reported CVEs. The speakers' motivation stems from this disparity, seeking to illuminate the potential dangers lurking within these devices and encourage a proactive approach to security by manufacturers.

Their analysis encompassed a diverse set of dash cams, categorized by origin and type. Korean dash cams often provide firmware downloads on official websites and sometimes offer cloud services. Chinese models also provide firmware downloads and were notably found with open Telnet ports. Built-in dash cams, frequently OEM devices, typically lack official firmware downloads and often utilize the RTSP protocol for live streaming. The OEM nature of many built-in devices implies that a single vulnerability could impact a wide range of branded products, underscoring the need for robust security at the manufacturing source. Dash cam connectivity, a primary vector for new threats, primarily falls into three types: direct connection via Bluetooth and the dash cam's Wi-Fi AP mode; communication through a phone's hotspot; and cloud-based communication, where the dash cam connects to the internet via a router. Understanding these connectivity paradigms is fundamental to identifying potential attack paths and designing appropriate defensive measures.

Key Findings

▶ Watch: Dash Cam Connectivity Methods Explained (3:00)

The comprehensive analysis of nine dash cam models yielded several significant findings across firmware accessibility, network posture, and internal architecture. The researchers successfully obtained firmware for most devices through various methods, highlighting a general lack of strong protection against reverse engineering. Notably, five out of nine devices featured accessible UART shells, with four of these allowing shell access without any password, and one even running a custom shell. This prevalence of easily accessible debugging interfaces presents a significant security weakness, providing direct entry points for attackers.

Port scanning using Nmap revealed common open services, including FTP (port 21), Telnet (port 23), DNS (port 53), HTTP (port 80), RPC (port 111), and RTSP (port 554). The presence of these widely known ports, especially Telnet and FTP, without proper authentication or security hardening, indicates a fundamental lack of secure configuration. Furthermore, the communication protocols employed by these devices were a key area of discovery. Six of the analyzed dash cams utilized custom protocols, four had web interfaces, two supported cloud services, and one even used encrypted communication, which the researchers bypassed using Frida to inspect plaintext packets.

A critical challenge during dynamic analysis was the presence of watchdog timers, which reboot devices upon detecting unresponsiveness. The team successfully bypassed these in three distinct ways: leveraging an existing watchdog stop function in initial boot scripts, interrupting the boot script with Ctrl+G, and modifying boot arguments within the bootloader. These bypass techniques were essential for enabling dynamic debugging with GDB. These findings collectively paint a picture of an ecosystem ripe for security vulnerabilities, characterized by accessible debugging interfaces, insecure network services, custom and often unauthenticated protocols, and a general lack of robust security engineering practices.

Technical Deep Dive

▶ Watch: Common Open Ports & Services Discovered (6:05)

The researchers employed a meticulous, multi-stage methodology to analyze the dash cams, beginning with firmware acquisition, progressing to static and dynamic analysis, and culminating in protocol examination.

Firmware Acquisition: This initial and crucial step involved four primary methods:

1. Official Websites: Many Korean and Chinese dash cam vendors provided firmware downloads directly from their official support pages, simplifying initial access.
2. Debugging Ports: The presence of physical debugging interfaces like UART and JTAG proved invaluable. The team found UART ports in five out of nine devices, four of which allowed passwordless shell access, and one had a custom shell. This direct shell access enabled copying firmware to an SD card for extraction.
3. Firmware Upgrade Functionality: By analyzing the firmware upgrade process, researchers could either identify direct download URLs or capture network packets to obtain the latest firmware versions.
4. APK File Extraction: For dash cams with dedicated mobile applications, firmware-related APK files were often found within the app's installation directory via an ADB shell, which could then be extracted and decompressed.

Initial System Analysis:

Once firmware was obtained, the next steps focused on understanding the system's architecture and running services:

1. Port Scanning: Using tools like Nmap, the team identified open ports and the services running on them. Common findings included FTP (port 21), Telnet (port 23), DNS (port 53), HTTP (port 80), RPC (port 111), and RTSP (port 554). The presence of these well-known ports often indicated potential entry points for attackers.
2. Boot Logic Analysis: Files within /etc/init.d, /etc/rc.local, and system daemon configuration files were scrutinized to understand the sequence of scripts executed during boot. For example, the rcS file in /etc/init.d was observed to execute all files starting with 'S' in that directory, providing a clear path to understanding critical system initialization.
3. Process and Network State Analysis: With shell access, commands like ps were used to list running processes and identify main binaries, while netstat helped map open ports to their corresponding binaries, offering insights into the system's operational state.

Binary Debugging:

To perform dynamic analysis and identify vulnerabilities within the main binaries, the researchers leveraged standard debugging tools:

• Tools: GDB and Busybox were stored on an SD card for convenient access.
• Vulnerable Function Tracking: The main binaries were decompiled and analyzed for calls to known vulnerable functions such as system(), fopen(), strcpy(), gets(), and scanf(). The team also utilized their R&D solution, GIOT, to visualize and analyze vulnerabilities efficiently.
• GDB Debugging: Using the UART shell, GDB was attached to the PID (Process ID) of the running main binary, allowing real-time analysis of its behavior and debugging of vulnerabilities.

Watchdog Timer Bypass:

A significant hurdle in dynamic debugging was the watchdog timer, which would reboot the device if it became unresponsive. The researchers developed three effective bypass techniques:

1. Initial Script Modification: In one case, the initial boot script contained a function to stop the watchdog (e.g., writing 183A to a specific test register). Executing this command allowed for dynamic debugging.
2. Boot Interruption: For another device, repeatedly pressing Ctrl+G during boot interrupted the boot script. The watchdog disable code was then executed, followed by resuming the script, enabling GDB debugging.
3. Bootloader Argument Modification: The most intrusive method involved accessing the bootloader (e.g., by pressing ESC and F1 repeatedly). Here, the init value in the boot arguments was modified from Linux RC to bin/sh, and no watchdog was added. This allowed manual, line-by-line execution of initial scripts and GDB debugging of the main binary.

Protocol Analysis:

Understanding the communication between the mobile app and the dash cam was crucial for uncovering logic flaws and authentication bypasses.

• Methods: This involved capturing and analyzing communication packets, as well as reverse engineering the APK code and dash cam binary code.
• Custom Protocols: Six of the analyzed dash cams used custom protocols, primarily in hex or JSON formats.
• B vendor: Used a hex format with four bytes for dummy data, two for the command number, and four or more for parameters.
• M vendor: Employed a hex format with four bytes for the command number, four for packet length, another four for the command number, and four or more for parameters.
• T vendor: Used a JSON format with three keys: a session token, a message ID (command number), and param (parameters). Analyzing these unique structures was key to understanding communication content.
• Encrypted Communication: For the device using encrypted communication, the researchers successfully used Frida to hook the app and inspect plaintext packets, bypassing the encryption layer.

This deep dive into the methodology underscores the complexity of analyzing embedded devices and the ingenuity required to overcome obstacles like watchdog timers and custom protocols. The findings highlight a systemic lack of security-by-design in many dash cam products.

Demo / Proof of Concept

▶ Watch: Analyzing Boot Logic and Running Processes (8:00)

While the presentation did not feature a live demonstration, the speakers meticulously detailed four distinct zero-day scenarios that illustrate the types of vulnerabilities discovered and how they could be exploited. These scenarios serve as proofs of concept, demonstrating the practical implications of the identified security flaws.

1. Shell Script Execution (SD Card Vulnerability):

• Vulnerability: The boot script of certain dash cams was found to include code that executes a file named test.sh from the inserted SD card path. This functionality, likely intended for developer testing or debugging, was left enabled in production firmware.
• Exploitation: An attacker could craft a malicious test.sh file containing commands to establish persistent access, such as launching a Telnet daemon binary. When this SD card is inserted into the vulnerable dash cam and the device boots, the test.sh script is automatically executed, opening a Telnet connection and granting the attacker a shell with elevated privileges. This provides full control over the device.

1. Stack Buffer Overflow (RTSP Live View Vulnerability):

• Vulnerability: The live view feature, often implemented using the RTSP protocol, was susceptible to stack buffer overflows. This occurs when the dash cam's software fails to properly validate the length of incoming data, specifically within RTSP header parsing.
• Exploitation: An attacker would craft a specially malformed RTSP request. By hooking the dash cam app's library, the attacker could modify the RTSP header data to exceed the allocated buffer size. This overflow could overwrite critical memory regions, including the PC (Program Counter) register, which controls the flow of execution. Through careful gadget chaining (identifying existing code snippets within the device's memory and linking them), an attacker could achieve arbitrary code execution, ultimately gaining a shell on the device.

1. OS Command Injection (Device Settings Vulnerability):

• Vulnerability: Many dash cams allow users to configure various settings (Wi-Fi, ADAS, GPS, etc.) via the mobile app. When these configuration packages are sent to the dash cam, some devices fail to properly validate special characters in the input data before passing them to system functions.
• Exploitation: An attacker could intercept the device configuration packets using a proxy tool. By manipulating the data to inject special characters like backticks (` `) or dollar parenthesis ($(...)`), which are used for command substitution in shell environments, the attacker could inject arbitrary OS commands. If the dash cam's internal system functions execute this unvalidated input, the injected commands would run with the privileges of the dash cam's firmware, allowing the attacker to take control of the system.

1. Improper Authentication (Custom Protocol Vulnerability):

• Vulnerability: A pervasive issue found in dash cams utilizing custom communication protocols was the complete lack of authentication for accessing critical functions. Many functions, such as requesting file lists or formatting the SD card, could be accessed by simply sending the correct command packet without any prior authentication.
• Exploitation: An attacker could capture a legitimate packet, for instance, one requesting a file list from the SD card. Even if the packet format is complex (e.g., four bytes for command number, four for packet length, another four for command number, and four for parameters), replicating and replaying this exact packet to the dash cam would trigger the corresponding function. This replay attack could be used to retrieve sensitive data or execute destructive actions like formatting the SD card, all without any form of authentication or authorization. This highlights a fundamental design flaw where trust is implicitly placed on any incoming command packet.

These scenarios vividly illustrate how seemingly minor architectural or coding oversights can lead to severe security breaches, granting attackers full control over the dash cam and potentially sensitive data.

Defensive Implications

▶ Watch: Watchdog Timer Bypass Techniques (10:00)

The findings from this research underscore a pressing need for significant improvements in the security posture of dash cams. Manufacturers must adopt a security-by-design approach to protect consumers and the integrity of the data collected by these devices.

1. Remove Script Execution Code: The most immediate and critical recommendation is to completely remove any script execution code from accessible paths like the SD card, especially if it's intended for developer testing. Such functionalities should be disabled or stripped from production firmware to prevent unauthorized code execution.
2. Enhance Communication Security: All communication between the dash cam, its mobile app, and cloud services must incorporate robust authentication and verification processes. This includes mutual authentication, strong cryptographic protocols, and proper session management to prevent replay attacks and unauthorized access to device functions. Encrypted communication should be implemented end-to-end, and the encryption keys must be securely managed.
3. Implement Thorough Input Validation: A fundamental defense against OS command injection and buffer overflow vulnerabilities is stringent input validation. All user-supplied or network-received data must be meticulously checked for special characters, length constraints, and expected data types before being processed by system functions or written to memory buffers. Parameterized queries should be used where applicable, and safe string handling functions should replace vulnerable ones like strcpy and gets.
4. Secure Debugging Ports: Debugging interfaces like UART and JTAG should be physically disabled or, at minimum, password-protected in production devices. Default or easily guessable credentials for debugging shells must be eliminated.
5. Secure Boot and Firmware Updates: Implement secure boot mechanisms to ensure only cryptographically signed and trusted firmware can be loaded. Firmware update processes should also be secure, verifying firmware integrity and authenticity before installation to prevent malicious updates.
6. Address OEM Device Security: Given the prevalence of OEM devices, manufacturers producing components or base designs for multiple brands must ensure their core firmware is secure. A vulnerability in one OEM component can propagate across numerous products, magnifying the risk.
7. Increase Industry Awareness and Collaboration: The dash cam industry needs to collectively acknowledge and address these security challenges. This includes establishing industry-wide security standards, participating in vulnerability disclosure programs, and collaborating with security researchers to proactively identify and mitigate risks.
8. Regular Security Audits and Penetration Testing: Manufacturers should routinely conduct security audits and penetration tests on their devices and associated applications to identify and remediate vulnerabilities before they can be exploited in the wild.

By implementing these defensive measures, dash cam manufacturers can significantly enhance the security of their products, safeguarding user privacy, vehicle integrity, and critical data from potential attackers.

Key Takeaways

• Growing Market, Lagging Security: The dash cam market is experiencing significant growth driven by network connectivity, yet security measures have not kept pace, with only three CVEs reported in three years despite an expanding attack surface.
• Widespread Vulnerabilities: Dash cams exhibit common, critical vulnerabilities including shell script execution from SD cards, stack buffer overflows in RTSP streams, OS command injection via device settings, and improper authentication in custom communication protocols.
• Easy Firmware Access and Debugging: Many devices allow easy firmware acquisition from official websites or APKs, and often feature insecure debugging ports (e.g., passwordless UART shells), providing direct access for attackers.
• Custom Protocols are a Weak Point: The prevalent use of custom, often unauthenticated, communication protocols exposes devices to replay attacks and unauthorized function execution, highlighting a lack of secure protocol design.
• Watchdog Bypass Techniques Exist: Researchers demonstrated multiple methods to bypass watchdog timers, allowing for dynamic analysis and debugging of device binaries, which is crucial for uncovering deeper vulnerabilities.
• Urgent Need for Secure Development: Manufacturers must adopt robust security practices, including thorough input validation, strong authentication, secure boot, and removal of development-only features from production devices, to protect users and the integrity of these critical vehicle accessories.

About the Speaker(s)

Hyo Jin Lee and Hanryeol Park are researchers at Zien, an Xiot Security Convergence Company. Their work focuses on conducting research and development in the field of automated Xiot firmware SECaaS solutions. They are continuously advancing their efforts to enhance the security of IoT devices, including the comprehensive analysis of dash cams presented in this talk.