Who We Are
The Sentryo Security Labs team is developing the next generation of visualization and detection algorithms for our product, ICS CyberVision.
We analyze the latest threats in the ICS world and try to improve the product with the help of Data Science. This includes helping our customers understand their network, and finding new ways to detect cyber attacks.
Although our main area of expertise revolves around Cyber Physical Systems and specifically ICS networks, we are also interested in related fields and critical systems in general, like the next generation of connected and autonomous cars.
In this context, last year, we worked on new ways to detect malicious activities in a car network and the specific threat of message injections.
Our Source Data
In a modern car, hundreds of electronic devices called ECUs (for Electronic Control Units) communicate with each other on a shared bus (a type of communication system that transfers data between components) with the CAN protocol. Each ECU has a specific role in the functioning of the car. One could, for example, measure the speed of the car with a sensor and broadcast the value on the bus. Another ECU might be waiting for a specific request to start applying the brakes.
The CAN protocol has been in use for quite some time now, and is rather basic. Each ECU can broadcast a CAN message on the bus. The message must contain an ID (the CAN ID) and can contain up to 8 bytes of data.
The content of these messages is vendor and model specific. That means we know the speed value of the car is somewhere in a message, but we don’t know in which type of message (which ID) and how and where the actual value is encoded (position, number of bits, endianness). This could look like some sort of safeguard against attackers but, as often with security by obscurity, it is only a matter of time before a determined attacker reverse-engineers and finds the not-so hidden information.
Cars, today, are getting more and more connected to the outside world. By leveraging some vulnerabilities in one of the many subsystems inside a car, an attacker can remotely gain a foothold in the CAN bus.
Because of the broadcast nature and lack of security of the CAN protocol, it is easy for an attacker to inject malicious messages on the bus. The major issue here is that ECUs make critical decisions based on these messages and have little to no mechanisms in place to filter abnormal ones.
One attack, in particular, comes to mind where an attacker was able to trigger the “park assist” function of a car , while driving at high speed, to crash the car. The ECU in charge of that function is monitoring the speed of the car and do not honor a “park assist” request unless the speed is below 5 mph. The attack worked nonetheless because the attacker also injected spoofed speed values on the CAN bus (note: the attack here is simplified).
This is just one example, where fooling a specific ECU enabled the attacker to indirectly take control of the steering wheel in very dangerous conditions. Bypassing the speed restriction and making a turn at high speed can easily cause a roadside car crash. 2016, Charlie Miller and Chris Valasek, “CAN Message Injection”, download the document
Our project was inspired by the work of Jun Li  who presented its prototype at DEFCON. The overall idea is to build an anomaly detection capability on the CAN bus.
It works by:
- extracting, with some message structure knowledge, the physical variables like the speed, RPM, or acceleration values that are circulating in CAN messages;
- learning the normality of the system, i.e. the normal interactions of these variables while driving;
- detecting deviations from this model that may hint at message injection;
This can be expressed as a multivariate time series anomaly detection problem and there are many ways to approach this. We will describe our own take on the subject. 2016, Jun Li, “Deep Learning on CAN BUS”, DEFCON car hacking village 2016, watch the video
In this experiment, we used the undocumented high-speed CAN bus of a modern car (2016 model). We started from scratch, with our car and a CAN traffic reader. We built different network captures from different test drives, where we carefully noted our actions and the overall status of the car (speed, acceleration, etc.).
CAN message reverse-engineering
We then started analyzing this data to find which are the physical variables.
Using our observations, the little documentation available on the Internet, we explored the data and managed to extract the most important ones: speed, acceleration, rotation per minute (RPM), steering angle, etc.
Below, an example of the RPM variable extraction where we found out that the RPM values were stored in two consecutive bytes (the 4th and 5th bytes) of a particular CAN ID.
As you can see on the right, we were able to reconstruct the entire time series for the RPM variable, starting at 0 when the engine was off, and obviously changing during the driving part.
That’s it for part 1, which presented the CAN environment, the message injection threat, and how we managed to extract the necessary data from CAN messages. In part 2, we will use this data to train Machine Learning models under normal conditions and try to detect message injection attacks!