Cars, CANs and Cracking

Intel think that the smart cars of the future will be sending 11 Petabytes of data per year over the Internet by 2020. But do car…

Cars, CANs and Cracking

Intel think that the smart cars of the future will be sending 11 Petabytes of data per year over the Internet by 2020. But do car manufacturers understand cyber security, especially as they become interconnected?

Background

Vehicles are increasingly coming under a spotlight for a lack of security integration, such as with the compromise of the Jeep Cherokee, and in problems with Volkswagen key fobs, which reveal the encryption key of the fob by just listening to two encrypted messages. 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.

Honda and Hyundai

Recently 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):

Mazda

If you have a Mazda, be worried, as it could be a listening device for others.

Researchers — Stefan Tanase and Gabriel Cirlig from Ixia — have found that it was possible to discover a great deal of information from one of their models, including text messages, call records, app activity, photos, contacts, GPS history and emails. These were all stored in an unencrypted format. They also were able to install malware in the car, and where they could track its location in real-time.

Stefan and Gabriel managed to probe the car and then modified the autorun feature, in order to gain full access to the car’s infotainment system. After this they even managed to create a script on a USB device which would provide a “ping” with location data, in order to track the device. This worked, even if GPS tracking was not enabled on the car, as the cars were often fitted with a GPS chip. After this they then went after the wi-fi system, and were able to map open Wi-Fi networks in Bucharest:

Overall physical access to the car would be required for these attack. The researchers note that a potential problem may be with rental cars, and where malicious agents could install tracking software on the vehicles, and snoop on personal communications.

Volkswagen, Audi …

Well the genie is out-of-the-bottle after being suppressed for two years. The recent case of The Megamos key fob vulnerability brings to the forefront the battle between car manufacturers and security testers. While some, such as Facebook, Google and Microsoft, reward the security testers, others such as Fiat Crysler, Starbucks and Volkswagen have branded their work as criminal activity, and who expose their customers to risks [here].

The car industry is perhaps feeling bullied and targeted just now, but its approach is equivalent to sticking your fingers in your ears, and hope that the big bad bully will go away. In the Megamos vulnerability they have relied on the courts to supressed a problem, but increasing it is the regulators, who can impose fines, who will have the control on how their respond in the future. While a bug on your operating system will be fixed by a seamless update, the patching of a vulnerability on a safety-critical device, such as a car, is much more serious, and could cause a risk to life and limb, or at least expose owers to the risk of crime. It is a serious issue, and one which perhaps cannot be handled in traditional ways for taking court actions. Overall the Internet is no respector of national boundaries, and often with little reguard to ruling make in one region of the World.

In the latest case the RFID Megamos Crypto transponder (The Megamos) has been shown to be vulnerable where an intruder just has to listen to two messages sent from the key fob, and the encryption key is cracked. The unit is made by a Swiss manufacturer, and the vulnerability has been known since 2012. The code that exploits the vulnerability has been available on the Internet since 2009, but there has been no recalls or patches for it.

The new vulnerability adds to the growing problem of accesses to vehicles without keys. Last year, in London, it is reported that around 42% of all break-ins were related to accesses without keys. This type of crime is especially focused on high-value cars such as BMWs and Audis.

At present the RollJam device is available on the Internet for £20 and opens many of the well-known brands of cars, along with most garage door openers and disabling some alarm systems (see below). It basically “jams” the wireless signal twice when the user uses their key, and then is able to grab the access code for the car.

Academic freedom v industry interests

The Megamos” is one of the most common immobilizer transponders, used in Volkswagen-related brands including Audi, Porsche, Bentley and Lamborghini, but used in many others vehicles, include Nissan and Volvo.

The researchers — including Roel Verdult (Radboud University, The Netherlands) and Flavoi D Garcia (University of Birmingham, UK) — first discovered it in 2012, and approached the manufacturer, and then told Volkswagen in May 2012. They then planned to present at the USENIX 2013 conference, but were blocked by a UK court injunction, which blocked anyone having anything to do with the publication of the paper. The court reasoned academy freedom against the security of Volkswagen cars, and decided in favour of the car manufacturer. The paper has now been published, though, with one line taken out.

Bad crypto

The vulnerability relates to a proprietary cryptographic methods used by the device, and where the researchers could generate transponder’s 96-bit secret key and start the car within less than half an hour. Overall they just need to listen to the device twice and break the encryption key — a bit like having a password of “password”.

The scope of the patching would be massive, as there is no simple update. At the core is the propriety cryptography method, and which has been shown as being weak. Most systems would use well-defined ones such as AES (Advanced Encryption Standard), which can normally only be broken by brute force.

The list of car vulnerabilities just gets longer

With cars increasingly using computer systems and in connecting to the Internet, they are becoming a soft target for security testers. The level of testing in the past for cars have typically been related to long-term soaks and impact tests, but the car industry must now start to take penetration testing of their computer systems seriously. In the case of the Megamos vulnerability it related to around 216 cars with push button starts [1] (the emboldened makes were tested by the researchers):

What is strange with the Megamos vulnerability is that is a weakness in the implementation and design on the key fob, and not a software bug, which is something which should have been reviewed as part of the due diligence process in evaluating the designs, and in testing. If the design flaw had been found by someone in industry, it may have been published and patched, but the academics involved went through the proper disclosure procedures with the companies involved.

