A Remote Attack on the Bosch Drivelog Connector Dongle

Background

In this blog post, I discuss the vulnerabilities of the Bosch Drivelog Connector OBD-II dongle found by the PlaxidityX Research Team. The vulnerabilities allowed us to stop the engine of a moving vehicle using the Drivelog platform.

On February 20th, 2017, in accordance with Argus’ responsible disclosure policy, upon uncovering the vulnerabilities we informed Bosch of our findings. On February 21st, 2017, Bosch’s Product Security Incident Response Team (PSIRT) contacted PlaxidityX and began addressing the issue.

In summary, the following two vulnerabilities were found:

• An information leak in the authentication process between the Drivelog Connector Dongle and the Drivelog Connect smart phone application.
• Security holes in the message filter in the Drivelog Connector dongle.

The information leak allowed us to quickly brute-force the secret PIN offline and connect to the dongle via Bluetooth. Once connected to the dongle, security holes in the message filter of the dongle enabled us to inject malicious messages into the vehicle CAN bus.

In our research, we were able to turn off the engine of a moving car while within Bluetooth range. As troubling as that is, in a more general sense, since we can use the dongle to inject malicious messages into the CAN bus, we may have been able to manipulate other ECUs on the network. If an attacker were to implement this attack method in the wild, we estimate that he could cause physical effects on most vehicles on the road today.

This post describes the basic setup and capabilities of the Drivelog dongle and its accompanying mobile app. We describe the research in the order in which it was carried out. That is, first we describe how we uncovered potential security holes in the message filter and then we describe how we uncovered the information leak in the authentication process between the dongle and the app. We then describe a complete attack flow.

Connected Devices – Holy Grail for Attackers

In recent years, cyber security researchers have shown how IoT (internet of things) devices can be used by hackers. For example, Mirai software creates a botnet out of everyday routers and remote cameras while for years poorly configured smart fridges have become part of widespread spamming campaigns. It takes no stretch of the imagination to see car hacking as the next target of attack and whether true or not, car hacking gained more attention when it was allegedly cited as part of the CIA toolkit.

Moreover, cyber attacks on cars have been making the headlines over the past few years with almost all major brands becoming a victim of a hack. The most widely publicized hack to date took place in the summer of 2015 when Charlie Miller and Chris Valasek conducted the Jeep hack whose grave safety implications led to the first cyber recall of over 1.4 million vehicles.

About the Bosch Drivelog Connector Dongle

Like other IoT devices the Bosch Drivelog service promises to provide drivers with features that simply make aspects of life easier, in this case, car maintenance. Connecting to the car’s OBDII port, the Bosch Drivelog Connector monitors vehicle health and, in case service is needed, directs the driver to one of the workshops or dealerships in the Drivelog program. Two Drivelog dongle models are available, for private and commercial vehicles, the only difference being the number of CAN buses to which the dongle connects.
In order to communicate with the dongle, we downloaded the Drivelog Connect app, which connects to the dongle via Bluetooth and enables the driver to review vehicle health, track trip data and more. The Drivelog Connect app is available for both Android and iPhone. Due to the open nature of the Android OS, we focused on the Android version during our research.

Getting started – Emulating a Car in the Lab

The first thing we had to do was get the Drivelog dongle and mobile app to work in a lab without actually being connected to a running car. Therefore, our first order of business was to recreate a car environment in order to fool the dongle into working outside an actual car.

To do this, we observed the data the dongle required to function by recording and analyzing the CAN bus traffic of an actual car while the dongle was connected. Because the Drivelog Dongle supports a wide variety of car makes and models, we assumed it would only use ODBII PIDs – a small subset of standardized diagnostic messages widely supported by car OEMs which are very easy to identify within (otherwise OEM-specific) CAN bus traffic.

The basic idea was simple: First, connect the dongle to a running car, identify the PID requests sent by the dongle and record the responses from the car; next, we needed to simulate a running vehicle in a lab – when the dongle sent its requests, we replayed the recorded responses from the car, which caused the dongle to behave normally.

After reviewing all the PID messages sent over the CAN bus, we constructed a request-response dictionary that allowed us to emulate the normal in-vehicle messages of a car. With the dongle working in a lab environment, we then turned our attention to the Android application and after decompiling the Java binaries, we were able to start our review of the source code.

