UDSonCAN Attacks Discovering Safety Critical Risks by Fuzzing

UDSonCAN Attacks Discovering Safety Critical Risks by Fuzzing

Speakers: Seunghee Han, Security Researcher, Autocrypt

Conference: DEF CON 32

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

Overview

This talk, presented by Seunghee Han of Autocrypt at DEF CON 32, unveiled critical safety vulnerabilities discovered in "latest EV models" through the application of UDS (Unified Diagnostic Services) fuzzing techniques. The presentation highlights a significant security oversight where fundamental diagnostic services, intended for repair and testing, remain active and exploitable while a vehicle is in motion, directly contravening established automotive cybersecurity standards.

The research demonstrates two alarming real-world attack scenarios: causing a sudden stop in a moving vehicle and completely disabling a vehicle's functionality. These findings are not merely theoretical; they were demonstrated on a new EV SUV model, underscoring immediate, safety-critical risks to both vehicle occupants and the broader public. The work by Autocrypt, a mobility security company deeply involved in helping OEMs achieve CSMS (Cyber Security Management System) certification under WP.29 regulations, provides a stark reminder that even with increasing industry focus on cybersecurity, fundamental flaws can persist.

The talk serves as a crucial wake-up call for the automotive industry, emphasizing the imperative for stringent adherence to diagnostic protocol specifications like ISO 14229 throughout the vehicle's operational lifecycle. The implications extend beyond individual vehicle models, pointing to systemic challenges in implementing and validating secure diagnostic architectures across the modern automotive ecosystem.

Background

▶ Watch: Introduction and demonstration of critical vehicle vulnerability (0:00)

The modern vehicle is a complex network of electronic control units (ECUs) that communicate extensively to manage everything from engine performance to infotainment. Central to the diagnostic and maintenance process for these sophisticated systems is the Unified Diagnostic Services (UDS) protocol, defined in ISO 14229. UDS allows diagnostic tools to communicate with ECUs, read fault codes, reflash software, and perform various tests. It's the standard language spoken by technicians in repair shops to understand and fix vehicle issues. Given its privileged access to critical vehicle functions, UDS incorporates various security measures, though their implementation and robustness can vary.

The communication backbone for UDS messages in most vehicles is the Controller Area Network (CAN) bus. CAN is a robust, message-based protocol, but it was originally designed without inherent security mechanisms like authentication or encryption. This lack of inherent security at the bus level means that once an attacker gains access to the CAN bus (e.g., via the OBD-II port), they can inject arbitrary messages, including UDS commands, without significant internal hurdles from the CAN protocol itself.

To proactively identify vulnerabilities, the automotive industry widely employs fuzzing – a software testing technique where invalid, unexpected, or random data is fed as inputs to a computer program or system to test its robustness and discover coding errors or security loopholes. In the vehicle industry, black-box fuzzing is common, where testers interact with the system without internal knowledge of its code or architecture, typically using commercial fuzzers to send a wide range of UDS messages over the CAN bus. This approach aims to simulate various stressful or abnormal conditions to uncover how the system behaves under duress. The speaker noted that many previous talks at forums like the Car Hacking Village (CHV) have delved into CAN, UDS, and UDS fuzzing, indicating a well-established research area.

The context for this research is further shaped by global regulatory efforts such as the UN Regulation No. 155 (UN R155), part of the WP.29 framework, which mandates Cyber Security Management Systems (CSMS) for vehicle manufacturers. These regulations, which came into effect in 2020, require car makers to demonstrate robust cybersecurity practices throughout the vehicle lifecycle, from design to post-production. Companies like Autocrypt play a critical role in assisting OEMs and tier suppliers in achieving CSMS certification, often through extensive security testing, including fuzzing. It was during such rigorous fuzzing tests for a "new latest EV model" that the presented critical vulnerabilities were unexpectedly discovered, highlighting that even with increased industry focus and regulatory pressure, fundamental security weaknesses can still slip through.

Key Findings

▶ Watch: Two vulnerable UDS services: ECU reset and communication control (4:10)

The core findings of this research revealed that two specific UDS services, ECU Reset and Communication Control, were found to cause significant vehicle malfunctions when targeted with fuzzing techniques. While the talk touched upon both, the detailed demonstrations and explanations focused predominantly on the ECU Reset service due to its immediate and severe safety implications.

The primary vulnerability identified stemmed from the ECU Reset service (Service ID 0x11) remaining active and accessible even when the vehicle was in an operational state, specifically "drive mode." This directly contradicts the safety guidelines outlined in ISO 14229, which specifies that critical diagnostic services should not be available when the system is in an "operational mode" (i.e., driving). The standard dictates that the server (ECU) condition for such services should be "ignition is on and system not be in an operational mode." The failure to enforce this restriction opened the door for two distinct and highly dangerous real-world attack scenarios:

