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

[CVE-2020-15779] Path Traversal in Socket.io-file NPM module

Title: Path Traversal in Socket.io-file NPM module
Date: 18/05/2020
CVE-ID: 2020-15779
Advisory: https://www.npmjs.com/advisories/1519
Author: Thomas Sermpinis
Versions: <= 2.0.31
Package URL: https://www.npmjs.com/package/socket.io-file
Tested on: node v10.19.0, Socket.io-file v2.0.31, socket.io v2.3.0
Proof of Concept: https://www.exploit-db.com/exploits/48713

During one of my penetration tests for a local military equipment supplier, I faced a web application running on an embedded device that used web sockets in order to initiate the connection between the server and the client. There are several different technologies that can be used in the back-end system in order to make use of web sockets, but the client made use of Socket.io.

The web application was relatively small, with only a few entry points that did not seem to be vulnerable. All the modules were up to date and my enumeration started to go into a dead end. As there were more days for my pentest, I decided to dig deeper and I started analyzing more the request and researching about the npm modules that were included and were in use in the web application.

One of the functionalities was a configuration file upload, that was stored in a folder in the filesystem, by using the Socket.io-file npm module. Socket.io-file (2.0.31) is a node module for uploading files via the Socket.io module. Playing around with the requests I managed to bypass the restrictions and upload a file in a different folder from the expected one (I knew that as I had access to the backend of the system).

Client and project aside, the upload functionality of socket.io-file is vulnerable to improper input validation, allowing attackers to bypass upload directory restrictions and it allows them to upload files to paths of their choice in the underlying system.

Description of the Vulnerability

The default configuration of Socket.io-file comes with an upload functionality handled by websockets. When a user tries to upload a file with the web application, the following client side request is created in order for the file to be created:

Figure 1: Normal websocket request for file upload with Socket.io-file

42["socket.io-file::createFile",{"id":"u_0","name":"testfile.mp3","size":1,"chunkSize":10240,"sent":0,"data":{}}]

In order for this file to be created to the underlying system, the code from index.js of Socket.io-file is executed and the following part of the code, manages to merge the file path (supplied by the socket.io-file configuration) with the file name that was supplied by the user:

if(typeof options.uploadDir === 'string') {uploadDir = path.join(options.uploadDir, filename);}

As an example, if the user uploads a file with the name “testfile.mp3” and the server is configured to to store files in the “/home/Documents/socket-app/data” path the resulting path that Socket.io-file will create the file, will be “/home/Documents/socket-app/data/testfile.mp3”.

Because the aforementioned code makes no check on the file name, the upload request can be intercepted and the file name altered in a way that will move in certain paths of the system. The following example exploits this issue:

42["socket.io-file::createFile",{"id":"u_0","name":"../testfile.mp3","size":1,"chunkSize":10240,"sent":0,"data":{}}]

This request will generate the following path for the file to be stored “/home/Documents/socket-app/data/../testfile.mp3”, which means that the file will actually be created in “/home/Documents/socket-app/testfile.mp3” as the ../ characters will move the path one level lower in the filesystem.

Figure 2: File created in the node_modules directory of the filesystem, outside the intended directory.

From this example we can understand that we can write in several sensitive directories like the ~/ home directory (which includes the .ssh folder which allows us to rewrite the ssh configuration), in the root webserver directory (which can help us get a reverse shell under the right circumstances) and the cron directory (where we can inject cron jobs for code execution). Additionally, if the back-end system runs with superuser privileges (which is not so uncommon), the attacker can use this vulnerability to create files in even more sensitive paths (e.g. /root and /etc). As an example, we can write the /etc/passd file of our implementation like the following:

42["socket.io-file::createFile",{"id":"u_0","name":"../../../etc/passd","size":1,"chunkSize":10240,"sent":0,"data":{}}]

Issue Replication

In order to replicate the issue, the following steps have to be executed:

  • Setup a proxy to intercept HTTP and WebSocket requests (e.g. Burp Suite or OWASP Zap)
  • Upload a file using the Socket.io-file web application and intercept the websocket request
  • Change the “name” parameter by adding ../ and specifying the needed path:
    • 42[“socket.io-file::createFile”,{“id”:”u_0″,”name”:”../../../Downloads/testfile.mp3″,”size”:1,”chunkSize”:10240,”sent”:0,”data”:{}}]
    • This example will create the testfile.mp3 file in the Downloads directory of the current user (our test server stores files in “/home/ubuntutest/Documents/socket-app/data”)

Remediation

No fix is currently available. Consider using an alternative package until a fix is made available.

Vulnerability Disclosure Timeline

Following the npm guidelines for vulnerability disclosure (“If maintainers are unresponsive after 45 days, npm Security makes the advisory public”), we responsibly disclosed this vulnerability on 18th of May 2020.

  • Initial Disclosure: 18th May 2020
  • Security Team Validation: 18th May 2020
  • Advisory Release: 7th July 2020
  • CVE-ID Assignment: 15th July 2020
  • PoC Release at exploit-db.com: 27th July 2020