Dongle and App Overview

Reviewing the decompiled Java binaries, we learned several things. Although a large portion of the sources had all of their symbols stripped and replaced with sequential alphabet names (e.g., a(), b(), c()), we were able to find a large number of textual debug log prints (pictured below) that made understanding the code easier. Further into our review, we found that the debug logs were disabled so despite being present in the code, the debug messages aren’t written into the Android system messages log. As functioning logs are very useful for reverse engineering, we disassembled the application into Smali, an easy-on-the-eyes Java bytecode representation, and patched the app to re-enable these logs.

We noticed that the Drivelog application, among other features, can update the dongle’s firmware. In fact, once a firmware update is available, the Drivelog app will not allow you to connect to the dongle until the firmware update process is complete – a clever way to ensure updates are quickly implemented.

Getting our hands on the dongle’s firmware would have allowed us to audit its code and potentially gain remote code execution capabilities. Unfortunately, after observing the application’s behavior and how it communicates with the dongle, we learned that the firmware updates are encrypted in-transit and only decrypted by the dongle itself. This meant that obtaining the firmware, while still potentially possible, may have required significant effort, which led us to look for other potential attack vectors.

Uncovering Security Holes in the Message Filter

Now knowledgeable of the encryption that secures the firmware, we decided to focus on an attack vector which would prove less time consuming, for example, a compromised smartphone; we asked ourselves, how much damage could an attacker do with root access to the driver’s phone and the ability to communicate with the dongle through the Drivelog app?

In order to understand the protocol being used we listened in on the Bluetooth communications. We learned that the data passing between the dongle and the app was encrypted (which we confirmed by reviewing the decompiled source code). To get around this, we added another patch to the Android app, which mirrored all the Bluetooth communication on UDP, and enabled us to observe how the app and dongle communicated when the dongle sent CAN bus messages.

The protocol between the app and the dongle, as mirrored by our patches, is textual as follows:

In image 2 above, messages sent by the app are marked as TX while message sent by the dongle to the app are marked as RX. By comparing the Bluetooth and CAN bus messages, we could see that REQ commands are used by the app to request the dongle to send CAN bus messages. The data following a REQ command is precisely the data sent on the CAN bus after it is padded to length 8 (the maximum length for a CAN bus frame).

For example, “REQ 2 1 C” is an engine RPM query (as per the Wikipedia article about OBDII PIDs). The CAN bus message ID transmitted by the dongle is set once per session in the MSET command, which appears to be an initialization command (e.g., in the figure above, the message ID is set to 0x7DF – note the “22 7DF” part of the MSET payload). The MSET settings apply to all the subsequent commands after it (in the figure above, all the REQ commands will send CAN bus messages with ID 0x7DF). The MSET command also sets the CAN bus baud rate, which message IDs to ignore, and other parameters.

Therefore, it appears that the Drivelog app controls, at least somewhat, both the message ID and contents being transmitted by the dongle to the CAN bus.

After reverse-engineering the app-dongle Bluetooth protocol, we added another set of patches to the Drivelog app that allowed us to send arbitrary messages to the dongle by tunneling them over UDP from our desktops to the app. Using this setup, we manually tested the constraints imposed on the dongle by the communications protocol and found two significant things: First, an attacker can control the message ID and use extended message IDs without any limitations; next, we found that the dongle rejects messages that contain invalid values in their second byte (roughly speaking, only 1-10 are allowed). This limitation makes sense if you look at a typical diagnostic request message: the first byte is the ISOTP packet length and the second is the service identifier.

Thus, limiting the possible service identifiers to the small subset above effectively allows the dongle to use only PIDs (and no other type of diagnostic communication). In addition, the dongle pads all messages sent to length 8, so you can’t send messages of any other length to the CAN bus.

Unless an attacker is willing to use OEM-specific messages, which may not conform to any known structure, allowing only specific diagnostic service IDs (i.e., in fact, only PIDs) severely restricts an attacker’s options.

Getting Around the Service ID Limitation

This brings us to the first vulnerability. As explained above, while an attacker can’t send diagnostic messages with invalid service IDs, he/she can use OEM-specific messages that pass the filter in order to have a physical effect on the car.

