Tag: CAN

Categories
CAN Injection

CAN Injection Attacks: A New Form of Vehicle Theft

The automotive cybersecurity field experienced a noteworthy development in 2023 when an automotive cybersecurity researcher reported that his Toyota RAV4 was hijacked and stolen using a novel theft technique known as CAN injection.

The tweets by the security researcher the day his RAV4 was stolen

It was an innovative, yet simple technique that showcased the adaptability of attackers against modernized defenses against automotive threats. All that was necessary for the thief to do was find a spot inside the body of the car he could reach into and place there a special device capable of delivering CAN messages to unlock the car and start it up. OEMs are now prompted, once again, to respond and innovate to this novel, yet simple, technique.

In this article, we will delve into the specifics of the incident further, examining its implications and responses to combat this new technique.

However, to fully grasp the incident, it is essential to understand briefly what CAN is and how it operates.

What is CAN?

The CAN protocol functions as a sort of internal neural network, facilitating the transmission of messages to other Electric Control Units (ECUs) in a standardized and reliable manner. Compared to other protocols, CAN excels in its efficiency and resilience. For this reason, CAN stands out as the central medium for intra-vehicular communications among technologically advanced vehicles. Despite originating in the mid-1980s and entering into automotive in the early 1990s, CAN has proven itself still by its widespread adoption and continued use up to this day.

Not only is CAN fast and reliable, but messages are standardized for compatibility across wide ranges of ECUs and devices. This standardization also substantially reduces the amount of wiring to install as communications between ECUs do not have to be one-to-one between every ECU inside the vehicle. Instead, ECUs can be clustered into smaller groups, forming internal networks that optimize communications and increase safety.

Additionally, the decentralized nature of the CAN bus makes this protocol very reliable. It allows every device on the line to send and receive messages even if one ECU goes down. CAN also protects message integrity and correctness by such mechanisms as CRC checks and ACK signaling.

However, a weakness of CAN is that the protocol does not include native protections against message injection. It is up to the OEM to develop and implement methods to detect fraudulent messages and secure standard communications. As the CAN broadcasts communications to all ECUs on the same line, other connected devices can accept the spoofed messages without authentication. It was this inherent weakness that was taken advantage of and caused the theft of the RAV4.

Decoding the CAN Injection Incident: How Manipulated Messages Led to Car Theft

For some time now, automobile theft developed into a cat-and-mouse game in which thieves creatively invent new methods to attack and steal vehicles while manufacturers respond with solutions to combat them. Advanced vehicle technology served to advance the struggle as we see today.

Thieves introduced techniques such as keyless entry, relay attacks, signal jamming and intercepting, OBD (On-Board Diagnostics) port hacking, and key cloning. In response, manufacturers developed robust defenses. Rolling codes, motion sensors, and improved encryption of unlock codes were invented to protect against keyless and relay attacks. Immobilizers were invented to ensure the vehicle could not start without the correct key fob. Improved device software and Intrusion Detection Systems improved communications security. Smartphone applications now have features that improve security. Finally, VSOCs (Vehicle Security Operations Centers) are increasingly deployed to detect fraudulent CAN messages, remote attacks, and any other potential threats to vehicles and fleets.

Despite these protections, who would have thought that an exposed CAN bus would have been the cause of the next trophy hack?

Concerning the theft of the RAV4 mentioned at the beginning it was precisely that. A headlight ECU that could be reached by simply pulling out the bumper was the entry point to get in the vehicle and start it. From that ECU, the attacker injected messages to open the doors and start the engine. The entire key-unlock and start mechanism was, in effect, bypassed.

In general, if the purpose of stealing a vehicle is to sell it, then the methods the thief will use will be both the easiest and the cleanest. A car that is easy to steal with minimal damage caused will have more value than a car broken into but with damage caused during the process.

The internal structure of the CAN network and the physical wiring inside presented itself as a good opportunity to steal the RAV4 relatively cleanly using the new CAN injection technique. All that was necessary was a little manipulation of the bumper to find a place to inject CAN packets.

As explained earlier, ECUs can be clustered into separate networks. In the case of the RAV4, the ECU controlling the headlights shared the same bus line as the ECU controlling the doors and the smart key. This line was connected to a gateway ECU that could transfer messages to ECUs on other lines. Such ECUs included the one controlling the engine. This diagram can be seen in the image below.

Schemata of the RAV4 CAN bus

