Summary
This post covers four common automotive attack techniques: CAN bus injection, UDS security access bypass, keyfob replay, and FOTA spoofing. It describes how each maps to the vulnerability classes that AppSec researchers already know. Synack Red Team researcher Manh Nguyen Dinh breaks down the vehicle attack surface, draws the parallels to traditional web security, and explains what it takes to pivot into automotive security research.
The “Aha” Moment: From Application Pentest to Automotive Hacking
A year ago, I was a standard AppSec guy, comfortably assessing APIs and hunting for web and mobile vulnerabilities. My world was defined by HTTP requests and JSON responses. Then, I took part in automotive security.
At that time, the field felt like a dark, walled garden. There were no standard roadmaps, no abundant StackOverflow threads, no prompt AI, and very few mentors to point the way. It was a high-risk pivot into a narrow, gatekept niche. But I was driven by a visceral realization: in this world, a “successful exploit” doesn’t just mean a leaked database, it means a two-ton machine behaving like a possessed entity.
I still remember the first time I sent a crafted CAN message via my laptop to an OBD-II port and watched the high-beam headlights flicker on command. It was a simple replay attack, something we’d consider “Security 101” in the cyber world. But seeing physical hardware react to my bits? That’s when I realized: automotive security is the ultimate frontline of cyber warfare.
So, What Is Automotive Cyber Security?
To the uninitiated, it sounds like protecting a machine that happens to have wheels. But it’s much more than that. At its core, it is the practice of protecting communication protocols, electronic control units (ECUs), and software for a vehicle.
While it follows the classic CIA Triad, there is a fourth, overarching dimension that redefines everything: Safety. In the automotive world, cybersecurity and functional safety are two sides of the same coin. If a server goes down, a business loses money. If a car network is breached, people will lose their lives. The stakes are radically different:
- Confidentiality: Protecting the driver’s real-time location, voice recordings, and sensitive PII.
- Integrity: This is the bridge to Safety. Can an attacker inject a message into the CAN bus to tell the car it’s at 0 mph when it’s actually at 60? If you lose integrity, you lose control.
- Availability: Imagine “automotive ransomware” bricking an entire fleet during rush hour or disabling a critical steering assist function when it’s needed most.
- Safety (The Ultimate Goal): Unlike traditional IT, the “Impact” column in our risk assessment isn’t measured in dollars, it’s measured in ASIL (Automotive Safety Integrity Level). We are fighting to ensure that a cyber-attack doesn’t translate into a physical collision.
In this world, we aren’t just protecting data; we are protecting human lives.
The Vehicle Attack Surface: More Interfaces, More Problems
To a security researcher, a modern vehicle is an layered architecture. You have high-level, internet-connected systems (Infotainment) running alongside low-level, legacy networks (CAN bus) that were never designed for security.
Understanding the attack surface is about identifying the entry points and, more importantly, how to pivot between them.
External Interface
These are the doors into the system. In my experience, developers often prioritize connectivity over isolation:
- Wireless: Keyfobs (RF/LF), Wi-Fi, Bluetooth, and Cellular (4G/5G), RF, UWB, NFC, GNSS, V2X. The Telematics Control Unit (TCU) is particularly interesting because it bridges the cellular network directly to the vehicle’s internal buses.
- Physical: The OBD-II port remains the most direct access point for local testing. However, we are seeing more vulnerabilities in USB media interfaces and EV Charging (V2G) protocols, where the vehicle handshakes with external infrastructure.
In-Vehicle Networks (The Pivot)
Getting into the Infotainment is only half the battle. The real work happens when you try to affect the vehicle’s behavior:
- Protocol: CAN, LIN, FlexRay, and increasing Ethernet. Of these, CAN is the most widespread and also the most interesting from a security standpoint
- The Gateway: This is the critical junction. It acts as a firewall between the “clean” powertrain network and the “dirty” connectivity network. Finding a logic gap or a memory corruption bug in the Gateway is usually the goal for a full-chain exploit.
Common Automotive Security Vulnerabilities
When you peel back the layers of vehicle proprietary systems, you’ll start to see ghosts of AppSec’s past. Most “Automotive” vulnerabilities are just classic flaws rebranded for a different architecture. The attack surface here is vast—from physical interfaces to RF signals to cloud-connected update pipelines—and the vulnerability classes are nearly endless. But most of them share one thing in common: they’re classic flaws, just rebranded for a different architecture.
For the sake of this post, I’m not going to try to map every corner of that surface. Instead, here are four of the most approachable examples — the ones that best illustrate how familiar concepts translate into real-world automotive impact:
| Automotive Vulnerability | Traditional AppSec Equivalent | The Impact in a Car |
| Keyfob Replay Attack | Session/Token Replay | Capturing a Rolling Code (Token) over the air and replaying it to unlock the doors or start the engine. |
| UDS Security Access Bypass | Using weak Seed/Key logic to gain “Root” access to an ECU. | |
| CAN Bus Injections | IDOR / Command Injection | Sending an unauthenticated frame to a specific ArbID to trigger a physical action. |
| FOTA Spoofing | Man-in-the-Middle (MitM) | Intercepting an over-the-air update to inject malicious firmware. |
1. The Keyfob: Sniffing “Cookies” in the Air
The keyfob is essentially a physical session token. Many vehicles still use rolling code schemes that can be defeated by signal jamming and capturing (the classic “RollJam” attack).
To a researcher, this is just a session replay attack. If the system doesn’t properly invalidate a captured code or lacks a secure “timestamp” mechanism, an attacker can “sniff” the token from the air and use it later to gain full access to the vehicle. It’s a reminder that even without a physical connection, the vehicle is constantly broadcasting its vulnerabilities.
2. UDS Security Access Bypass
UDS Service 0x27 (Security Access) functions as the primary authentication gate for sensitive operations like memory writing or firmware flashing. It relies on a Seed-Key exchange: as illustrated above, the UDS Server (i.e., the ECU) generates a random Seed and sends it to the tester, who must then return a valid Key calculated via a proprietary algorithm. Only if the Key matches do the server grant access.
An attacker’s goal is simple: produce a valid Key without knowing the intended algorithm. The most common paths to get there: Seeds with insufficient entropy that are predictable or repeat across sessions; derivation logic so weak (think single-byte XOR or hardcoded lookup tables) that it can be reverse-engineered from the firmware in minutes; Keys short enough to brute-force within the ECU’s lockout window; or static Keys shared fleet-wide, meaning a single firmware dump compromises every vehicle of that model.
Bypassing this service grants root privileges over the ECU, enabling an attacker to bypass safety restrictions or inject persistent malicious code.
3. CAN Bus Injection: Physical Command Injection
The CAN bus is inherently trust-based, lacking source authentication or encryption. This allows for a vulnerability similar to IDOR or command injection. By crafting an unauthenticated frame with a specific ArbID (Arbitration ID), an attacker can trick an ECU into executing a physical action. Injecting a high-priority “Engine Kill” or “Door Unlock” command into the stream is essentially a direct request to the hardware that the system cannot verify or reject.
What makes this particularly dangerous is the blast radius. Unlike a web app where a command injection affects a single session, a CAN injection targets a shared broadcast bus so that every node hears every frame. There are no ACLs, no firewalls, no rollback. The command executes, and the car responds.
4. FOTA Spoofing: The Gateway MitM
Firmware Over-The-Air (FOTA) updates are the primary way OEMs patch vehicles, but they are also a massive Man-in-the-Middle (MitM) target. If the update process lacks robust code signing or secure transport (like TLS with certificate pinning), an attacker can intercept the package. Spoofing the update server allows for the injection of malicious firmware directly into the car’s safety-critical ECUs, turning a legitimate maintenance feature into a persistent backdoor.
That’s the real threat model here: FOTA spoofing isn’t a per-vehicle attack. It’s a fleet-level one. A single compromised update server becomes a silent, persistent backdoor pushed to thousands of vehicles simultaneously – turning a legitimate maintenance feature into the most scalable exploit in automotive security.
Some Advice: How to Build Skills for Automotive Security Research
Securing an automotive system requires a hybrid mindset. You need the grit of a security engineer and the domain-specific knowledge of a vehicle technician. For someone pivoting from a traditional IT background like me, the learning curve felt steep. It’s a narrow field where documentation is a luxury. However, with a solid foundation in security concepts, the transition is far from impossible; it’s a matter of learning while doing.
The key is to deconstruct the target. You must dive deep into how each component operates and, more importantly, how they communicate. This is the only way to map the full picture: identifying the assets, tracing the attack surfaces, and following the attack paths.
Only when you truly understand the system can you start asking the right red team questions:
- Can GPS location data be exfiltrated?
- Can the steering be manipulated remotely?
- Can this Firmware Over-The-Air (FOTA) update be spoofed?
Each of these questions serves as the starting point for a Threat Analysis and Risk Assessment (TARA). This model is what dictates the defense strategy, whether it’s ECU authentication, CAN bus message encryption, or implementing a robust Secure Boot to ensure software integrity.
In my journey, learning by trial was essential. Using tools like UDSim, CANoe, or simply getting my hands dirty with an OBD-II adapter helped bridge my traditional InfoSec knowledge with this complex mechatronic world. There’s a unique thrill in this field: the moment you see a physical component, like a headlight, flicker because you sent a single frame to the right address, you’ll know you’ve officially opened the door to automotive cybersecurity.
In the near future, I will be sharing more detailed write-ups of the vulnerabilities I’ve discovered in automotive systems, including cases that have been assigned CVEs. These analyses will be published on my blog, where I’ll dive deeper into the technical details, exploitation approaches, and corresponding mitigations.
Thanks for reading. Be sure to follow Synack and the Synack Red Team on LinkedIn for upcoming Exploits Explained posts in this series.
Frequently Asked Questions
What makes automotive cybersecurity different from traditional application security?
The stakes. In web or mobile security, a successful exploit might expose data or disrupt a service. In automotive security, it can directly affect physical safety. The CIA Triad still applies, but it exists under a fourth dimension: Safety. Risk isn’t just measured in dollars, it’s measured in ASIL (Automotive Safety Integrity Level), which quantifies how likely an attack is to cause injury or loss of life. That changes everything about how you approach threat modeling, prioritization, and defense.
Can an attacker actually control a vehicle’s physical functions remotely?
Yes, under the right conditions. The attack chain typically starts at an external entry point (Bluetooth, cellular, or the OBD-II port) and pivots inward through in-vehicle networks like the CAN bus. Because CAN was designed for reliability rather than security, it has no native source authentication. An attacker who gains access can inject crafted frames that trigger physical actions: door unlocks, steering inputs, or engine interference. This isn’t theoretical. Researchers have demonstrated these capabilities on production vehicles.
Why are CAN bus vulnerabilities so difficult to patch?
Because CAN was never designed with security in mind. It’s a decades-old broadcast protocol built for reliability in closed, trusted environments. Modern vehicles layer connectivity (Wi-Fi, 4G/5G, Bluetooth) on top of that legacy architecture without always isolating it properly. Patching often means updating dozens of ECUs with interdependencies across the vehicle’s network. Even with FOTA capability, the update mechanism itself can become an attack vector if not properly secured with code signing and certificate validation.
How do automotive security researchers test vehicles without damaging them?
The same way any penetration tester works: with scope, controlled environments, and a systematic approach. Tools like UDSim and CANoe simulate vehicle network behavior in a lab without requiring a live vehicle. Physical testing typically starts at the OBD-II port, working up through the network layers before any live testing on a full vehicle. The goal is to understand how each component communicates before attempting to manipulate it. This is the same methodology that applies in web or application security, just with different protocols and hardware.
About the Author
