CAN-in-CAN Attack for Bypassing Security
At the ESCAR USA 2022 conference, we presented research discovering a new protocol attack on the CAN-FD vehicle communication protocol named CANCAN.
What is CANCAN?
CANCAN is a CAN-in-CAN attack, involving the encapsulation of a seemingly valid CAN or CAN-FD message inside another CAN-FD message. It may be used for circumventing various security measures that perform CANID based filtering.
Figure 1 – Slow Sampling of a Fast Bitrate Message
Security Assumptions
The CANCAN attack will assume the following:
• An attacker is able to send an FD message with specific properties (such as a specific CANID) to a target. This may require the attacker to exploit a previous attack to gain
the ability to send messages on the CANBUS, or to utilize a physical access attack.
• The attacker wishes to send a specific attacking message. This may be some diagnostic message (e.g., over the UDS protocol) which will enable some restricted functionality,
or some incorrect or malicious signal data.
• The attacker cannot send the attacking message directly to the target. This may be because of IDS/IPS preventing such a message to be sent, or because of the routing rules
of a gateway located between the attacker and the target.
When CAN this happen?
This attack will require that a CAN-FD controller will attempt to begin the sampling of a message in the middle of the data field of a message already in the process of being sent.
This may occur in three scenarios:
1. Wakeup – when a controller will reset and start sampling the FD bus at the time that an FD message is in the process of being sent.
2. Bus Error – when an error in the sampling of the bus will cause a message parsing to end prematurely. An example of such a case is a bit-flip in the DLC field (representing the length of the sent data), causing a 64-byte long message to appear as a 7-byte long message.
3. Mixed Network – when a network will contain both FD supporting nodes, and CAN nodes which are only FD-aware. When encountering an FD message, the FD-aware CAN nodes may stop the message parsing and wait until the bus appears quiet and ready for sending a new message.
In all three cases, the controller will only accept an “encapsulated” message as valid if it first encounters a sequence of recessive bits. The number of required recessive bits making the bus appear quiet is 11 bits (IDLE bits) for the wakeup scenario, or 10 bits (EOF + IFS bits) in the case of Bus Error or Mixed Network scenarios.
The following GIF shows an example of the wakeup scenario demonstrated using our setup. An encapsulating message is created and repeatedly sent (using the ‘cancan_atk.py’ script). The target is reset every second (using the ‘restart_unit.bat’ batch file). The target will receive the sent message, but once every few resets will instead receive the encapsulated message (as seen in the PCAN View window).
Figure 2 – Setup Demonstrating the Wakeup Scenario
Encapsulation Techniques
There are several options regarding the encapsulation technique itself:
• Base Encapsulation – the usage of the message data field for encoding the entire encapsulated message.
• End Encapsulation – the usage of both the message data and the message ending (which includes the CRC and ACK fields) for encoding the encapsulated message. This method will
impose some constraints regarding the encapsulated message and require special handling for verifying that the message ending (which includes its CRC and STUFF Counter
values) appears valid. An optimized way of doing this is also presented, minimizing the overhead of the validation techniques.
• Multiple Encapsulation – encapsulating multiple messages in the same message, using the previously described methods.
Figure 3 – Base Encapsulation vs. End Encapsulation
Possible Fixes
This issue may be fixed in several different areas of the system:
• Controller – the controller logic itself may be changed to prevent this issue. When checking if the bus is quiet by counting 11 (or 10) consecutive recessive bits, performing the check using the fast bitrate (considering the ratio between the fast and slow bitrates) will prevent the CANCAN attack.
• IDS/IPS – intrusion detection and prevention systems may be designed to look for and prevent (or raise an alert) a message that seems to encapsulate another message.
• Authentication Layer – using a higher-level authentication layer (such as SecOC) may prevent the entire spoofing capabilities inherent to the CAN and CAN-FD protocols, rendering the CANCAN attack irrelevant.
Conclusion
The CANCAN attack may affect any component implementing the CAN-FD protocol and may affect protocols currently being developed (such as CAN-XL), unless specifically addressed.
For the full research paper, “CAN-in-CAN Attack for Bypassing Security”, click here.
