Your Car Could Be A Cybersecurity Target: Limp-home Mode

Your Car Could Be A Cybersecurity Target: Limp-home Mode

I give demos on how easy it is to connect to my car using the controller area network (CAN):

Basically there is little in the way of security, as the CAN bus wasn’t originally designed to have security in mind, and focuses on multicasting messages (sending to every device on the bus), and on detecting devices which are faulty, and kicking them off the bus. These days virtually everything in a modern car is controlled over the bus, thus a major flaw could compromise vehicles, even when being driven.

Now researchers from the University of Michigan have found that the CAN protocol has a dangerous vulnerability — the bus-off attack. This attack focuses on the built-in error handling facilities and is used to compromise the bus. The paper was presented at an ACM conference in Vienna [here]:

They focus on creating a DoS (Denial of Service) against the ECUs (Electronic Control Units), so that they are not able to perform their control operations, and can thus compromise the vehicle’s operation.

An old bus

The CAN bus was developed by Bosch, and was first used in the BMW 8 Series in 1988. It then finally made its way to a standard in 1993 (ISO 11898). The great thing about the CAN bus was that it was designed with the ISO 7-layered model in mind, and thus was ready to connect instrumentation to the Internet.

Overall it has three main layers which fit between the Network layer: object layer (dealing with message handling); transfer layer (deals with fault confinement and message validation); and the physical layer (deals with sensors and cables). This can be illustrated as:

With this we have a number of ECUs (Electronic Control Units) and these connect vehicle we have a number of ECUs (Electronic Control Units) and these connect onto a common bus. Typical ECUs are the engine management control unit, the traction control unit, and so on. We can then connect to an On-board Diagnostic (OBD) connector in order to connect to the bus, and view the messages (it is thus connector that I use to connect to my Audi here):

While the ODB give some physical security (where you would have to get into the vehicle to connect it), these days a remote connection onto the bus from the Internet can be possible. Unfortunately, too, security of the bus was not a major factor at that time. So the CAN bus allows for a backbone that connected to all the devices using a common bus. Signals could then be broadcast across the bus using an addressing format. Its major flaw is that all the devices share the same bus, and so can hog the bus, and starve the others of information. Along with this, every device on the network receives all the messages, thus, messages from the from the external Internet will be sent to all the devices on the network.

Cho then used the built-in error handling mechanism to perform a DoS against the bus using an error information packet, which stops all the other messages on the bus, and then tells the devices on the bus to resend whatever they are in the process to sending. This swamps the bus with traffic.

But Cho takes it one step forward, as each node sets an internal error counter, and when it receives the error message it increments its counters. When the counter gets to 128, it goes into passive mode, and is not able to stop the messages on the bus, then, when it gets to 255, it is disconnected from the bus. In this way the whole of the vehicle can be switched off complete. The vehicle will then go into a fail-safe mode, and just give the driver enough functionality to take the vehicle to the nearest service centre.

Setting it up

The main conditions they used were:

• Send a spoofed message from a device with the same ID as an existing message. This is easy to implement and just requires to know what the next ID message will be.
• Send a spoofed message at the same time, and same ID, as an existing message. This again is fairly easy, as the messages are synchronised by a clock.
• Set a priority bit on the message so that it has a higher importance (so that the real message will be ignored, as it is less important). This condition is the most difficult, but still feasible.

The scary thing is that once the error message is released, the bus will then go ahead and performance its own attack. On seeing the error, the node who is targeted in the fake message will then increment its own error counter, and attempt to resend the message. Unfortunately, the only the spoofed message will be seen as it has a higher priority. So, it just keeps copying and sending out messages until it is kicked-off the bus.

An attacker is likely to target low ID values, as they are more likely to the safety-critical devices, such as for the braking controller. To test the method, the researchers successfully compromised two cars (2013 Honda Accord and 2016 Hyundai Sonata):

Hacking an EV

You can find more information here:

https://medium.com/asecuritysite-when-bob-met-alice/did-you-know-an-electrical-vehicle-can-be-hacked-through-a-charging-session-2a75d9e9e11c?sk=9c7a9229bebe360ddb5c5572f131d855

Conclusions

If you think the Internet is a scary place for security, IoT is going to be a whole lot scarier, as the systems we use for embedded devices are often fairly simple.

For fixing this particular problem, the researchers recommend that too many repetitive error frames defines that something is going wrong, and to correct the messages before they are sent. Also the system can detect if a device stays in the active mode, even though the passive mode counter has reached its limit.

CAN Background

The Controller Area Network (CAN) protocol is an ISO-defined standard (ISO 11898) for serial data communication at bit rates up to 1Mbps. It was initially developed for the automotive industry, and has the advantage of using a common bus which reduces the need for wiring harnesses. It has since outgrown this application. The standard includes a physical layer and a data-link layer, which defines different message types, arbitration rules for bus access and methods for fault detection and fault confinement.

Its basic features are:

• Differential transmission using twisted-pair cables.
• Arbitration — access to the bus is controlled by a non-destructive bitwise arbitration technique. In arbitration, every transmitter compares the level of the bit transmitted with the level that is monitored on the bus. If these levels are the same then the unit will continue to send.
• Small messages (only up to 8 bytes in length), each with an associated checksum. These have fixed format messages, which transmit data and other information. Nodes only transmit messages when the bus is free. The content of a message is identified by the IDENTIFIER, which describes the data, but does not provide for the destination of the information. All the nodes on the network can decide whether they need to read the data or not (multicast).
• No addressing structure — messages are broadcast on the common bus with a message with a priority level and identification.
• Prioritization of messages — each message has a defined priority. On a free bus, any node can transmit their message. Two or more units which transmit a message at the same time produce an error condition. The unit with a message of higher priority always gains access to the bus over a lower priority node.
• Multicast reception with time synchronization — all nodes are able to receive transmitted data and can also quickly synchronize their clocks to the transmitted data.
• Error detection and signaling — powerful error handling scheme that allows for the retransmission of messages when they are not properly received. There is also automatic retransmission of corrupted messages as soon as the bus is idle again. The recovery time from detecting an error until the start of the next message is at most 29 bit times, if there is no further error.
• Multimaster — any device can gain control of the bus.
• Enhanced fault finding and fault isolation. Implementation of methods of fault finding and removal of faulty nodes from the bus. There is also a distinction between temporary errors and permanent failures of nodes. Defective nodes are switched off.
• Unlimited number of connections — any number of units can connect to the bus (without causing a disruption) and they can also be easily disconnected.
• Guaranteed latency times.
• System-wide data consistency.
• System flexibility — nodes can be added to the CAN network without requiring any change in the software or hardware of any node and application layer.
• Sleep mode/wake-up — a CAN device may be set into sleep mode without any internal activity and with disconnected bus drivers. This helps to save power. The sleep mode is finished with a wake-up by any activity or by internal conditions of the system.
• Acknowledgements — all receivers check the consistency of received messages, acknowledge a consistent message and flag an inconsistent message.

References

[1] Cho, K. T., & Shin, K. G. (2016, October). Error handling of in-vehicle networks makes them vulnerable. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (pp. 1044–1055).