While the car is not turned on it maintains a low-energy state and awaits a message, typically an unlock request, to prompt the car to wake up. For instance, when a signal is sent from the key fob to unlock the doors, the transmitted signal initiates an ECU to send messages on the CAN bus to unlock the doors and perform other tasks to prepare the car once the driver enters.

What CAN injection does is upset the communications between the vehicle components by sending fraudulent messages on the bus that mimic real ones. If these fake messages are not caught, then the injection is successful. The thief can now send a “door unlock” message as if from the smart key ECU and the ECU controlling the doors blindly accepts it.

The strategy for attack becomes simple:

  1. Pull out the bumper enough to expose the headlight ECU.
  2. Attach a device to it.
  3. Send messages imitating a “car unlock” sequence from the smart key ECU as if a real request was transmitted from it.
  4. The ECU controlling the doors receive the message. The key is validated and the doors unlock.
  5. A message indicating that the key was validated arrives at the gateway ECU and gets transferred to the ECU controlling the engine immobilizer.
  6. The immobilizer is disabled and the car can start.
  7. Open the door and drive away.
The message injection tool disguised as a JBL mini speaker. Photo by Ken Tindell

All the equipment that the thief needed was a tool to pull out the front bumper and a CAN injection tool masquerading as a tiny JBL wireless Bluetooth speaker. The tool was built to send and receive messages, featuring an additional circuit programmed to block other ECUs on the line from sending messages. The additional circuit was essential to:

  • Block other ECUs from transmitting data
  • Suppress any warnings sent on the bus
  • Prevent the spoofed messages from clashing with real messages from the smart key ECU and their resulting errors

The circuit operates through a mechanism known as a dominant override. It maintains the bus in a recessive state by sending bits of value 1 fast enough so that no other ECUs can send messages. Generally, if an ECU wants to begin packet transmission, it will send the dominant bit. However, this injector tool suppresses any sent dominant bit so fast that it does not appear to any potential receiver. The injector sends the recessive bits too quickly for the other ECUs to transmit. Therefore, only recessive 1’s appear. The only exception occurs when the injector tool transmits. This was the final defense the thief had to get past.

Preventing CAN-injection Attacks

To safeguard against the threat posed by CAN-injection attacks, OEMS must enact countermeasures to improve security and further sustain it in response to subsequent attacks.

The first recommendation is to conceal all ECUs deep enough inside the interior. This way, attackers cannot reach them unless they expend considerable effort, most likely resulting in a stolen car with diminished value once stolen.  

Another effective defense against such attacks is to employ a mechanism that encrypts messages and requires ECUs to authenticate before sending. SecOC (Security On-board Communication) is an excellent mechanism that implements both. SecOC uses cryptographic techniques such as digital signatures and message authentication codes (MACs) to verify the origin and integrity of messages exchanged between ECUs. The challenge-response mechanism involved in authentication also provides effective protections against replay attacks.

The final piece of advice is for OEMs to submit their vehicles to routine automotive penetration tests performed by experts with up-to-date knowledge in automotive cybersecurity. Regular penetration tests ensure the vehicle’s security posture remains resilient against emerging attack vectors, such as CAN injection, and allow for timely updates and enhancements to counter potential new vulnerabilities.

Categories
Security Research

CANdy – an automated CAN bus message mapping framework

Check out CANdy demo

When I was offered to write a bachelor thesis on the topic of CAN bus message mapping, I had no idea how crucial and fascinating such an area actually is and I would like to share with you what I learned and created during the past six months.

First thing first, what exactly is that CAN bus we are talking about? CAN stands for Controller Area Network, a communication protocol usually used in real-time systems to enable data exchange between each controller and electrical devices (engine sensors, brake systems, air conditioning, etc.). We can find it in many industrial domains but most importantly – transportation. CAN bus is a communication backbone of your vehicle’s internal systems and its importance has risen since every new car model is equipped with more electrical controllers and sensors than the previous one. For instance, CAN provides an efficient and cheap way to send data from engine sensors to the automobile dashboard to show you information about the car’s speed or RPM. However, the protocol only tells how each unit should talk to the other, but does not specify the “language” they ought to use. In other words, there are no general rules imposed on the data payload format. What is more, only car manufacturers are in charge of creating the definitions, which are not publicly available. As a result, we cannot simply connect to the bus and send messages or understand what exactly happens in the car. Such a state provides a certain level of security, that can prevent others from modifying the car internals or injecting malicious messages to its CAN network unless they are given some message definitions. This principle is also known as a “security by obscurity” and is generally considered as an insufficient method for securing any system or application.

