Connected Car Vulnerabilities Affect the CAN Standard
A vendor-neutral attack targets connected cars and abuses the network protocol that connects all in-vehicle equipment and systems and allows them to communicate. The standard for this network is called a Controller Area Network, or CAN.
Save to Folio
In many instances, researchers and engineers have found ways to hack into modern, internet-capable cars, as has been documented and reported several times. One famous example is the Chrysler Jeep hack that researchers Charlie Miller and Chris Valasek discovered. This hack and those that have come before it have mostly been reliant on specific vulnerabilities in specific makes and/or brands of cars. And once reported, these vulnerabilities were quickly resolved. But what should the security industry’s response be when a hack is found that is not only successful in being able to drastically affect the performance and function of the car, but is also stealthy and vendor neutral?
Enter the hack that does just that—one that has been discovered and proven to be effective by the collaborative research efforts of Politecnico di Milano, Linklayer Labs, and our Forward-looking Threat Research (FTR) team. It is currently indefensible by modern car security technology, and to completely resolve it would require broad, sweeping changes in standards and the ways in-vehicle networks and devices are made. Realistically, it would take an entire generation of vehicles for such a vulnerability to be resolved, not just a recall or an OTA (on-the-air) upgrade. We've anticipated initial questions you might have and provide answers below.
Another "car hacking" proof of concept? What's new about it?
What’s new is that it’s an attack that disables a device (e.g., airbag, parking sensors, active safety systems) connected to the car’s device network in a way that is invisible to state-of-the-art security mechanisms.
What is the main takeaway from this research?
Gaining access to someone else's vehicle has become a common situation, with many legitimate use cases. It is time that standardization bodies, decision makers, and car manufacturers take this change into account, and revise the design of the cyber-physical systems that govern future automobiles in order to secure them.
Is my car affected?
Likely, yes. Our attack is vendor neutral. However, specific vendors may take non-standard countermeasures to make the attack more difficult to carry out.
Wasn’t the “Jeep hack” the most advanced attack so far?
The "Jeep hack" was indeed very advanced and effective. However, currently available in-car cybersecurity technology (e.g., an aftermarket IDS/IPS) could detect such an attack because it requires frame-injection capability. In addition, car manufacturers could simply upgrade the software running on a car device to patch the vulnerabilities exploited by that attack.
How long will it take for the car manufacturers to solve this problem?
It's not the car manufacturers' fault, and it's not a problem introduced by them. The security issue that we leveraged in our research lies in the standard that specifies how the car device network (i.e., CAN) works. Car manufacturers can only mitigate the attack we demonstrated by adopting specific network countermeasures, but cannot eliminate it entirely. To eliminate the risk entirely, an updated CAN standard should be proposed, adopted, and implemented. This whole process would likely require another generation of vehicles. We elaborate on the research in this article, as well as in the video below, where our researcher Federico Maggi gives a full-length speech about the research (the same speech that he delivered at the DIMVA conference in Bonn, on July 6th).
https://youtu.be/oajtDFw_t3Q
Error in the System: The Design Vulnerability Within the CAN Standard
So how does this attack work? It abuses the network protocol that connects all in-vehicle equipment (e.g., parking sensors, airbag, active safety system) and systems (infotainment), and allows them to communicate. The standard for this network is called a Controller Area Network, or CAN.
After initial development by Bosch in 1983, the CAN protocol was officially released in 1986 and was first featured in production vehicles in 1989. In 1993, the International Organization for Standardization (ISO) accepted CAN as a standard and published ISO 11898 for road vehicles. Since then, CAN has been used as a standard for practically every light-duty vehicle currently in circulation today, and was being pushed to be the only acceptable one in the US federal courts.
Why would the various devices and systems in a car need to be connected to each other? The various in-vehicle subsystems should be able to function automatically, especially in times of emergency. For example, CAN enables your infotainment or safety system to receive messages from your car’s airbag system to know whether or not it needs to phone home in the event of an accident. It can also enhance your driving experience. For instance, your infotainment system can turn up the volume of the car’s audio once it reads the signal from your engine control system that you are currently stepping on the gas. That way, you can hear the audio over the engine’s increased volume.
Figure 1. A typical CAN network diagram (*1)
The CAN messages, including errors, are called “frames.” Our attack focuses on how CAN handles errors. Errors arise when a device reads values that do not correspond to the original expected value on a frame. When a device detects such an event, it writes an error message onto the CAN bus in order to “recall” the errant frame and notify the other devices to entirely ignore the recalled frame. This mishap is very common and is usually due to natural causes, a transient malfunction, or simply by too many systems and modules trying to send frames through the CAN at the same time.
If a device sends out too many errors, then—as CAN standards dictate—it goes into a so-called Bus Off state, where it is cut off from the CAN and prevented from reading and/or writing any data onto the CAN. This feature is helpful in isolating clearly malfunctioning devices and stops them from triggering the other modules/systems on the CAN.
This is the exact feature that our attack abuses. Our attack triggers this particular feature by inducing enough errors such that a targeted device or system on the CAN is made to go into the Bus Off state, and thus rendered inert/inoperable.This, in turn, can drastically affect the car’s performance to the point that it becomes dangerous and even fatal, especially when essential systems like the airbag system or the antilock braking system are deactivated. All it takes is a specially-crafted attack device, introduced to the car’s CAN through local access, and the reuse of frames already circulating in the CAN rather than injecting new ones (as previous attacks in this manner have done).
Figure 2. Attack device attack chain (*1)
Remote vs. Local Access Vulnerabilities in the Context of Modern Cars
Often, many car hacking proof-of-concepts and vulnerabilities are disregarded because they require having local access to the car. First, our attack can be enabled with any remotely exploitable vulnerability that allows the attacker to reprogram the firmware of an ECU (e.g., the infotainment system). Secondly, even local attacks should be taken seriously. Traditionally, the scenario in which an attacker could access a car that way is not only rare, but is also very risky to the attacker. This may have been true back then, but with current transportation trends such as ride-sharing, carpooling, and car renting, the scenario where many people can have local access to the same car is now more commonplace. As such, a paradigm shift in terms of vehicle cybersecurity must happen.
Mitigation
As we mentioned, mitigating this particular security issue will not be easy since the vulnerability itself lies in the design and cannot be immediately patched. Any worthy solution would require a drastic change in regulation and policy and would take an entire generation of vehicles to adopt. Going forward, some long-term solutions can help protect against such exploits:
- Network Segmentation or Topology Alteration: By altering the topology or segmenting a CAN in a vehicle, targeted error-flooding can be stopped from affecting a specific system.
- Regulated OBD-II Diagnostic Port Access: The creation of a special hardware key or password in order to open the case where the port is physically located may protect against illegal and unauthorized devices being introduced to the CAN. The implementation of a software-level authentication in order to allow traffic from and to the port can be considered as well. This would require a change in the regulations.
- Encryption: Encrypting CAN frame ID fields can prevent attackers from identifying CAN frames to target, and thus resulting in a noisier and much more detectable attack pattern.
We have already disclosed our findings to the US/ICS-CERT and an alert has been issued. For more information about this particular hack and the research efforts going into it, you may peruse our latest technical brief, titled “A Vulnerability in Modern Automotive Standards and How We Exploited It.” In it, we dissect our findings regarding this particular vulnerability down to the nitty-gritty. We also go into detail about the mechanics of our attack and expound on our recommendations in mitigating this vulnerability. *1: A Stealth, Selective, Link-layer Denial-of-Service Attack Against Automotive Networks, Andrea Palanca (Politecnico di Milano (Italy)); Eric Evenchick (Linklayer Labs); Federico Maggi (FTR, Trend Micro, Inc.); Stefano Zanero (Politecnico di Milano (Italy))