1. Sudden Stop Scenario: This attack involves sending an ECU Reset message to a vehicle while it is actively moving. The research demonstrated that this command could instantly stall the engine and bring the vehicle to an abrupt halt. The video evidence showed the vehicle stopping without the brake pedal being pressed, indicating a complete loss of powertrain control. Such an unexpected stop, especially at higher speeds, carries an extremely high risk of causing severe accidents, mechanical failures, or damage to the vehicle and its occupants.

1. Vehicle Disabling Scenario: In this scenario, ECU Reset messages are sent continuously to a vehicle, whether it is stopped or in motion. The effect is to render the vehicle inoperable, preventing it from being controlled or driven until the attacker ceases the malicious commands. This effectively disables the vehicle, potentially stranding occupants in dangerous locations or preventing emergency services from using the vehicle. The speaker emphasized the alarming nature of this attack, noting that the vehicle's usability remains compromised for an indefinite period, dictated solely by the attacker's actions.

The target of these attacks was identified as the Gateway Control Unit (GCU) of a "new latest EV SUV model." The GCU plays a crucial role in filtering and routing communications between different CAN buses and ECUs within the vehicle. Its vulnerability to these UDS commands suggests a fundamental flaw in its state management or message filtering logic, failing to correctly interpret the vehicle's operational status and restrict dangerous diagnostic services accordingly. The discovery underscores a critical gap in the implementation of cybersecurity best practices even in contemporary electric vehicles, despite the increasing focus on automotive security and regulatory compliance.

Technical Deep Dive

▶ Watch: Detailed explanation of the ECU reset service vulnerability (4:50)

The technical foundation of these attacks lies in the Unified Diagnostic Services (UDS) protocol, specifically leveraging the ECU Reset service (Service Identifier 0x11). UDS, standardized by ISO 14229, is a set of diagnostic services used to query, control, and test ECUs within a vehicle. These services are typically accessed via the OBD-II port, providing a standardized interface for diagnostic tools.

The ECU Reset service is designed for legitimate purposes such as troubleshooting, system initialization, or software updates. It allows a diagnostic tool to command an ECU to perform a reset, similar to rebooting a computer. The service supports various sub-functions, including:

• 0x01: Hard Reset, which typically involves a full power cycle or a complete re-initialization of the ECU.
• 0x03: Soft Reset, which might involve restarting specific software components without a full hardware reset.

The speaker demonstrated sending an actual message for a hard reset, which would be represented as 0x11 0x01 on the CAN bus, followed by any necessary data bytes.

The critical vulnerability was rooted in the misconfiguration or lack of proper state validation for the ECU Reset service within the target vehicle's Gateway Control Unit (GCU). According to ISO 14229-1: Unified diagnostic services (UDS) — Part 1: Application layer, there are specific conditions under which diagnostic services should be active or inactive. For services with safety implications, the standard explicitly states that the "condition of server" (i.e., the ECU receiving the command) should be "ignition is on and system not be in an operational mode" to prevent dangerous actions while the vehicle is driving. An "operational mode" generally refers to the vehicle being in motion or ready to drive (e.g., gear set to 'D' or 'R').

In the vulnerable EV model, the ECU Reset service on the GCU was not disabled when the vehicle was in "drive mode." This allowed an attacker with physical access to the OBD-II port to send the 0x11 service message, even when the vehicle was moving at speed. The GCU, being a central point for inter-ECU communication, would then forward or process this critical command, leading to the immediate reset of essential vehicle systems. The speaker's test setup involved connecting a laptop to the vehicle's OBD-II port using a standard CAN interface and an OBD cable, configuring the CAN bus parameters to standard values (e.g., 500 kbps for high-speed CAN). This setup is readily available and commonly used by automotive researchers and technicians.

When the ECU Reset command was issued to the moving vehicle, it caused the engine (or in an EV, the powertrain management system) to stall, resulting in an abrupt stop. The video demonstration clearly showed the vehicle's sudden deceleration and subsequent rocking motion, indicative of a mechanical failure rather than a controlled braking maneuver. This suggests that crucial control systems, potentially including those managing motor power, transmission, or even steering and braking assistance, were momentarily or completely taken offline by the reset command.

For the "vehicle disabling" scenario, the continuous injection of ECU Reset messages created a persistent state of disruption. Each reset would temporarily incapacitate the ECU, and before it could fully recover and re-establish normal operation, another reset command would be received. This effectively trapped the vehicle in an endless loop of reboots, rendering it uncontrollable and unusable. This highlights the severe consequences of failing to implement proper state-based access control for safety-critical diagnostic functions.

