The Network Standard Used in Cars Is Wide Open to Attack

The networked electronics found under the hood of modern automobiles enable a great many useful and cool things, such as fuel-saving engine optimizations, parking assist mechanisms, collision avoidance systems, and myriad further applications most often involving sensing and the passing of data among vehicular systems and human drivers. As is pretty much always the case when electronics become networked, this connectivity also offers hackers new potential exploits.

According to research presented last month at the ACM Conference on Computer and Communications Security in Vienna, courtesy of computer scientists at the University of Michigan (and Adrian Colyer’s excellent The Morning Paper), the controller area network (CAN) protocol implemented by in-vehicle networks has a new and potentially quite dangerous vulnerability. The attack, known as a bus-off attack, exploits the CAN’s built-in error handling facilities to potentially nuke both contemporary insecure CANs and future secured versions.

First off, CAN is a fairly old technology. It was first developed and published by Bosch in 1985, with CAN-ready processors released by Intel and Philips in 1987. CAN made it into an actual car (the BMW 8 Series) in 1988, and was made the international standard for in-vehicle networks in 1993. Nowadays, it’s pretty common and there are several spin-off protocols, such as CANOpen and DeviceNet.

Prior to CAN, auto electronics were connected device to device as needed. If, say, a dashboard indicator, water pump, fuel injection controller, and diagnostic computer all required temperature readings from the engine, then we’d expect a wire strung from the thermostat to each one. Multiply this ad hoc topography across an entire car and the result was an unwieldy nest consisting of miles of of wires. CAN fixed this by implementing a bus architecture. Every component in CAN is hooked into the same backbone across which messages are transmitted in a unified format. Crucially, this means that each device only needs to have a single network interface rather than however many are needed to connect to x number of other devices.

The result looks kind of like a local internet network, where every message to and from the greater internet is actually received by every other computer on the local network. It’s just that those meant for other computers are filtered out. In CAN, the collision-avoidance system might not care about engine temperature, but it will still get those messages. That system knows, however, that it doesn’t care about the temperature data and so it’s able to safely discard/filter out that data.

This brings us back to the proposed new vulnerability. According to the UM researchers, Kyong-Tak Cho and Kang Shin, it’s possible to take advantage of CAN’s built-in error handling mechanism in what amounts to a Denial of Service (DoS) attack.

Error information is passed among Electronic Control Units (ECUs) in the form of error frames, which are standardized messages containing two data fields where further error details can be specified in the form of flags (where one bit in a particular position is flipped to indicate something useful). When any ECU node along the bus detects an error, it sends out a message in the form of an error frame. This nukes all traffic currently on the bus and tells every other ECU that they need to resend whatever they were in the process of sending. Simple enough.

There’s more to it, however. Every ECU node maintains an internal error counter. When a node realizes that it’s either sent or received a bad message, it not only sends out the aforementioned error frame, it increments this counter by some amount (eight ticks for sending a bad message, one for receiving a bad message).

When an ECU’s error counter hits 128, it goes into passive mode. Future error messages from passive nodes will no longer nuke everything on the bus. When a counter hits 255, the corresponding ECU will lose its access to the bus completely. When this happens, things turn sour for the whole automobile system, which may shut down completely or enter a “limp-home” mode.

Image: Cho et al

“Since the bus-off is a serious problem, in most cases, vehicle systems are designed to first enter a ‘limp home’ mode (when it occurs) with all their parameters set to pre-set values, and thus run with reduced functionality (e.g., limited engine RPM),” Cho and Shin explain in a paper that accompanied their presentation. “In this mode, warning lamps are lit up on the dashboard to alert the driver, and the vehicle runs only for some time before it is properly serviced by an OEM-authorized service center. Depending on the severity of the underlying issue, a vehicle in the limp home mode will later be totally disabled.”

It’s thus possible to disable one or more components of a car by flooding a CAN’s bus with error messages. This isn’t a simple undertaking, but it can certainly be accomplished with some dedication. There are three conditions an attacker would have to meet to pull this off: 1) The spoofed message must have the same ID as an existing message; 2) the spoofed message must be sent at the same time as that existing message; and 3) the spoofed message must have a particular flag set establishing it as dominant over the real message so that the real message is ignored by the various devices connected to the bus.

The first condition is trivially easy and is just a matter of having an ECU connected to the bus that has no filtering in place, such that it receives every message on the network and can determine based on this what the next message’s ID will be. The second is likewise easy because messages are passed around the CAN at fixed intervals—it’s just a matter of clock synchronization. The final condition is not as easy (or easy to explain, anyhow), but is still totally reasonable to implement.

The neat thing is that once you unleash one of these error messages, the CAN will sort of do the rest of the work for you. The ECU node whose message you faked will see the error, increment its error counter, and then attempt to resend the message. But, it will only be seeing the spoofed message, not its own original message, because we made the spoofed message dominant. So, it will just keep copying and sending our bunk message until it’s forced off the data bus. Mission accomplished.

“If the attacker targets a message sent with high priority (i.e., a low ID value) and small message intervals, then the attacker would most likely disconnect a safety-critical ECU that sends important messages related to, for example, vehicle acceleration or braking,” Cho and Shin explained.

This was, by the way, demonstrated in actual vehicles.

As it turns out, this vulnerability is fairly easy to fix. For one thing, it’s easy to detect because the repetition of error frames implies something nefarious is going on—normally, the source of the erroneous message would take action to correct the message before resending. The attack can be further confirmed by the presence of an error message that remains in active mode after the passive mode counter has maxed out. This would only be possible if the same message were being sent by two different ECUs.

“Even though the proposed attack has not yet been seen in the wild, it is easy to mount and also directly related to drivers/passengers’ safety, and should thus be countered with high priority,” Cho and Shin conclude. “Moreover, the facts that the proposed attack can nullify state-of-the-art solutions and is easy to launch, make it even more important to design and deploy its countermeasures.”

Via: Motherboard