OBDeleven vulnerability

OBDeleven‘s OBD-II dongle is an onboard diagnostics port module that connects to a mobile app over Bluetooth.

It takes advantage of weaknesses in UDS secure access to unlock the vehicle ECU and enable enhanced diagnostics and some additional functionality. Some of these functions are only available in premium and/or regional vehicle versions. To carry out most of these tasks, OBDeleven tokens are used.

It is an excellent example of high-end reverse engineering knowledge being ‘productized’ and delivered as a commercial service to end users. It allows home-user vehicle function tuning, though its ability to tune engine performance is very limited, generally towards throttle responsiveness.

During our own research, we discovered a vulnerability in the OBDeleven app itself that allowed the unlocking process itself to be observed.

This effectively undermined their commercial offering and would allow anyone with a little coding skill to bypass the need to pay for their service.

This image shows the commands to enable and disable the start/stop functionality – this normally costs 100 credits:

Technical detail

To unlock or enable certain vehicle functions, the OBD-II dongle interacts with certain ECUs in the vehicle. The OBDeleven dongle accepts simple commands received from a web API, passes them via Bluetooth to the dongle via a smartphone, which then carries out actions against the vehicle.

The commands use UDS secure access to unlock certain ECUs before reconfiguring them. UDS secure access uses a challenge/response, which should use a secret algorithm and a random challenge seed.

The intention is that OBDeleven receive payment for unlocking functionality in cars. However, when using the application, the commands for all functionality are downloaded via the API, regardless of payment status. It’s possible to take the commands for an expensive operation and use them without payment.

Due to this vulnerability, it is possible to see the commands for each piece of functionality for all vehicles, including which UDS secure access algorithm is in use. By observing this data, it’s clear that there only a limited number of different algorithms in use. Most car manufacturers or tier 1 ECU manufacturers use only a few variants.

This means that:

1. The UDS challenge/response algorithm for these vehicles is known (although implemented inside the dongle, so not trivial to reverse engineer directly from the OBDeleven app).
2. The OBD-II port has access to systems that may have a marginal impact safety, such as enabling video playback in the IVI whilst driving.

Commercial consequence

If OEMs and other parties wish to generate incremental revenue streams from, for example, enabling premium functionality for a period of time, then security restrictions need to be capable of limiting access to 3^rd party apps and dongles of this nature.

Conclusion

Various more generic OBD-II port dongles are also available. Many are based on the ELM327 Bluetooth device which have very poor security, including no Bluetooth PIN, or an unchangeable default of 1234/0000. 

Some offer an open Wi-Fi hotspot, which clearly presents a risk if the driver does not remove the dongle whilst driving.

There is the risk that an attacker uses this entry point to inject messages onto the CAN bus connected to the OBD-II port. Whilst all modern vehicles prevent free access to the powertrain from the OBD-II port, it is often possible to interact with significant numbers of ECUs. With this level of access, it is possible to reconfigure the vehicle, or in extreme cases, disable an ECU entirely.

A number of apps are available to interface with the dongle and derive similar functionality in terms of enabling premium features or clearing faults.

There remains a difficult balance between consumers, independent garages and the right to repair vs security controls on the OBD port and protection of revenue streams for premium functionality.

Strong security mechanisms can be implemented to achieve this balance; protecting core and safety critical functionality, whilst permitting fault diagnosis.