A closer look at the security of aftermarket OBDII tools

Blog post 2018-03-26 by Josefien Hupkes, intern at Secura

In the past few years, interesting research has taken place regarding automotive security. The broad attack surface of connected cars make this subject very versatile and also gives researchers, as well as attackers, a lot of options. As this subject caught my interest, I decided to do my research internship at Secura and investigate a specific part of the attack surface of a connected car.

OBDII and CAN Bus

One of the attack vectors in particular, the On Board Diagnostics (OBDII) port, seemed like a particularly interesting subject for further research. This port was originally meant to be a useful tool for garages to measure diagnostic information about a car. Nowadays, the port isn't just being used for its original purpose. Due to the OBDII port being available for small plug-in devices, the aftermarket automotive industry saw an opportunity in using the OBDII port for other purposes than its original one. Functionalities range from increasing or decreasing insurance cost to fleet management to even having a social purpose for sharing your driving behavior with your friends. Products range from cheap Chinese diagnostics scanners to more 'high-end' devices that can be used for multiple purposes at a time.

As was already known, the OBDII port (and so these dongles as well) is connected to a car's central control unit, the CAN Bus. The CAN protocol has already proven not to be implemented with sufficient security measures. When connected to a CAN bus in a car, it is possible to sniff the messages from every ECU connected to the CAN Bus in question. When sniffed messages are reverse engineered, the knowledge gained by reversing can be used to send messages to the CAN bus as well.

The presence of the OBDII port poses a risk for 'easy access' to the car's ECUs and the possibility to use an OBDII dongle, if any vulnerabilities are found, as a means to compromise a car's  CAN Bus.

Automotive Security Research

For my research, I took a few OBDII dongles to investigate their attack surface and identify vulnerabilities and insufficient security features.

dongle in On Board Diagnostics (OBDII) port

Most of the dongles used Bluetooth as their means to connect to a mobile phone and display all necessary data in a mobile application. Another recurring theme in the dongles was the usage of GSM/GPRS to send data from the dongle to the backend. Eventually, the focus was mainly on the usage of Bluetooth and GSM/GPRS, reverse engineering the dongles' PCBs  and obtaining the firmware of the devices, but the mobile applications and web backends were investigated as well. The image shows how the OBDII dongle is plugged into the diagnostics port.

Results concerning hardware and firmware

A clear conclusion of the investigation was that every dongle had multiple security flaws. Some of the flaws were hardware specific, such as leaving components and test pads marked on their PCB so reverse engineering was not a very difficult task and UART pads could be found easily. Also, for some dongles firmware was obtained fairly easily, even one of them has been observed to use the insecure FTP protocol to push firmware updates to the dongle. When FTP is used for firmware updates, firmware can be acquired by just sniffing the update with Wireshark and extracting the firmware file. The analysis of a firmware update also lead to the discovery of hardcoded credentials, since the same were used in every (automated) firmware update.

Though the FTP firmware update flaw has been discovered, it has also been observed that some dongles DID take measures to prevent reverse engineering and firmware extraction. One of the dongles had an easy-access SPI flash chip which could be read with a Bus Pirate and a few test probes attached to the right pins. Even though the chip could be accessed and read easily, the chip appeared to be One Time Programmable to prevent extraction. Other dongles had epoxy layers around the microcontroller, microcontrollers that were glued (in other words: impossible to desolder) or had an absence of test pads for possible JTAG or UART access. Customized firmware has also observed to prevent reverse engineering.

Results concerning Bluetooth connections

In addition to the dongle specific results, the Bluetooth analysis has led to an interesting result that is applicable for all Bluetooth dongles investigated. It turns out that it is very easy to eavesdrop Bluetooth traffic of the dongles when the eavesdropper is in the Bluetooth range of ~ 10 meters. The dongles all have an implemented an insecure pairing mechanism. All dongles used 'Just Works', AKA tapping the Bluetooth name to pair, or a really simple hardcoded PIN code like '0000' or '1234'.

When pairing is set up with a Bluetooth dongle, an attacker with an Android developer option called "Bluetooth HCI snoop log" can store all Bluetooth traffic from paired Bluetooth devices in a log file. This log file can then be opened in Wireshark to view the captured Bluetooth traffic. In this way, an Ubertooth is not necessarily needed to capture the traffic. It is even possible to pair to the dongle and read data when the car's engine is switched off, since only the battery is needed to power the dongle.

Also, since all dongles investigated have the Bluetooth profile 'Serial Port', it is possible to send serial commands to the dongles. To do this, the dongle only needs to be paired to the smartphone or laptop that sends the commands, further authentication is not required. Malicious usage of commands that access the CAN Bus can lead to compromise of the CAN Bus.

Additional findings and conclusion

While the findings mentioned above are considered the most important, the investigation also lead to the discovery of hardcoded keys, the discovery of a phone number using the GPRS interceptor mentioned in the previous blog post 'Practical GPRS MitM attack- mobile setup with YateBTS' and a website that sends sensitive information over the unencrypted HTTP protocol.

After all, the main conclusion is that most IoT devices still aren't flawless and security isn't the main focus. Though, it did stand out that most security measures that were taken were taken in the way of customizing as much as possible. Regardless of this, the findings of the research have shown that OBDII dongles pose multiple risks to their users. As observed, the dongles and the corresponding back-end process sensitive information and, in some cases, don't encrypt the traffic in which credentials and information about the car, driving behavior and even driving routes are processed. The ease of eavesdropping on this is also worrisome. Finally, the firmware update process of some dongles can also lead to compromise.

Get the latest insights on digital security. Subscribe to the periodical Secura newsletter

Other blog posts:

How broken is WPA2 really and what to do?

A bad week for crypto: following KRACK, now there's ROCA

 

@Secura 2018
Webdesign Studio HB / webdevelopment Medusa