Beemer, Open Thyself! – Security vulnerabilities in BMW's ConnectedDrive

Inhaltsverzeichnis

• Deutsche Version dieses Artikels
  

Cars with built-in modems are sending data to their manufacturers – German motorist's club ADAC wanted to know what exactly gets sent. c't connected ADAC with a specialist who analysed the data transmissions, using the example of BMW's ConnectedDrive technology. He discovered security vulnerabilities that even allow unauthorised attackers to open the vehicles.

The Internet of Things does not stop at the threshold to the garage: More and more cars include a cellular modem with a SIM card by default. Depending on the manufacturer, these modems do different things: they might provide Internet access to the passengers, they could send telemetry data or traffic information to the manufacturer or they can alert the emergency services in case of a crash. With some brands, a mobile app allows the owner to control some functions of the vehicle through a mobile app. This might include the auxiliary heating system or, with electric cars, the charging of the main battery. These apps even allow for remote locking and unlocking of the car doors.

One of the leading manufacturers in this area is BMW. Its ConnectedDrive technology has been on the market for several years now. Like c't, ADAC is interested in the privacy and consumer protection implications of the data transmitted in the use of this system. They asked me to investigate this in detail, with surprising results: I discovered a number of serious vulnerabilities, even though my focus wasn't even on security initially.

For my research, ADAC provided me with several BMW cars with ConnectedDrive; among them a BMW 320d Touring. I wasn't given any special information from the manufacturer and had to work with what is publicly available on the Internet.

To gain a first impression, I looked at the control unit for ConnectedDrive. There are several variations of this so-called Combox. This device, among other things, is responsible for the multimedia functions in the car. Things like playing back music files from a USB stick or pairing a mobile phone with the Bluetooth handsfree unit built into the car. This device has been included in various BMW models since 2010.

The Combox's CPU is an SH-4A, a powerful 32-bit RISC processor from Renesas. Mobile communication is facilitated by a GSM/GPRS/EDGE modem from Cinterion (formerly Siemens). The device also uses a V850ES micro controller, also manufactured by Renesas. Presumably, the V850ES was selected for its low power consumption which enables the modem to keep receiving when the car has been parked and the engine isn't running. The SH-4A's larger power demands would drain the battery too quickly.

Disassembled

To start off, I removed the Combox from the car, connected it to an AC adapter and activated the emergency function that is usually triggered by a button inside the cockpit. I figured out the pins for power lines and the emergency button on the connector by looking at the modules on the mainboard. Research on the Internet provides another way: by downloading diagnosis software intended for BMW service garages which documents the pin configuration. To log the Combox's mobile network traffic, I set up a test environment using a base station that supports OpenBSC and thus emulates a cellular network.

When the emergency button is pressed, the Combox sends a text message and then starts a voice call. The text message is scrambled and does not reveal any recognisable patterns whatsoever. In each case where the emergency mode is triggered, sent data looks different – this suggests the data is encrypted.

To figure out where exactly the data gets encrypted, I logged data traffic between the cellular modem and the V850ES micro controller. This traffic flows over a serial connection. To learn the allocation of the modem connectors, I consulted specifications that can be found on the Internet. Since I could not find the data that gets sent with the emergency text message in the data I logged on the connection, I assumed that the message gets created and encrypted within the modem itself. This is plausible; the cellular modem used can be extended to provide such functionality.

Desoldered

I had to get at the firmware of the modem. The modem unit did not include standardised test headers (Joint Test Action Group, JTAG) that could have been used to obtain the firmware. This meant I had to desolder the flash module of the modem and use an adapter board to read the firmware. That's no trivial task, as the chip is packaged using a BGA – after desoldering, it has to be reballed. There are, however, service providers that offer to take care of this.

To analyse the firmware, the flash chip on the adapter board was connected to an STM32 evaluation board with enough I/O pins and a matching I/O voltage of 1.8 Volts. The contents of the flash memory were extracted to a PC over the serial connector of the evaluation board, using a few lines of C code. To analyse the firmware code, I used the tool IDA Pro from Hex-Rays. It is suited to inspect assembler code and supports the ARM CPU of the modem.

Using IDA Pro, I was quickly able to identify several encryption and hashing algorithms in the firmware. This is possible due to the fact that popular crypto algorithms use certain tables and constants that can be searched for automatically. Based on my findings I was able to discover other parts of the code which use the same encryption and hashing algorithms.

Looking for the Keys

Were do the crypto keys come from? Being an optimist, I initially assumed unique keys were generated for each car, stored in the V850ES micro controller and sent from there to the cellular modem. Since looking for the keys in this case would have been a lot of work, I decided to keep analysing the protocol for the emergency calls instead. Certain strings in the firmware quickly indicated that it seemed to be using something based on NGTP (Next Generation Telematics Protocol). That wasn't surprising, seeing as BMW is one of the main backers of NGTP.

