How to secure heavy-duty vehicles. SAE J1939 cybersecurity is challenging, but not impossible.
Securing heavy-duty vehicle CAN bus networks is challenging, but not impossible. Arilou Automotive Cybersecurity CTO, Gil Litichever, and VP Product and Marketing, Gilad Bandel, explain.
In this article, Gil Litichever and Gilad Bandel take a look at SAE J1939 cybersecurity, reviewing the protocol and its related networks. They draw from their experience gained during the development and implementation of Arilou’s Sentinel-TRK solution, which provides intrusion detection, and optional prevention, for trucks and other heavy-duty vehicles.
They highlight specific features and vulnerabilities of the J1939 and offer advice and practical guidelines for protecting heavy-duty vehicles.
While some experience of automotive networking and the J1939 protocol is helpful, for those without it, we will point to support material, where we can, to help bring you up to speed.
JUMP TO A SECTION:
- Vehicle Configuration
- Aftermarket Fleet Management Equipment Installation
- Specific Embedded Software Issues
Why does SAE J1939 cybersecurity need a different approach?
At some point, you have probably had one of those terrible suits that are too loose in one place and breathtakingly tight in another. And just as we could all benefit from a dress suit that is tailor-made to our exact size, so too can a customized cybersecurity solution benefit in-vehicle networks.
Customization is necessary in an environment in which a baggy fit (or high network overhead in this case) might mean the need for millions of dollars in additional hardware costs over the lifetime of a full vehicle production cycle.
Not all networks and protocols are created equal. Accordingly, we must tailor cybersecurity protection to specific network characteristics. Threat models, anticipated attack vectors, these must be measured, chalked, and cut to fit. The SAE J1939 CAN bus protocol –designed specifically for heavy-duty vehicles– is no different.
Understanding the Layers
You can divide the field into five layers:
- Individual ECU (Electronic Control Unit)
- IVN (In-Vehicle Network)
- EE (Electrical and Electronic) architecture
- Connected vehicle
- Connected fleet
In this article, we are looking mainly at the IVN layer. This layer will be addressed in upcoming standards SAE J1939-91A (in-vehicle network security) and J1939-91B (telematics interfaces, e.g. secure bidirectional OTA (over-the-air) updates, ExVe (extended vehicle), and ITS (intelligent transportation systems) among others).
The main reason for this approach is that we see this layer as the most vulnerable with the highest risks and lowest inherited protection. Other layers are not specific to J1939 (such as ECU hardware and embedded software securing). Higher layers (such as connected vehicle and connected fleet) are more generic and share a commonality with passenger vehicle cybersecurity.
This article derives from our field experience and understanding of SAE J1939 cybersecurity. It reflects our expert professional view of the subject, rather than just being an explanation of the standards. The conclusions and proposed courses of action you will find later in this article are not academic, but realistic examples that you can use as guidelines for implementation.
Who are the threat actors targeting heavy-duty vehicles?
Know your enemy. When you consider which threat actors are motivated to attack heavy-duty vehicles, it’s important to look beyond normal civilian considerations. Heavy-duty vehicles often form part of critical economic and social infrastructure, including heavy industry, agriculture, emergency, and military services.
The three main categories you should look at when considering potential attackers are:
- Criminals, looking for ransom or wishing to inflict physical damage. They may want to harm the reputation of your business or use your connected devices as a vector to hack government infrastructure or private individuals. They could be doing this to find ways to manipulate them for immediate financial benefit, but also consider industrial espionage.
- Terrorists, nation-states, anarchists, activists or any group/individual with a political or ideological background. Their primary target is to cause as much damage as possible.
- The owner/end-user might attempt to hack the vehicle themselves. They might do this to make use of clone ECU replacements, chip tuning, and/or similar actions. Not often considered, you should keep this in mind as ultimately it can harm your bottom line if you’re a fleet owner. This is especially true now when the automotive industry is looking to leverage in-vehicle data and IVI ecosystems as new revenue streams.
How do attack surfaces and threat models for SAE J1939 cybersecurity differ to regular CAN?
We will not look at individual ECUs as they can be considered just another hardware/software embedded device. While no doubt there are specific vulnerabilities and exposures in some devices, here we are focusing exclusively on scenarios using the J1939 protocol.
Attack Surfaces and Threat Models
The preferred attack method would be remote. This type of attack can be achieved from anywhere and leaves very few traces –if any.
Attaching a physical device is an option that provides full access to the bus, but this has the risk of being detected. Injecting malware into an ECU is a more viable option. An attacker who can gain physical access to a vehicle has more effective and efficient methods at their disposal, but still, the cyber-attack has many virtues.
In contrast to passenger vehicles, which use regular CAN bus (with flavours per individual make and model due to proprietary implementations by OEMs), J1939 is well standardized (in production terms). SAE J1939 architectures share a pool of modular components, with little variation of integration between vehicles.
In many cases, ECUs are interchangeable between vehicles manufactured by different OEMs. This similarity optimizes development costs and re-use factors. It also means that once hackers identify a kill chain, they can leverage it to attack many vehicles from multiple OEMs. This characteristic offers clear financial benefits to manufacturers but is an obvious threat from a cybersecurity perspective.
Other cases for J1939 include modular vehicle attachments such as agricultural equipment or trailers. These can serve as a vector to attack the parent vehicle (in this instance, a tractor). Gaining access to a trailer left overnight is much simpler, say, than to a tractor that is better guarded. The trailer is likely used by many service vehicles, and thus can infect many, if not all of them. These, in turn, can be infected by compromised service vehicles creating a viral effect.
It is worth noting that attacks originating from the cloud, such as fleet management systems, Wi-Fi, and Bluetooth, are possible. However, as they do not relate directly to SAE J1939 cybersecurity, we will look at them in a future article.
Regardless of the attack method, we should assume the enemy is among us, and that somehow the attacker can inject rogue traffic into the J1939 network.
SAE J1939 cybersecurity attack vectors and scenarios
J1939 uses 29-bit, extended CAN addressing, implementing its own format. This implies there is no way authenticate the origin of the message.
Any spoofing or impersonation attack is possible since any ECU can send a message ID it wishes. This is without any way to ensure that it originated from the designated ECU.
For example, any ECU can inject messages that would tamper with the power train, engine control or instrument cluster ECUs. Misuse of diagnostics messages can stop a trailer dead in its tracks. Complex scenarios, such as MITM (Man In The Middle), may also be staged.
Passenger vehicle configuration remains fixed for the vast majority of cases after it leaves the OEM assembly line, and via the dealer, reaches its owner. This means the security mechanism imposed at this point remain valid and relevant for the whole lifecycle of the vehicle.
This is not the case with heavy-duty vehicles as they have a much more complex and dynamic lifecycle. The dealer is entitled to make changes, add optional components, etc. The same applies to the vocational integrator, the fleet owner, or any independent owner.
Equipment can be mixed-and-matched, and you will see this more often than not with agricultural equipment. Even worse, these are usually shared among many vehicles, enabling the spread of malware to any connected device, and vice versa. An epidemic effect is highly likely in this sort of situation.
Aftermarket Fleet Management Equipment Installation
These are devices added by fleet owners to monitor and control their fleet. In some cases, regulations require the installation of driver-hours recording ELDs (Electronic Logging Devices) and other telematics equipment.
In all such cases, where these devices have not been part of the OEM cybersecurity control process –nor part of its supply chain– cyber-protection is not guaranteed.
As a result, such devices can be compromised and used as a means to introduce malware into the vehicle.
Specific Embedded Software Issues
There are several types of vulnerabilities when implementing a protocol or a standard:
- Inherent protocol vulnerabilities, where a protocol is defined in a vulnerable way – we can attack the system just by reading the specification.
- Implementation vulnerabilities or software bugs, for example, buffer overflow.
- A poorly defined/complex protocol which leads to implementation vulnerabilities, or code flow that exposes the protocol to attacks.
As we are focusing on the J1939 protocol, we won’t cover generic embedded issues or general ECU related vulnerabilities. J1939 is a complex protocol (compared to the standard CAN bus). We shall discuss the 3rd vulnerability type. To explore them in any depth, we need to look at actual code.
DISCLAIMER: The code used for this vulnerability assessment –although freely available on the internet as open-source for educational purposes– will not be referenced at the request of the code owner. All vulnerabilities found were reported to the owner to help make it better. This is not amateur code, having been developed by an authority in the field.
The original code was loosely obfuscated by applying name changes to all private functions, variables, and constants, and by removing all comments. De-obfuscating the code is done manually and requires minimal reverse engineering. The code snippets presented here are after de-obfuscation, with meaningful names and comments.
The code target system is various Arduino platforms, including ARM-based, and therefore there are some small footprint requirements.
JUMP TO AN ISSUE
General Pitfalls Seen in the Code
A common flaw seen is the use of the J1939 sequence number (SN) as an index into the message data – without a scripting a check of the following:
- 0 < SN <= 255 (SN = 0 may easily cause a buffer overflow)
- SN <= number of frames
- SN should go up by one – no reordering in CAN bus
Another is the acceptance of message size and the number of frames without the performance of a sanity check:
- Number of frames = ceil(message_size/7)
Also, when using a message size buffer less than the maximal size of 1785, there is no special care taken to prevent buffer overflow:
- Validate the number of frames and message size to match the buffer size.
- When the buffer size is not a multiple of 7, pay special attention to the last copy instruction.
State Machine Timeouts and Decisions
Here it is more vague, since every decision may have another effect. In general, use a ‘what-if’ approach to cover as many attack scenarios as possible.
Message Override Vulnerability
In standard CAN bus attacks, when overriding a message, we usually either send a message very frequently or disable the sending ECU (by entering a diagnostics session for example). Sending frequent messages creates a substantial footprint, and may be visible. Also, a diagnostic session may require us to fill in a lot of these.
The J1939 transport protocol enables us to override a message without the sender or receiver being aware. In this attack, we will override the message after it has been transmitted by the sender, making it a virtual MITM attack.
Anticipating a legitimate ECU will send a TP.CM BAM message (these are periodic messages). We send these messages with the number of packets doubled (byte 4), assuming that the number of frames is smaller than 128. After the legitimate sender sends the whole message (TP.CM BAM and the message data TP.DM messages), we will send our data. Neither the receiver nor the sender knows the message is modified. Furthermore, the attacker can look at the original before sending their own.
How it works:
If the BAM messages state machine is in an idle state, and we receive a TP.CM message with command BAM(32), we read the BAM message data and move to the next state. Any further BAM messages will be ignored until the message is completed, or a timeout occurs. So, the second BAM message is ignored.
There is no sanity check between the message length and the number of packets. The write pointer to the frame is deduced from the message sequence number, without validation. When the attacker sends the messages with the sequence numbers starting from sequence 1, it will override the reassembled message data. Finally, since we have doubled the number of expected frames, only now will the TP (transport protocol) transaction finish and the message be received by the higher layers.
Figure 1: Code snippet – message data reassembly
Several mitigations could prevent the attack:
- Comparing the number of frames and message length.
- Comparing the number of frames/message length with known PGN message length.
- Comparing the message sequence number with a stored value since there is no reordering on the CAN bus.
PTP (peer-to-peer) Sender DOS (denial-of-service)
Although DOS (denial-of-service) attacks in SAE J1939 cybersecurity are trivial, we will highlight this one since it could have been easily avoided.
The TP (transport protocol) defines a PTP session which requires RTS (Request To Send) messages, and that the receiver should send a CTS (Clear To Send) message.
When receiving RTS requests (even if dedicated to another ECU) the attacker keeps sending CTS replies. This will prevent the sender from transmitting the data. This will continue until the receiver times out and sends an abort message.
How it works:
When receiving a CTS reply, the sender resets the sending, preventing the timeout from occurring.
Figure 2: Code snippet – PTP frame CTS state machine
When receiving repeated CTS messages we should never reset the timer.
TP Receive Buffer Overflow
Since memory allocation is static, you should not expect a buffer overflow into the TP packet data. However, there are two of them.
Send a BAM or PTP TP message with a sequence number of 0. This will copy 7 bytes into bytes -7–0 of the 1785 bytes, overriding 3 bytes of the PGN, the source address, the destination address, the number of packets, and the frame number of the current session.
If the pointer was not defined as a signed int (16 bit for Arduino), but rather as an unsigned int, the attack would have copied 7 bytes into bytes 1785-1792 where we have a 1785-byte buffer. This overrides the session length variable, used later for copying data, resulting in much more dangerous exploitation.
How it works:
When BAM message data is received, the data is copied according to the message sequence number without validation (see Figure 1 above). The sequence number in the protocol should start from 1. When placing 0, it means nPointer = -7 and the attacker writes to the 7 bites before the buffer.
Validate the sequence number; SN – 0 < SN < number of frames. Also, validate the number of frames.
Small Footprint Code Variant Buffer Overflow
Sometimes to save space, the J1939 stack does not support the maximal frame size of 1785 bytes. In one of the compilation variations, the maximal frame size was 256 bytes with a 256-byte buffer. The fact that we rely on the sequence number as part of our pointer, without validation, can cause a buffer overflow. This applies to both BAM and PTP sessions.
Assuming we have a 256-byte buffer. We can send a message with up to 256-byte message length but with a sequence number >= 36. This causes a basic buffer overflow of up to 1529 bytes (see Figure 1 above).
Validate the sequence number; SN – 0 < SN < number of frames. Also, validate the number of frames according to message length. Make sure the last copied frame does not create an overflow or increase the buffer size to 7*36 = 259 bytes.
Mitigating cyber-attacks on SAE J1939 heavy-duty vehicles
Tier-1s and OEMs need to take proactive action to protect the heavy vehicle for a large number of reasons, including:
- Regulations such as the UNECE WP.29
- Growing awareness within professional bodies in the automotive industry
- Top management who wish to protect their firm’s reputation, and prevent loss of life and damage to property, for which they will be liable
- Insurance companies requiring cybersecurity adoption to minimize risk
Reducing risk involves acting in a large number of areas. Examples include those detailed in the ISO/SAE 21434 standard and AUTOSAR best practices guides, among others. Practically, this translates to an extensive set of activities, including:
- Process and procedures
- Cybersecurity management systems
- Secure by design approach of all components and the overall system
- A secured software development lifecycle
- Compliance with standards such as A-SPICE and MISRA
- Dedicated cybersecurity protection mechanisms such as IDS/IPS, endpoint protection, cryptographic solutions.
It is important to note that out of all of the solutions mentioned above, IDS/IPS is the only dedicated, devoted, and independent component of this defence-in-depth approach.
While implementing many security means as part of the overall strategy is imperative, maintaining an IDS/IPS is crucial. IDS/IPS solutions are the only components of a vehicle to have all their resources allocated to its protection.
Ideally, the IDS/IPS function should reside in the central gateway. However, you can distribute it to the TCU, IVI, V2X OBU, domain controller, or any other connectivity or safety-critical ECU. Only this way will you best protect the vehicle..
Automotive cybersecurity solutions for SAE J1939 heavy-duty vehicles
Since the J1939 CAN bus is the heart of the heavy-duty vehicle, interconnecting all ECUs, it is prone to cyber-attack and should therefore be well protected. The methods to be employed should include a variety of procedural and technological means as we have detailed throughout the article.
We need to take measures to implement proper security measures. To protect the vehicle, and the J1939 networks used by heavy-duty vehicles, from dangerous attacks.
Arilou offers the Sentinel-TRK IDS/IPS for SAE J1939 as a customizable and comprehensive protection tool. In addition to Sentinel-TRK, a variety of automotive cybersecurity products are available both in a complementary capacity or for other domains:
- Arilou Sentinel-CAN IDS/IPS for CAN bus
- Arilou Sentinel-ETH IDS/IPS for automotive Ethernet
- CANpress CAN bus traffic compression with optional authentication and encryption
These among our many other products provide holistic protection solutions which answer the challenge of securing modern and legacy in-vehicle networks.
You can find out more about our product portfolio on our solutions page. If you would like to speak to us about SAE J1939 cybersecurity, or any related topic, please don’t hesitate to reach out to us using the contact page.