For instance, Charlie Miller and Chris Valasek show in their paper “Adventures in Automotive Networks and Control Units” how to detect OEM-specific messages by recording and then replaying CAN traffic, iteratively refining the recording until a small set of messages responsible for a specific feature are discovered. Given the large quantity of car makes and models supported by the Drivelog platform, it’s highly unlikely that the dongle’s message filter, designed to prevent malicious diagnostics, would also prevent all other damaging CAN messages an attacker might try to send.

An alternative method employed by PlaxidityX is fuzzing – in order to observe any and all effects on a car by automatically sending CAN messages to a car based on expected patterns. In our experience, fuzzing CAN bus messages can cripple or permanently damage cars, which makes such a research method potentially costly. However, an attacker can skip the expensive research and simply send random messages as a form of attack, expecting (and rightfully so) that at least some of them will cause the car and its passengers lasting damage.

To test our understanding of the dongle message filter, we attempted to perform such an attack using one of the test cars owned by Argus. During the test, we successfully exploited the vulnerability in the Drivelog dongle to send a CAN bus message that shut down the car’s engine while the car was in motion. Depending on the make and model of the car in question, there may be many more messages that can be used for an attack.

To summarize the first vulnerability, the security holes in the message filter allows an attacker with root privileges on the driver’s phone to send malicious CAN messages outside of the scope a small subset of diagnostic messages (i.e., OBDII PIDs) which can potentially have physical effects on the vehicle.

The second vulnerability we discovered amplifies the effect of the first and eliminates the need for a compromised phone.

Information Leak in the Authentication Process

In the previous section, we assumed an attacker had access to a compromised phone. Now we set out to explore if there was an easier way to send the dongle commands that will generate CAN messages. In order to duplicate the read and write access we had through the compromised smartphone, we turned our attention to the authentication process between the Drivelog dongle and the Android app.

In terms of user experience, the pairing process between the dongle and the app is simple – the user chooses the dongle from the list of Bluetooth-enabled devices in the area and enters the PIN etched on the dongle when prompted to do so. However, having reviewed the decompiled sources we found the process to be significantly more complicated:

The pairing process includes the following steps:

1. The Android application connects to the dongle using Just-Works Bluetooth and requests the dongle certificate (the dongle’s public key and a signed binary string), which the dongle then sends.
2. The Android application sends the dongle certificate and a PIN obtained from the user to the backend server.
3. The server replies with a pairing certificate that is received by the dongle (via the app).
4. The dongle verifies that the pairing certificate contains a matching PIN to the one stored in it electronically. Upon successful verification, the dongle sends the dongle certificate and nonce to the Android app.
5. Upon receipt of the dongle certificate, the Android app verifies that it contains a matching PIN to the one provided by the user.
6. Upon successful verification of the PIN provided by the user and the PIN contained in the dongle certificate, the Android app signs the dongle’s nonce.
7. Once the dongle nonce is signed, the app sends both the dongle’s nonce and the phone’s nonce to the dongle to which the dongle responds by signing the phone’s nonce and transmitting it back to the app.
8. Once both the dongle and the Android app verify the signature of each nonce respectively, an encrypted channel is set up using the nonces exchanged.

The process outlined above is a high-level overview of what takes place during authentication. However, the actual steps and mechanisms used to perform the authentication involve Elliptic curve Diffie–Hellman anonymous key exchange and XSalsa20 for the encrypted channel as a stream cipher. While interesting, these details are not necessary to understand the vulnerability found.

During step 1 the dongle transmits its certificate, which includes its public key and a signed binary string, which is the signed result of a SHA256 hash calculated on the following strings (concatenated in this order):

1. The dongle’s MAC address
2. The dongle PIN
3. The dongle public key

The result of the hash computed above is signed with a specific private key (held by the dongle); we referred to this above as the “signed binary string”. Skipping over a few less interesting steps, in step 5 of the authentication process, the smartphone application verifies the signed binary string against a matching public key by re-computing the SHA256 hash of the dongle’s MAC address, a user-provided PIN and the dongle’s public key. If the signed hash result matches the signed binary string the dongle is authenticated.