To define its communication protocol, NGTP uses the standardised notation ASN.1 (Abstract Syntax Notation One). The firmware shows that syntax was created with the open source compiler asn1c. Looking at the structure of the firmware with knowledge of how asn1c works allowed me to reconstruct the ASN.1 syntax that is used in the protocol relatively closely. This step was needed, because NGTP only makes suggestions on how a protocol is built, it does not specify actual implementation details.

Following this, I went on the hunt for the crypto keys again. The NGTP protocol includes functions to update keys which again led me to believe that keys had to be stored somewhere. For a long time, my search was in vain. In a last ditch effort, I analysed a conspicuously random looking block of data included in the firmware. I tried to use some of this data as a key to decrypt the emergency text message I had logged – after some trial and error, it actually worked.

What I had discovered seemed weird to me. Would they really be using the same key material for all cars? On the other hand, so far I had only looked at the emergency text messages. For that use case, having the same key in every car would be relatively harmless.

I had discovered that DES (with a 56-bit key) or AES128 (with a 128-bit key) was used for the encryption. To sign the messages, three methods were implemented: DES CBC-MAC, HMAC-SHA1 and HMAC-SHA256. The algorithm used is indicated in the header of the message. To sign and encrypt data, 16 pairs of two 64-bit keys each are used. Which key pair is used is also noted in the header of the message.

It's not clear why BMW is using DES encryption as this algorithm has been considered broken for some time. It's block length is shorter compared to several other crypto algorithms, leading to shorter messages, but the same is true for 3DES (Triple-DES) and that algorithm is at least still considered mostly secure.

Reassembled

After my successful attempt to decrypt and decode the emergency text message, I turned my attention back to the car itself. I wanted to figure out if its communication was better protected when it came to security-related functions. For this purpose, I started to investigate the remote unlocking feature.

To use this feature, the owner of the car first has to create an account on the BMW website and enable Remote Services. The iOS and Android app My BMW Remote can then be used to open the driver-side door. To understand how this works in detail, I had to once again log the data traffic to and from the car. This had to start with a text message since a data connection wouldn't otherwise be possible to a parked car with its engine switched off.

The easiest way to get at this text message was to look at the serial connection between the cellular modem and the V850ES micro controller in the Combox. After telling the app to unlock the car door, I did indeed find a text message in the logged data. This message seems to have debug character since it is actually being processed by the cellular modem.

Having knowledge of the crypto algorithms and key table, I could easily decode and analyse the message. To see how the car would react, I then sent it a copy of the text message using my emulated cellular network (replay attack).

After the vehicle had received the text message, it took approximately one minute for the systems connected to the main processing unit to boot up. Following this, the Combox initiated a data connection to the BMW backend servers via the cellular network and tried to access data there. Since it did not receive any data, the connection was terminated and nothing further happened. This meant the text message wasn't enough to open the doors and the system required further data from the backend (see diagram).

The surprising thing about what had just happened was, that the cellular connection between the vehicle and the BMW servers could be logged without problems in my emulated network. The car had sent a simple HTTP Get request; there was no encryption with SSL or TLS in transit.

To figure out which data the car expected from the BMW backend, I simply had to trigger the unlock sequence from the app before starting my replay attack with the text message. That way, the server would store the needed data for my car. Shortly afterwards, the car door opened.

This new data could be encrypted and analysed using the same methods as before. The protocol was once again NGTP, but this time different signing and encryption methods where used: AES128 instead of DES and HMAC-SHA256 instead of DES CBC-MAC. The key table was the same.

Break-in

I now had sufficient knowledge to emulate all components of the unlocking feature. I was able to forge data that would allow me to open the car. All I needed was my base station and a laptop that would send the spoofed text message and then would masquerade as the BMW backend server.

The question was if the keys that I'd extracted would actually work with other cars. My tests with several other BMWs reassured me they would. In testing this, I learned some additional things. If the Remote Services are deactivated in a vehicle with ConnectedDrive, the remote opening of the doors would not work. It is, however, possible to activate Remote Services using the emulated cellular network.

This works similarly to the previous attack. The car gets sent a text message instructing it to load new configuration data from the BMW servers. This data gets loaded via a simple HTTP Get request and is formatted as unencrypted XML that is trivial to understand. The configuration file is not protected against manipulation at all, something that could have been easily solved by signing the data. This means it was easy, using my emulated network, to first activate Remote Services and then open the doors.

At least the messages sent to a vehicle are checked with regard to which car they are addressed to. This check is done with a VIN (Vehicle Identification Number) included in the message. If the VIN does not match the car in question, it will not execute the command it is sent. This is no hurdle to a potential attacker, though, since the Combox is very helpful in this regard: If it does not receive a valid VIN, it actually sends back an error message that contains the correct VIN in order to identify the sender of the message.