The choice of the Gateway Control Unit as the target is significant. GCUs are designed to act as a firewall or router between different vehicle domains, often mediating communication between the powertrain CAN, body CAN, and infotainment CAN. If a GCU is vulnerable, it can serve as a single point of failure, allowing an attacker to impact multiple critical systems connected through it. The fact that a diagnostic command, intended for a controlled environment, could bypass safety checks at this central gateway underscores a fundamental design or validation oversight.

Demo / Proof of Concept

▶ Watch: Live demonstration of sudden vehicle stop attack (8:20)

The talk included compelling video demonstrations that served as robust proofs of concept for the identified vulnerabilities, clearly illustrating the real-world impact of the UDSonCAN attacks. The hardware setup for these demonstrations was straightforward, requiring only components readily available to automotive security researchers or even hobbyists.

The setup consisted of:

1. A laptop: Used to generate and send the malicious UDS messages.
2. An OBD cable: Connected to the vehicle's standard OBD-II port, which provides direct access to the vehicle's CAN bus.
3. A CAN interface: This device bridges the laptop's USB port to the vehicle's CAN bus, translating commands into CAN messages and vice versa.

The speaker confirmed that standard CAN bus parameters were used, implying no specialized or unusual configurations were required for the attack to succeed.

The demonstrations focused on two distinct attack scenarios:

Scenario 1: Sudden Stop

• Methodology: The vehicle was initially set to "drive" mode and was actively moving. The attacker then sent a single ECU Reset message (specifically, a hard reset command, 0x11 0x01) to the target Gateway Control Unit (GCU) via the OBD-II port.
• Demonstration: The video showed the vehicle, an EV SUV model, moving forward. Upon the injection of the ECU Reset command, the vehicle immediately came to an abrupt, uncontrolled stop. The speaker highlighted a critical detail: the car was observed moving "back and forth and back and forth," which indicated that the brake pedal was not pressed by the driver. This motion is characteristic of a vehicle losing power or control and then rocking slightly as it comes to a complete halt, rather than a controlled deceleration via the braking system.
• Implications: This demonstration vividly illustrated the extreme danger of this vulnerability. A sudden, unexpected stop, especially at high speeds on a public road, could lead to severe rear-end collisions, loss of control, and significant mechanical failure or damage to the vehicle and its occupants. The fact that the vehicle's primary safety systems (like controlled braking) did not override the reset command is particularly alarming.

Scenario 2: Vehicle Disabling

• Methodology: Similar to the first scenario, the attack involved sending ECU Reset messages to the vehicle. However, in this case, the messages were sent continuously to the target GCU. The demonstration implied this could be performed on a stopped vehicle or even a moving one, rendering it inoperable.
• Demonstration: The video showed the vehicle's systems being continuously disrupted by the stream of ECU Reset commands. The vehicle was unable to be controlled or driven. The speaker underscored the "scariest part" of this attack: the duration of the disabling effect is entirely dependent on the attacker. The vehicle remains incapacitated until the attacker chooses to stop sending the continuous reset messages.
• Implications: This attack effectively bricks the vehicle, making it unusable. This could lead to situations where occupants are stranded in unsafe locations, or the vehicle cannot be moved during an emergency. It represents a complete denial of service for the vehicle, highlighting a critical flaw in its operational resilience against malicious diagnostic commands.

Both demonstrations were concise but impactful, clearly validating the speaker's claims and emphasizing the severe safety and operational risks posed by the identified UDS vulnerability. The simplicity of the attack steps—connect, start engine, send message, observe—underscores the accessibility of this type of exploit given physical access to the OBD-II port.

Defensive Implications

▶ Watch: Live demonstration of continuous vehicle disabling attack (9:40)

The discovery of these safety-critical vulnerabilities, particularly the exploitability of the ECU Reset service in operational mode, carries profound defensive implications for vehicle manufacturers, suppliers, and the broader automotive cybersecurity community. Addressing these issues requires a multi-faceted approach, emphasizing adherence to standards, robust testing, and secure architectural design.

1. Strict Adherence to ISO 14229 and Related Standards:

The most immediate and critical defensive measure is to ensure strict compliance with ISO 14229-1 guidelines. Specifically, diagnostic services that have safety-critical implications, such as ECU Reset (Service ID 0x11) and Communication Control (Service ID 0x28, though not detailed in the talk, it was mentioned as a vulnerable service), must be disabled or severely restricted when the vehicle is in an "operational mode" (e.g., driving). The server (ECU) must validate the vehicle's state (e.g., speed, gear position, engine running status) before processing such commands. This involves implementing robust state-based access control logic within the ECUs themselves, especially in critical components like the Gateway Control Unit (GCU).

1. Enhanced ECU Firmware Validation and Secure Coding Practices:

Developers of ECU firmware must incorporate secure coding practices that prioritize safety and security. This includes:

