The Controller Area Network (CAN) of a vehicle can be thought of as its computer network or nervous system. Instead of requiring numerous point-to-point cabling hops connecting the various components, a single network bus provides the infrastructure that every component in a vehicle can connect to. In the world of networking, “bus” refers to a network topology where the participants in the network are all plugged onto a single piece of network infrastructure. It eliminates the necessity and complexity of point-to-point wiring where a car may have as many as 70 components that need to be in conversation with one another.
Since the invention of CANBus in the 1980s, vehicle components that connect to a CANBus have included relatively simple features such as electronic window controls, car locking systems, and airbags, but this has now grown to include more advanced technological additions like infotainment systems. Increasingly, information from the car’s sensors are needed by multiple recipients; for instance, in a modern car the knowledge that the vehicle is set to use the reverse gear needs to be known by the transmission system, indicators on the driver display, vehicle reversing lights, proximity sensors, and the driver’s reversing camera.
The simplicity and ubiquity of CANBus technology has opened it up to other industries and modes of transport; marine engineering, industrial automation, electric scooters and electric bikes may also deploy CANBus technology. As the automotive industry continues to develop its driverless technology, CANBus will play an increasingly large role – far beyond its originally intended scope.
Threats and vulnerabilities
As Hyppönen’s Law surrounding IoT devices states: “if it’s smart, it’s vulnerable”, and CANBus is no exception to this concern. Hacking a car remotely by gaining access to its CANBus isn’t simply a theoretical concept – it’s been done. This threat, however, is given relatively little attention, despite its potential to put lives in danger. An external party having control of a vehicle directly puts users’ physical safety at risk – an event rarely seen in the world of cybersecurity.
The emergence of CANBus in the 1980s means many important security features a vehicle CANBus should have today are not standardized, and are in some cases non-existent. The varied protocols in place to protect against accessing the CANBus put some makes and models of cars at greater risk than others. Take patching as an example: if a specific vulnerability is found, the vehicle has to be patched. Most manufacturers would have to recall the vehicles in question in order to update them. This would result in a significant number of cars never being updated. Very few manufacturers support over-the-air updates and even fewer provide automated updates, despite this being standard security practice for most consumer technology devices.
As vehicle manufacturing takes strides towards driverless options, and cars in general become increasingly smart and connected, the security of CANBus needs to be better understood and addressed.
A virtual vehicle in a virtual machine
To build awareness of CANBus’ security threats, Immersive Labs has created a series of 16 offensive labs. It begins by gently introducing CANBus concepts, and security aspects of CANBus deployment – including CANBus integration with other systems – before tackling tools and techniques used for CANBus reverse engineering. Participants must put this knowledge into practice to identify and manipulate components on the CANBus.
These labs are most suited to pen-testers for IOT/embedded systems but would also be of interest for an advanced red teamer. Tooling includes a CANBus-enabled virtual car, providing a safe environment to explore what could otherwise be dangerous on a real vehicle’s CANBus.
CANBus Ep 11/16 – The Virtual Car
Labs in the series
CANBus: Ep. 1 — An Introduction
CANBus: Ep. 2 — Systems
CANBus: Ep. 3 — Threat Models
CANBus: Ep. 4 — Messaging
CANBus: Ep. 5 — SocketCAN
CANBus: Ep. 6 — In The Rear-View Mirror
CANBus: Ep. 7 — Interacting with a CAN Sensor
CANBus: Ep. 8 — Fuzzing a CAN Sensor
CANBus: Ep. 9 — Record and Playback
CANBus: Ep. 10 — Physical Connection
CANBus: Ep. 11 — The Virtual Car
CANBus: Ep. 12 — Reverse-Engineering Tools
CANBus: Ep. 13 — Reverse-Engineering Tools Continued
CANBus: Ep. 14 — Fuzzing with SavvyCAN
CANBus: Ep. 15 — DBC Files
CANBus: Ep. 16 — Real-World CAN Architectures
Expert input
The Immersive Labs CANBus series was created in collaboration with Mark Adams, an expert on driverless vehicle security. Following 25 years at GCHQ, Mark worked at Lyft as a principal security engineer involved with their autonomous vehicle project. His understanding of CANBus security and driverless tech vulnerabilities ensures our CANBus labs are driven by the latest threat intel in this area.
You can hear from Mark in the latest episode of the Immersive Labs Cyber Humanity podcast which discusses the evolution of CANBus, maliciously taking control of a vehicle, and future threats on the horizon.
If your organization isn’t already using Immersive Labs, our sales team will be happy to demo the CANBus series at a time convenient to you.