In my ongoing research I also looked at very recent BMW models. In some of them, the Combox has been replaced by other control devices. Multimedia and handsfree functions have been integrated in the so-called Headunit and cellular communication has been moved to a device called the TCB (Telematic Communication Box) which now supports UMTS in addition to GPRS/EDGE connectivity. The TCB ignores messages that do not include the correct VIN. Since it does not answer either, the correct VIN can't be easily figured out as is the case with the Combox. Communication still uses the known keys for all vehicles, however.

In practice

What would remote unlocking via an emulated cellular network actually look like in practice? The required equipment fits in a briefcase or a backpack. The range of the emulated network can reach more than a hundred metres, even in a city centre. This so-called IMSI catcher works by having a stronger signal than the actual mobile networks in the area, causing mobile phones to prefer the fake network. The IMSI catcher does not need to know the phone number of the target vehicle. It uses the TMSI (Temporary Subscriber Identity) instead, which it assigns to a mobile device once it enters its network. If the target car uses the TCB module, an attacker has to jam existing UMTS signals in the area to force the control unit to fall back to GSM.

Since not only cars with ConnectedDrive are likely to join the fake network, it's useful to filter connected devices by looking at the IMEI number – the unique serial number assigned to all mobile devices and cellular modems. The first eight characters of this number identify the device (Type Allocation Code, TAC). This method also allows an attacker to differentiate between the Combox and a TCB.

Knowing that a certain car includes a Combox, an attacker can figure out the VIN as described and then go about activating Remote Services and opening the driver-side door. If a vehicle includes a TCB, the VIN has to be sourced in a different way. Depending on the country the car will be sold in, the VIN has to be visible through the windscreen or will be present on a plaque in the door frame and can thus be photographed when someone exits the car. Unlocking the doors does not leave any traces and is completely inconspicuous even on crowded streets.

Conclusion

At the time of my initial investigation, ConnectedDrive included six security vulnerabilities:

• BMW uses the same symmetric keys in all vehicles.
• Some services do not encrypt messages in transit between the car and the BMW backend.
• The ConnectedDrive configuration data isn't tanper-proof.
• The Combox discloses the VIN via NGTP error messages.
• NGTP data sent via text messages is encrypted with the insecure DES method.
• The Combox does not implement protection to guard against replay attacks.

These problems could have been avoided easily. For example: Facilities to implement encryption in transit are available, but are only used by some ConnectedDrive services. Additionally, the manufacturer individualises the control systems in question by programming in the VIN, so it should be possible to also program unique keys for every vehicle.

In an interview with c't a year ago, Dr. Klaus Büttner of the research and development arm of BMW said that security and authorised access to a vehicle have the highest priority when it comes to the company's online services. According to Büttner, BMW routes all services over the company's own secured backend. Additionally, the cars only process authorised commands that are on a pre-determined list of actions.

In principle, this is all correct, but the devil is in the details. According to BMW, the security vulnerabilities have now been closed. Still, what are the options for car owners who are nervous despite the assurances from the manufacturer? Sadly, ConnectedDrive can't simply be switched off – there is no equivalent to the Airplane Mode offered by mobile phones.

To permanently deactivate ConnectedDrive, a written request and a visit to a service garage is required. A self-help measure would be to disconnect the Combox or TCB from the antenna. Depending on the car model, this is easy to do as the control unit can be found under the luggage compartment floor. Howeverm this also deactivates the automatic emergency calls.

Owners who do not want to go that far simply have to hope that the manufacturers take enough care when implementing the details of their online services. ADAC is demanding that computers that are included in cars have state of the art protection against manipulation and illegal access. This protection, says the demand, should follow the same standards that have become the norm in other industries. Additionally, these security measures should be verified by a neutral third party – as part of the Common Criteria Certification of the Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) in Bonn, for example.

Affected Cars and What to Do About It

As a consumer watchdog, ADAC has informed BMW about the results of this investigation. The manufacturer has confirmed the security vulnerabilities. According to the company, all cars that include ConnectedDrive and were manufactured by BMW, Mini and Rolls Royce between March 2010 and 8 December 2014 are affected. In Germany, this includes around 423,000 vehicles; worldwide, this number rises to 2.2 million cars. ADAC has compiled a list with the over 50 models in question.

The disclosure of the vulnerabilities was coordinated with BMW to give the company enough time to secure their services. A configuration change to enable encryption in transit for ConnectedDrive data has now been triggered via cellular connection. According to BMW, the certificate of the server is now being checked as part of this.

Car owners can not be sure if their car has received this change, however. To find out, owners can contact a BMW hotline at 0 89 / 1 25 01 60 10. This is especially applicable to cars that have been parked in underground car parks, other places without mobile reception or that had their starter batteries disconnected over the last few months. Owners can also trigger the change manually by selecting Update Services in the car's main menu. (fab)