• Input Validation: Thoroughly validating all incoming UDS messages, not just for protocol compliance but also for contextual relevance to the vehicle's current operational state.
• State Machine Management: Implementing robust state machines within ECUs that correctly track the vehicle's operational mode and apply appropriate restrictions to diagnostic services.
• Least Privilege: Ensuring that ECUs only grant access to services necessary for their current operational context.

1. Robust and Context-Aware Fuzzing and Penetration Testing:

While fuzzing was used to discover this vulnerability, it highlights the need for even more sophisticated and context-aware testing.

• Dynamic Fuzzing: Fuzzing should not only test for protocol malformations but also actively test services under various dynamic vehicle states (e.g., driving at different speeds, braking, parked, ignition off).
• Scenario-Based Testing: Incorporate specific attack scenarios (like the sudden stop and vehicle disabling) into routine penetration tests to validate the effectiveness of implemented controls.
• Hardware-in-the-Loop (HIL) Testing: Conduct extensive HIL testing that simulates real-world driving conditions while simultaneously injecting diagnostic commands to identify state-dependent vulnerabilities.

1. Secure Gateway Control Unit (GCU) Implementation:

The GCU, being a central point of communication, is a critical component for defense. It should act as an intelligent firewall, filtering and blocking dangerous diagnostic messages based on the vehicle's operational status.

• Intrusion Detection/Prevention (IDS/IPS) Capabilities: GCUs could incorporate logic to detect anomalous diagnostic command sequences or commands sent during inappropriate vehicle states and either block them or alert other systems.
• Message Filtering and Routing: Implement strict rules for which UDS messages can pass between different CAN segments and under what conditions.

1. Authentication and Authorization for Diagnostic Access:

While the talk did not detail specific UDS security measures, the broader industry trend is towards enhanced authentication and authorization for diagnostic access.

• Secure Diagnostics over IP (DoIP): For newer vehicles, moving from CAN-based diagnostics to Ethernet-based DoIP allows for stronger network security protocols (e.g., TLS) and more robust authentication mechanisms.
• Hardware Security Modules (HSMs): Utilize HSMs within ECUs to securely store cryptographic keys for authentication, ensuring that only authorized diagnostic tools or software updates can interact with critical ECUs.

1. Physical Security of the OBD-II Port:

Although the attacks demonstrated required physical access to the OBD-II port, this remains a significant attack vector.

• Physical Tamper Detection: Implement mechanisms to detect unauthorized access or tampering with the OBD-II port.
• Secure Gateways: Even with physical access, a securely implemented GCU and robust ECU firmware should prevent such exploits. The ultimate goal is to make physical access insufficient for critical safety compromises.

By implementing these defensive measures, the automotive industry can significantly mitigate the risks posed by UDSonCAN attacks and move closer to achieving the robust cybersecurity posture mandated by regulations like WP.29.

Key Takeaways

• UDS Fuzzing Reveals Critical Flaws: Even with increasing cybersecurity focus, UDS fuzzing remains an effective method for uncovering severe, safety-critical vulnerabilities in modern electric vehicles.
• Non-Compliance with Standards is Dangerous: The primary vulnerability stemmed from the ECU Reset service being active in drive mode, directly violating ISO 14229 guidelines, which mandates disabling such services when the vehicle is in an operational state.
• Immediate Safety Risks Demonstrated: Attacks can lead to highly dangerous scenarios, including sudden, uncontrolled vehicle stops and complete vehicle disabling, posing risks of accidents and stranding.
• Gateway Control Units are Critical Targets: The Gateway Control Unit (GCU) was identified as the vulnerable component, highlighting its crucial role in enforcing security policies and the severe consequences of its misconfiguration.
• Continuous Security Testing is Essential: The discovery during routine fuzzing tests underscores the need for ongoing, comprehensive, and context-aware security testing throughout the vehicle's development and lifecycle.
• Robust Implementation of Security by Design: Manufacturers must prioritize secure-by-design principles, ensuring strict adherence to automotive cybersecurity standards and implementing robust state-based access controls for diagnostic services in all ECUs.

About the Speaker(s)

Seunghee Han is a security researcher at Autocrypt, a mobility security company. She is credited as the first author of this research and presentation. The DEF CON 32 talk marked her first time speaking at the conference, an experience she described as both "nervous and so excited." Her work at Autocrypt focuses on vehicle security, where she is actively involved in conducting fuzzing tests for various OEMs (Original Equipment Manufacturers) and tier suppliers to help them achieve CSMS (Cyber Security Management System) certification in compliance with WP.29 automotive cybersecurity regulations. Her expertise lies in identifying weak points in vehicle systems, particularly through diagnostic protocol analysis and fuzzing techniques.