Blog: Automotive Security

OBDeleven vulnerability

Andrew Tierney 02 Jun 2018

The “OBDeleven” OBD-II dongle is an onboard diagnostics port module that connects to a mobile app over Bluetooth

It takes advantage of weaknesses in the UDS seed process 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.

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.

We reported this to OBDeleven, who promptly fixed their app.

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 include UDS unlock of ECUs.

Although the intention is that OBDeleven receive payment for use, due to a vulnerability in their application it is possible to see the commands sent for each piece of functionality for each vehicle. From this data, it is clear to see that there are only a very limited number of UDS seeds in use – nearly all vehicles use the same seed.

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 UDS seeds are widely known and do not vary from ECU to ECU or product line to product line.
    3. 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 3rd 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 high risk if the driver does not remove the dongle whilst driving.

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

By their nature, these apps are more open and far easier to reverse engineer.

‘Fuzzing’ of the OBD port by a nearby attacker via the dongle presents a very real risk. Whilst some OEMs have reasonable mitigation, fuzzing other brands via the diagnostics port can result in terminal damage to ECUs.

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.