OBD Case Study: Gone in 6 Seconds

History

Prior to the 1980s, vehicle diagnostics were more hands-on, and on-board computers were not fully developed. Identifying a car’s trouble meant testing fuses, relays, and opening up components and performing visual inspections, or using timing lights. During the 1980s and early 1990s, cars became more computer-controlled, such as controlling engine idle, vehicle speed and so on. Vehicle manufacturers also were not using a standard for communicating with on-board computers, also making diagnostics more difficult. A standard was developed (ODB-II, or ODB2) and going forward, diagnostics became more streamlined.

The ODB-II standard specifies the type of diagnostic connector, its pin-out, the electrical signalling protocols available, and the messaging format. It is used to connect to your vehicle’s on-board system and components such as ECU unit. Until recent years, diagnostic interface scan tools were expensive. Today, you can easily purchase ODB-II adapters and dongles that are Bluetooth enabled.

There is a growing trend to turn the vehicles into smart cars, from tech savvy gadget-geeks that try new technologies, to auto service vendors such auto insurance companies that provide monitoring systems to analyze your driving behaviors.

Inspired by the Chrysler hacking event, we study the privacy risks that have an impact on auto owners and drivers. Through the use of a Bluetooth OBD adapter and a smart phone, we took a peek into the world of connecting and retrieving data.

Data Breach Demonstration Using Our PoC App

The 0xID research team created a PoC app for Android to illustrate a data breach by connecting via Bluetooth to the OBD adapter of a nearby vehicle.

In our demo, we demonstrate how quickly the privacy data is collected – in only one or two seconds in all cases – by using a simple Bluetooth pairing connection, and by issuing PID “CAN bus over Bluetooth” commands. Figure 1. An OBD-II Bluetooth adapter connected to the OBD-II port of the tested vehicle

Tested OBD-II Commands to Achieve Data Breach via CAN-over-Bluetooth

Our tests involved two different vehicles, both stopped at a traffic light. In one car we engaged our PoC app and attempted to connect to the second car that had a Bluetooth-enabled OBD adapter installed. The pairing from the hacking car to the victim completed in less than one second. While still stopped at the traffic light, we issued an OBD-II PID command to retrieve the ASCII 17 character VIN (vehicle id number) of the target car with success. OBD-II PID command documentation here: https://en.wikipedia.org/wiki/OBD-II_PIDs. Figure 2. VIN of the target car breached in under one second

We issued other commands while still in proximity of the target car such as 01 05 (query coolant temperature), and 01 03 (query fuel system status). Figure 3. OBD-II PID command 01 05 Figure 4. Testing PID command 01 03

We were able to query the vehicle speed of the target car by issuing PID command 01 0D. Figure 5. Target car continued to be paired and breached while in motion

Conclusion

In our testing, we issued documented and safe PID commands, noting that there are some undocumented commands which actually send data or instructions to the CAN bus, possibly causing an unsafe driving condition. Most of the PID commands are for diagnostic purposes, but the protocol is open for more sensitive privacy data breach. It is alarming, and conceivable, that a malicious attacker could perform a brute force test on the street against nearby vehicles. This doesn’t only affect hacking cases such as Chrysler’s Uconnect, it can be any model with a Bluetooth OBD adapter.

We decided to close this can of worms by purging the PoC app. Be aware of the journey of the Internet of Things (IoT) so that you can take the educated risk.

0xID Labs