Patch-based vulnerabilities in the automotive domain

SheeldS CTO, Gil Litichever, explains how patch-based vulnerabilities in software updates can leave vehicles open to cyber-attack.

Patch-based vulnerabilities are a looming threat to the automotive domain. If you own a computer or an internet-enabled device, chances are that you’ve experienced an update process. Probably one that’s delivered a software patch for improved functionality or perhaps fixed a security issue.

These updates, usually conducted remotely over-the-air (OTA) via the internet, enable your device to function at its best – and most secure. However, the way these updates are distributed is not always simultaneous, and they often require user authorization to initiate. This leaves a window of opportunity for hackers to exploit. Once a patch is available, hackers can review it, infer the vulnerability, and then use that to gain access to devices that have yet to be updated.

Now, as modern vehicles become increasingly reliant on complicated software to manage features such as cruise control and automatic braking systems, the need for OTA software updates in the vehicle is also becoming important. Safety-critical features that are software-based must be regularly monitored and updated to make sure they are working as intended. However, the connectivity required to enable this also leaves them vulnerable to cyber-attack.

Patch-based vulnerabilities

Often software patches are used to solve security vulnerabilities in the code/firmware. Some vulnerabilities are made public, and updates are scheduled with advanced notice. Others, especially those which contain critical system patches, are not often public knowledge. Finding these patches in advance of a widespread update allows hackers to search for exploits which they can use to target vulnerable systems.

Analyzing a patch using static analysis methods such as the ones discussed in this Google Project Zero blog post or this SlideShare from CISO Platform can create an exploit in a very fast and efficient manner. This is also true of automatic techniques, as seen in this paper by Brumley, Poosankam, Song and Zheng.

Since security patches are not simultaneous, it is possible with the right resources to search for a patch, create an exploit, and launch an attack before the systems are updated.

Relevance to the automotive domain:

Patch-based vulnerabilities should be of particular interest to the automotive domain. OEMs and their suppliers are part of a complex supply chain. Many ECUs have the same code base (at least some parts of it), and some updates may manifest in systems that do not have an update mechanism at all but share the same libraries, drivers or other resources.

Firmware updates are slow in the automotive domain. Some vehicles make use of OTA updates, but many still require physical access to the vehicle. Additionally, because bugs in software can lead to potentially life-threatening faults, and major recalls, the industry is conservative with its update process. As such, exploiting zero-day vulnerabilities becomes much easier.

Using patch-based vulnerabilities is also cost-effective. In general practice, each attack on an independent, embedded system requires time and expertise – and is only effective on some systems. Exploiting patch-based vulnerabilities leverages existing, proactive efforts by OEMs and Tier-1s to fix bugs. This lowers the “cost” for malicious actors when developing an attack.

How can we fix the problem?

Arguably, all efforts to hide the firmware/patch are ultimately doomed to fail. No matter the anti-tamper/anti-piracy method put in place, a tenacious and dedicated hacker will find a way in. The most obvious technique in the automotive domain is to extract the code/flash memory from the target (if you disagree, I’m willing to argue! – see the appendix below or drop me a message!). To counter this and protect the vehicle we need to think creatively.

What is required:

• A system to analyze the similarities of related ECUs, and to fix the problems relating to shared vulnerabilities. There has been some academic research conducted in this domain.

• Simultaneous firmware updates, sent to all willing participants, which include/follow these parameters:

• Encrypted updates.

• Real-time monitoring of the update spread.

• Synchronized updates: an allotted timeslot in which all systems can reach and download the encryption key.

Appendix: Obtaining the firmware or patch

In the automotive domain obtaining the firmware or patch can be done in several ways:

By obtaining the incremental update/full firmware from a physical device.

If the update is carried out physically rather than remotely, for instance at a garage, it may be possible to recover the patch or full firmware from a diagnostic or update tool. Some devices may have protection and delete the update once completed, but these update devices (tablets, laptops) can be easily hacked.

Find the update on the internet – many updates are already readily available via the web.

Ask suppliers politely. As is the case across many industries, the application of some liberal social engineering can get you the information you need. This is also a clear indication that the automotive industry still has some way to go to catch up with the IT industry in general infosec procedures.

Assuming the update itself is encrypted, and we don’t have the key, it’s still possible to get the firmware from the device:

• Connect to terminal/shell and use the ECU operating system’s inherent capabilities (Linux/Unix-based systems, and even embedded systems, have such capabilities). It may require some hardware reverse engineering and tinkering.

• Connect to the jtag interface and extract the firmware from the flash or random-access memory (RAM):

• Usually requires some hardware work.

• If the firmware is stored encrypted on the flash, then extracting it from the RAM is a good option.

• If anti-piracy methods are implemented some hacking may be involved.

• Use the inherent bootloader – again sometimes some hacking may be needed if the bootloader is protected.

• Solder or connect a memory reader directly to the flash chip and extract the flash.

Conclusion

What is key to remember is that even OTA updates, which are supposed to mitigate risks, can become a potential opening for a cyber-attack. Patch-based vulnerabilities are one among many methods which can be exploited to gain access to a vehicle. It is examples such as this that make it clear that professional expertise is required to avoid missing vulnerabilities that might not be immediately obvious to the layman.

Many of these methods have been successfully implemented by Arilou during past testing and analysis sessions. Our research always brings us back to the testers adage that no system can ever be 100% error-free and as such no system ever 100% secure. Even anti-tamper/anti-piracy/encryption methods can be bypassed. As such, it’s important to make sure security professionals are assigned to the development, monitoring, and management of automotive cyber-security solutions. This is the most effective way to safeguard the future of the automotive industry.

*SheeldS previously known as Arilou