When most companies develop software they take the source code and then compile it to produce an executable program. A problem, though, is that an intruder can often easily reverse the code, and/or find out how it works. Once they know the operation, they can then probe for weaknesses. In this case the researchers used the freely-available IDA Pro package to reverse engineer the code. Unfortunately, very little can be kept as a secret now with hardware and its associated firmware.

Ford

In general most of the vulnerabilities are caused by software bugs, such as for the Ford C-MAX. In the end Ford has recalled 433,000 2015 Focus, C-MAX and Escape vehicles because of a software bug where drivers cannot switch off their engine, even when they take their ignition key out:

BMW

Recently, too, a security researcher showed how BMW cars could be controlled by sending commands that told the cars to open their doors and lower their windows. Overall BMW had to issue a security patch for over two million vehicles, including for BMW, Mini and Rolls-Royce [here].

So how safe is your new BMW? Yes. It has been crash tested, but what about it’s computer security? Well Keen Security Lab [here] have just found 14 vulnerabilities within BMWs (Series 3, 5 and 7). For this they analysed main three main remote attack vectors (Figure 1):

  • Infotainment System (also known as the Head Unit). See Figure 2.
  • Telematics Control Unit.
  • Central Gateway Module.

These systems integrate with the local bus systems (USB, CAN Bus — OBD-II — and Ethernet):

Figure 1: Bus connectivity

Figure 2: Infotainment System

They also found that the cars were susceptible to a local attack through the USB or OBD-II interface and where an intruder could obtain a root shell.

With the Infotainment System they found that the cars communicate with a remote system through the cellular network, and communications with the main system and the remote server go through a Telematics Control Unit:

USB vulnerability

The team discovered that specific USB chipsets allowed an intruder to setup an “Ethernet over USB” connection with the NBT Head Unit (Infortainment System) as root access, and could thus scan the system for open ports:

This showed that there are many exposed ports which could be connected to. Once connected it can be seen that they had root access and can thus run things with full rights, and also access the two connected networks (hu-intel and hu-jacinto):

OBD-II vulnerability

In another hack, the team found that they could connect to the E-NET network (which is an Ethernet connected network) and which connects to the OBD-II interface. You will typically find your OBD-II interface under the steering wheel and the connector will look something like this:

With E-NET, a vehicle can be remotely diagnosed for faults, and where an engineer can remotely connect to the Central Gateway. The team found — after reverse engineering the protocols used between the Central Gateway and the NBT — that they could bypass authentication and gain root access to the hu-intel system:

Bluetooth vulnerability

The team then found — by reverse engineering — that a third-party Bluetooth stack had been used, and that it was possible to send a malformed package that caused a memory corruption in the Bluetooth stack:

With this they could simply pair a device with the Infotainment System and then crash the stack and then pair without a PIN code.

ConnectedDrive vulnerability

BMW ConnectedDrive service supports the connectivity to remote Internet-based services, suc has for traffic information, weather and news. This is delivered through a browser named “DevCtrlBrowser_Bon” and which runs in the NBT:

The team were then able to simulate a connection to the ConnectedDrive service, and then probed for bugs in the browser. With this they found that could create a memory corruption, and run remote code with browser privileges.

CVE descriptions

Several of the vulnerabilities already have CVE numbers (the descriptions have been taken directly from the NIST National Vulnerability Database description):

  • CVE-2018–9322. The Head Unit HU_NBT (aka Infotainment) component on BMW i Series, BMW X Series, BMW 3 Series, BMW 5 Series, and BMW 7 Series vehicles produced in 2012 through 2018 allows local attacks involving the USB or OBD-II interface. An attacker can bypass the code-signing protection mechanism for firmware updates, and consequently obtain a root shell.
  • CVE-2018–9320. The Head Unit HU_NBT (aka Infotainment) component on BMW i Series, BMW X Series, BMW 3 Series, BMW 5 Series, and BMW 7 Series vehicles produced in 2012 through 2018 allows a local attack when a USB device is plugged in.
  • CVE-2018–9312. The Head Unit HU_NBT (aka Infotainment) component on BMW i Series, BMW X Series, BMW 3 Series, BMW 5 Series, and BMW 7 Series vehicles produced in 2012 through 2018 allows a local attack when a USB device is plugged in.
  • CVE-2018–9313. The Head Unit HU_NBT (aka Infotainment) component on BMW i Series, BMW X Series, BMW 3 Series, BMW 5 Series, and BMW 7 Series vehicles produced in 2012 through 2018 allows a remote attack via Bluetooth when in pairing mode, leading to a Head Unit reboot.
  • CVE-2018–9314. The Head Unit HU_NBT (aka Infotainment) component on BMW i Series, BMW X Series, BMW 3 Series, BMW 5 Series, and BMW 7 Series vehicles produced in 2012 through 2018 allows an attack by an attacker who has direct physical access.
  • CVE-2018–9311. The Telematics Control Unit (aka Telematic Communication Box or TCB), when present on BMW vehicles produced in 2012 through 2018, allows a remote attack via a cellular network.
  • CVE-2018–9318. The Telematics Control Unit (aka Telematic Communication Box or TCB), when present on BMW vehicles produced in 2012 through 2018, allows a remote attack via a cellular network.

Conclusions

These days cars are sold not just on perform, but on their entertainment system and their interconnectivity. So we hope that car manufacturers know that there are some bad people out their who want to do bad things. The concept of patching a car with a USB is not a thing that most people would want to do, and we thus need to be show that cars are secure by design.