On the day of the release of this article, I was present at incognito.kr, to talk about Automotive Cybersecurity and how to get started in this field.
Please note that I am not an expert is this field by any means. I just have some experience.
You can find the slides of this talk here !
Brief overview of the Automotive Cybersecurity landscape
The main thing that is crucial to understand is that the Automotive Industry works at massive scales. To beat your competitor, it is not enough to have the better product, you must also be able to deliver it reliably in volumes of tens of thousands. You also have tight deadlines and very strict requirements.
Another thing to understand is that, although security in cars is not new, Cybersecurity is. It sort of came to a shock to the industry that their cars were insecure when, in 2015, a Jeep Cherokee was hacked. The two people doing this owned everything in the car from the comfort of their homes. They could turn the wheel, jerk the seatbelt, control the infotainment system.
This kind of served as a baseline for the nightmare scenario a car manufacturer can go through. Of course, Chrystler patched the issue very quickly. But, as they did not support OTA (Over The Air) firmware updates, you had to run the update manually or at your dealership to be safe from the exploit.
There were other exploits before that (one infamous case demonstrated a police car being hacked.). However, this event served as a catalyst, because not only could you see the exploit, but you could also see the reaction of the journalist, absolutely terrified because he realizes that he has no control over his car in the middle of the highway. Nobody wants to be in this situation. Unlike most other cases of hacking, this immediately puts the victim’s life (and the surrounding people) in danger.
In response, the carmakers have tried to adapt. However, it seems that not every player is going at the same speed.
Attack surfaces
From all the attacks linked before, you may have noticed that the entrypoint is almost always different. As you can guess, a car has a very large attack surface.
I have often heard from semi-smart people that “a car is basically a computer on wheels”. A car is actually more of a bunch of networks…with wheels. So, it’s worse, actually.
The main attack surfaces (from my experience) are the following:
- The infotainment system: Often supports Bluetooth, WiFi, various radio protocols, and features a lot of user interaction,
- Mobile apps for car management: Can interact directly with the car, while being in an environment that is easier to debug for a pentester,
- The TPMS will send information regarding the pressure of your tires to the rest of the car wirelessly.
- OTA (Over the air) / PCB Reverse-engineering: Some cars can be updated wirelessly. This is interesting to us, because if we are able to conduct an MITM attack, we could install our own firmware.
- Good old API Hacking
Of course, there are other methods, like performing replay attacks or just breaking the car’s body to access the car’s internal wiring underneath.
The Controller Area Network
CAN as a protocol is often referred to as the CAN bus. It was created by Bosch in 1986, and is still used to this day in medical devices and Automotive ECUs.
The layout of a CAN frame is not complicated but there is a lot of information you don’t need to get started, so here is a oversimplified version:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Arbitration | Control | Data |
| ID | Field | Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data (0-8 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC | ACK | EoF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Later, the protocol was extended to support longer messages in the data field (up to 64bytes):
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Arbitration | Control| DLC |
| ID | Bits | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data (0-64 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In both cases, the frame:
- starts with the arbitration ID field, which is used to identify the message and to determine its priority on the bus,
- the control field contains information about the message type and format,
- the data field contains the actual message payload.
In the classic CAN frame, the data field can contain up to 8 bytes of data, while in the CAN-FD frame, the data field can contain up to 64 bytes of data.
The length of the data field is indicated by the DLC field in the CAN-FD frame. Both frames end with a cyclic redundancy check (CRC) field, which is used to detect errors in the message transmission, as well as an acknowledgement (ACK) field in the classic CAN frame, and an end-of-frame (EoF) field in the CAN-FD frame.
Attentive readers will notice something weird about this. Indeed, the sender of the message determines
the order of importance of the message sent, through the arbitration ID field.
However, there is no check or verification to check if the message is indeed as urgent as it seems, or the identity of the sender.
This means that if you are connected to the CAN bus with a rogue device, you can essentially block the car ECUs from receiving new messages if you spam the bus with messages with a super low arbitration ID, kind of like this:
#!/bin/python3
import can
bus = can.Bus()
while True:
msg = can.Message(12, data=[0 for _ in range(8)])
bus.send(msg)
If ECUs don’t receive updates from other ECUs, they will assume they are faulty, and turn on a DTC. In some cases, they can even shut down if they are not critical for the safety of the passengers.
There has been at least one attempt to use another protocol that I’m aware of: FlexRay, but AFAIK it is not used outside of BMW vehicles.
Recently, automakers have been attemtping to implement SecOC, aka Secure On-Board Communications.
However, implementing this and making the transition is not trivial for automakers, because the supply chain has to be in sync, since they all have to use the same standard.
Also, SecOC is not a silver bullet, it does not prevent a rogue actor from listening on the network, because the messages are only signed. (If you haven’t clicked on the link, you really should, it’s an excellent resource for understanding SecOC.)
another thing worth mentioning here is AutoSAR, the underlying architecture on which an ECU runs on. However, you will not see it a lot on the offensive side, so maybe don’t spend to much time on it.
Dataframes and protocols
As you can see from the nice ASCII arts above, each CAN frame send a blob of data. This data is often referred to as a Message.
Often, constructors will all have different messages, which are stored in a CAN database.
You can find some reverse-engineered databases here in the dbc format.
There are other formats for specifiying CAN databases, depending on the software used by constructors, but it will often be dbc from my experience.
This database is the first thing you want once you get access to a CAN bus because it allows you to know which message you can send, and how to interact with the car.
There are many tools you can use for fuzzing and figure out how to make the car do things.
There are also some standardized messages, such as XCP (a debugging and
calibration protocol), and UDS (aka Unified Diagnostic Services),
but they’re typically protected by Authentication mechanisms. UDS exists on almost all models in the world, which makes it is a good thing to look at.
Both of them work with a seed/key algorithm, for which the implementation depends on the constructor. Depending on your target, you can find
other researchers’ work to get access to these messages, and change calibrations, perform binary dumps, etc.
A more detailed description of the UDS protocol is available here.
Connecting to a car
You have two types of tools to be wired to a car:
- the really nice (enterprise-level) ones,
- the more DIY ones (which are actually quite nice).
For the enterprise-level stuff, you can already forget about it. It’s so expansive that you have to call the company to know the price. Even if you manage to find one on ebay, you will have to pay a (hefty) license fee to use the software that goes with it.
That leaves you with the DIY-ish stuff like ODB-II connectors.
Fortunately, you can find an OBD-II port on almost any car. Pretty much any of them works, provided your car doesn’t use some proprietary CAN derivative.
If you don’t have a car and but you want to experiment with the CAN protocol, you don’t even need a car to get started – just Linux. (Think about it, the software stack for the infotainment system often runs on Linux, so there is support out of the box):
# you might need to run this
sudo apt install can-utils
# enable kernel module
#
# if you you use a can connector, you can just retract the v from vcan
# in the following commands
sudo modprobe vcan
# set up the network interface
# s/vcan/can if using a real connector
sudo ip link add dev vcan0 type vcan
# run the interface
sudo ip link set up vcan0
Then, you will have a working CAN interface, that is even able to generate random messages for you if you need it to.
This is helpful for development, though AFAIK it cannot respect .dbc/.REF specifications. (yet)
After doing this, i would advise you to use the python-can package. It’s all you need to get started basically!
Useful links & write-ups
Here are compiled, in no particular order, other ressources that I have used when learning about cars:
- fault injection on renesas rh580,
- 0-click RCE Tesla Model 3 – presentation,
- srecords specs often used for car firmware dumps,
- Paper on Car Fuzzing using Vector software,
- Another Tesla hack write-up,
- Brilliant car-hacking blog
See you next time :)~