Let’s review the information the attacker has (as opposed to the dongle’s legitimate user):

• Dongle public key (step 1) – since the Bluetooth pairing required to connect to the Drivelog dongle is Just-Works, an attacker can easily pair with it and receive the dongle certificate, which contains the dongle’s public key.
• Likewise, since the attacker paired with the dongle they have the dongle’s MAC address.
• Having previously reverse-engineered the application, the attacker also has the public key it uses to verify the signed SHA256 hash within the dongle certificate.

At this point, if the attacker wanted to check if they guessed a PIN correctly they would need to concatenate the dongle’s MAC address, the attacker’s guess for a PIN and the dongle’s public key, compute the SHA256 of the whole string, and verify its signature against the encrypted binary string passed in the dongle certificate.

This is the point where our alarms went off. Once an attacker connects to the dongle, he/she then has enough information to guess the PIN offline. Further, since brute-forcing is possible offline, the only limiting factor here is the number of possible PINs.

Since, a Drivelog Dongle’s PIN has eight digits, there are 100 million possible PINs. A single verification requires a SHA256 calculation and a public key encryption operation. The calculations can be trivially parallelized – but the reality is, there’s no need: a modern laptop can run 100 million SHA256 computations and encryptions in roughly 30 minutes (according to independent benchmarks for the Ed25519 public-key signature system) using properly optimized software. The time needed can be further reduced by running several brute-forcing servers in parallel.

The impact of such an attack is simple and damning – PINs can be recovered quickly after connecting to the dongle once without the need for any secret knowledge; the dongle certificate leaks enough information about a relatively short secret PIN.

The Complete Attack Flow

At this point we’re ready to combine both vulnerabilities discovered into a single attack: we can quickly brute-force the PIN (information leak in the authentication process) and then use the communications channel to send malicious CAN bus messages (insecure message filter).

To sum things up, the attack flow includes the following steps in sequence:

1. Attacker pairs with the Drivelog dongle and receives the dongle certificate.
2. Attacker brute-forces the dongle PIN in an offline environment.
3. Attacker connects to the dongle.
4. Having completed steps 1 through 3, attacker is able to send malicious CAN bus messages.

If the attacker wishes to create damage, he/she can send random CAN bus messages and would most likely succeed in physically affecting a vehicle.

Final Words

While the focus of this blog is describing the vulnerabilities discovered in the Drivelog Dongle, when it comes to security, the Drivelog platform, including the dongle and mobile app, does a lot of things right.

The dongle does not expose any physical interfaces (e.g., its JTAG is firmly disabled), and the dongle is responsible for decrypting firmware upgrades (i.e., the dongle firmware is not easily accessible to attackers).

Moreover, all communication between the dongle, the Drivelog Connect app and the backend server is encrypted and the system design clearly places a lot of emphasis on cryptographic security.

However, this discovery illustrates the following fundamental principles regarding automotive cyber security:

• Even products designed with security in mind can have vulnerabilities, such as the two vulnerabilities described in this blog. Notice that like many of the vulnerabilities we have encountered in the past while researching automotive components, these two vulnerabilities are derived from errors in the design and are not implementation vulnerabilities.
• Automotive cyber security requires multi-layered solutions. While it is clear that cryptography will play a large role in the future of automotive security it can not be relied upon to protect against all attacks. Generally speaking, preventive measures are required, but experience teaches us that attackers will eventually find a way to bypass them and once they do, detection solutions, like PlaxidityX In-Vehicle Protection, are paramount in order to be able to properly react to the threat and mitigate the attack.
• Once an attack is detected automakers need the tools to understand the attack and the ability to send over the air security updates to the fleet on the road.
• Automakers and suppliers should carry out regular penetration testing of their products and services. These tests should be performed by automotive security experts.

References

1. A remote attack on an aftermarket telematics service (PlaxidityX blog)
2. Adventures in Automotive Networks and Control Units (Charlie Miller & Chris Valasek)
3. Ed25519 benchmarks
4. The Mirai botnet (Wikipedia)
5. OBDII PIDs (Wikipedia)
6. The ISO-TP protocol (Wikipedia)
7. Elliptic-curve Diffie-Hellman (Wikipedia)
8. Salsa20 encryption (Wikipedia)