Therefore, things can go wrong really easily. Lack of encryption or authentication allows us to forge any message we want and send it to the bus. Let’s say we have the format of the message carrying data from a proximity sensor and the car model uses a really advanced driving assistant, which can automatically detect if you are getting too close behind another car and slow down the car to avoid a possible crash. Now, what could happen when made up data were sent to the bus? With the right data, the driving assistant might slow down the car even if there is no vehicle around and vice-versa. In addition, CAN protocol is susceptible to DoS attacks as there is no mechanism preventing an attacker from flooding the bus with messages. As a result, blocking the whole bus can inflict major damage to the car and put the passengers in danger. Scenarios like these illustrate how easily we can affect the behavior of the car only with access to the CAN bus and why is car security more important than ever. Moreover, the next question is how do we obtain the message definitions for a specific car model.

Finally, this is where message mapping plays a key role. Luckily for us, raw CAN messages are not as random as they appear and we can find some certain patterns and characteristics to help us decode them. The process of assigning an unknown CAN message to a specific function or meaning is what we call message mapping. A few academic researchers have proposed solutions to either classify the messages or detect signals and their parameters, which do not fully recognize what exactly the message represents. Unfortunately, there is no universal method yet to map messages only with a message log from the bus and some level of interaction with the car is still required. Finding a message related to opening the door can be divided into three steps:

  1. Find out which messages are sent to the bus when you physically open the door. 
  2. If there is more than one, look at the payload and discover how does it change when you close or open the door. 
  3. Try to describe every possible state or value that is sent in the message.

It does not sound like big of a deal, right? Sadly, the task is a little bit more complicated than that. First of all, accessing the CAN bus itself could be a quite challenging task, because not all cars have their bus exposed to the OBD-II port. For instance, Volkswagen has its CAN bus hidden behind a gateway, therefore another channel needs to be found instead of a direct connection via OBD-II. In that case, you will have to take a more creative approach, which will require taking your car apart a little bit. Some modern cars may even offer ways to gain remote access, but that is way harder to accomplish still. Secondly, there are hundreds of messages sent to the bus every second and without any dedicated software, it would be impossible for us to navigate through all of that. Finally, this is where our tool comes in handy! CANdy can assort and filter out messages and provide useful information for mapping. It also gives you a better idea of what is going on the bus with its plotting modules and a decoder. What is more, you can write your own modules using its API to add some custom functionality. To better illustrate how CANdy works we would rather show you an example of mapping the gas pedal message using our tool.

This is how traffic on the CAN bus in Toyota Auris 2016 looks like in a span of 0.01 second.
One of our modules helped us detect message ID – 0x2c1, which appears when the gas pedal is pressed. We can get rid of all the noise with a message filter and get cleaner data for our analysis.  
The improved output suggests that some bytes of the payload may carry some useful information. Naturally, the most obvious way to examine such data is making a time series graph. And we have a module for it too.

This plot only shows the first and the seventh byte in the payload. But it is sufficient to recognize the data in the first byte as an indicator whether the pedal is pressed or not, while the seventh byte seems to tell us how much. In order to confirm or dispute our theory, one may look up an official definition for the gas pedal message on the internet or compare your results with someone else. One definition we found on the internet for Toyota Corolla 2017, a very similar model to Auris, describes the message like so:

It is not necessary to dive into details about the format, so we will interpret it for you. The message ID for the gas pedal is 705, which is 2c1 in hexadecimal. Then, there are two signals, which are technically just some values placed in the specified position of the payload. Also, the CAN message data field has a fixed length of 64 bits using zero-based indexing. In this case, it means that the fourth bit in the message indicates the gas pedal is released and the last byte of the payload is used for pressure on the pedal (offset 55 bits, length 8 bits). As we can see, our first guess about the indicator was most probably correct. The latter may be still applicable, because we do not have completely matching CAN definitions, but we cannot be sure either. Another way to test this theory is to try to press the pedal and see which bytes are changing accordingly. Such a task could be carried out with another module we wrote for rendering a real-time plot for a particular message and its bytes.

Ultimately, there are a lot of other units to map with their messages like windows, turn signals, etc. And there is nothing stopping you from trying to hack your car’s CAN bus the same way as we did. CANdy is published as an open-source tool for everyone to try out and for the next step, we would like to gather and publish a crowdsourced database of various CAN definitions. Thus, you are more than welcomed to take a look at CANdy, test it out, and share your results with us. For more information, please check out the paper with technical details and resources. Also, the repository with the tool is available at this link.