Car hacking is one of the hot security topics right now. This post looks at one IoT device for cars and what it could mean for security: Trainer for economic driving, electronic logbook, gas station finder. Just a few of the many more features provided by the PACE Kit – A small device connected to the OBD interface of your car, collecting various data about your style of driving and the state of the car, processed and presented with the help of your smartphone. A lot of potentially sensitive data collected and sufficient reason for us to check on the security of the PACE.

Inadequately protected application supports reverse-engineering

As with any other product tested so far the main security level depends crucially on the security of the corresponding application – The PACE Kit is no exception.

The application (tested version 1.0.1) however is in this case pretty much unprotected as there is no protection on source code level whatsoever. As you can see on the screenshot below showing an excerpt from the class diagram, no obfuscation is implemented (all class and function names not obscured) and therefore the whole source code is open to reverse engineering by even the lowest skilled attackers. With the help of the freely available Apktool (https://ibotpeaches.github.io/Apktool/) and one of the various JAVA-Decompilers it is rather painless to decode and decompile the .apk and thereby receive an excellent representation of the original source code.

Analysing the so obtained source code is quite simple and essential security functions are easily found.

First things that attract attention are lots and lots of debug code, excessive logging and even more logging which can be activated with a few changes to the code. Yes, the app is still in BETA stadium but as the release version will not change 100 percent of its functionality, revealing so much information at this point might be problematic. So it is not really surprising that essential functionality is quite easily identified and analysed. For example, we were able to find a complete list of all Bluetooth services and characteristics running on the PACE Dongle along with their function and UUID identifier. The following image shows an excerpt from the decompiled source code illustrating the finding.

With this list, it is extremely straightforward to search the code for any usage of a certain characteristic or service. Along with the information given by the unobscured identifiers an attacker can easily reconstruct the whole Bluetooth communication protocol of the PACE Dongle and App, including the authentication process.

When examining this authentication process, i.e. the activation process, a potential attacker can learn that a challenge response protocol is used to perform the authentication. He also learns that the challenge sent by the device is unique to it but dependent from the device’s serial, which in this case is identical to the device’s MAC address. On app side the response is calculated with a static algorithm using the challenge from the device and the serial-dependent so called CRAM key, fetched from the server (*Phew*). The whole process is completely reconstructable and (more importantly) potentially executable by an attacker. In our test we did not explicitly try to break the authentication process nor to perform it with a yet unknown device without using the original app, but we are pretty confident that it is possible.

Another critical information we were able to extract from the source code is an essential part of the overall security concept – the client certificate. Although the usage of a client certificate is exemplary and not common yet for Android Apps, the exposition of it when used is almost worse than using none: A possible certificate pinning used on server side is rendered useless when the client certificate cannot longer be trusted and a Man-in-the-middle is no longer detectable on server side. The fact that the client certificate was hard-coded into the app also means that the same client certificate is used for all copies and therefore all users.

The client certificate itself was found as a String array within the code, in fact encrypted but unfortunately along with the corresponding password. This way we were able to restore the JAVA keystore from it and eventually export private key und certificate information with the help of the free tool portecle. The following images show an excerpt (actually almost 100 percent) of the simple class with which we viewed and restored the keystore and the extraction of the private key and certificate info with portecle (private key is not revealed).

Online-Communication

Apart from the leaked client certificate the online communication is actually quite solid: All connections are sufficiently secured with TLS 1.2 and an adequate Cipher Suite is used to encrypt the communication (see the following image). Not all connections are secured with SSL-Pinning but at least a trusted certificated needs to be used at all times to make the server accept the connection.

With our own root certificate installed on the test smartphone we were able to spy into almost all connections established. In this way we could eavesdrop user login, car information (including VIN, i.e. vehicle identification number), logs and so on. The following images show excerpts from mitmproxy and the information gathered with a Man-in-the-middle-attack.

Although we must admit that an attack with a custom root certificate on the user smartphone on Android is not very likely (as it is not trivial to perform at all), it nevertheless represents a theoretical vulnerability at the very least and definitely points out potential for improvement.

Verdict

All in all the PACE Kit is actually one of the more secure devices we tested over the years. Yes there are a few problems (some of quite major nature) but none of them cannot be fixed with relative ease. Furthermore one has to acknowledge that the tested version is still in BETA stadium and therefore has the right to come with a whole bunch of potential bugs. But as we already mentioned: Revealing so much information with this debug version might be extremely problematic for the release version when it finally hits the store. For the functionality there are not all features implemented yet (such as the “find-my-car” feature) and some cannot be working as intended (the app told us our average fuel consumption on 100km was 1.7l – doubtful at the least), so there is definitely a chance for us coming back to testing these once they are released in the final version.