Vulnerabilities represent another example of how important it is to ensure that in-vehicle software is not tampered with after it leaves the factory.
The recent set of vulnerabilities (14 in total) found by the researchers at China’s Tencent Keen Security Lab are yet another example of how important it is to ensure that the in-vehicle software is not tampered with after it leaves the factory.
Many oversights that were common mistakes in the past (hard-coded keys and passwords, open ports) are becoming less prevalent and can be fixed relatively easily before they pose a threat. However, in-memory vulnerabilities in the logic and memory configurations of the software are often “waiting” to be exploited, unnoticed by the best of test suites. Moreover, as the complexity of automotive systems grows, the OEM has to rely on 3rd-party software, with minimal control over its quality. Bluetooth, USB, Ethernet and cellular interface drivers, and entire operating systems such as Linux and QNX, are all being developed by 3rd parties, and they are prone to in-memory vulnerabilities as they have to interact with the outside world via allocated memory (“buffers” – as in the infamous “buffer-overflow” scenarios). Zero-day in-memory vulnerabilities are lurking in these software stacks, and can be exploited repeatedly, as the firmware cannot be cleared of the danger as quickly as the victim of an attack – manufacturer, Tier1 or other vendor – would like.
In this research, Keen Labs engineers were able to find vulnerabilities in protocol stacks (Bluetooth, WiFi, Cellular, OBD-II) that pose the most critical attack surface, as they allow remote control of the Electronic Control Unit (ECU), and from there, hijacking of the entire vehicle. Such an attack, based on reverse-engineering research, can threaten an entire fleet, when used in combination with a high-power rouge cellular tower or a rouge WiFi device near a crowded parking lot or major intersection.
Sealing ECUs according to their factory settings and, more specifically, using Control Flow Integrity (CFI), is the only effective approach to stopping hackers from reaching safety-critical parts of the vehicle. It has become a high-priority task to find appropriate counter-measures, in light of the time and effort that researchers (and attackers) invest in analyzing control units, deriving ways to bypass static mechanisms such as stack canaries and ASLR, and finding in-memory corruptions.
What can be done?
This researh shows that gateways are not enough as a security measure that separates the safety-critical ECUs from the other ECUs in a vehicle. The Gateway must allow certain messages to pass from the “external” (Telematics/Infotainment/OBD-II) side to the sensitive safety-critical side, in order to support diagnostics services (as detailed in the Tencent report) and a slew of other 21st-century services such as self-parking and battery recharging. And Gateways, after all, are ECUs themselves, vulnerable to the same type of attacks as other controllers. In the case discussed here, there was no need to attack the Gateway in order to transmit harmful messages, but it would have been possible.
Solutions such as cloud-based continual updates and Intrusion-Detection Systems would not be effective in blocking attempts to use these attack vectors.
The Autonomous Security protection provided by Karamba would harden the ECUs and authenticate the messaging between them, so that the vehicle remains safe.
This latest research took a long time to complete, and significant vulnerabilities were found. The cybersecurity industry is working as a whole to help protect the cars we are driving, and with the promise of Autonomous Vehicles increasing the stakes, critical prevention technologies are emerging to enhance the automotive protection stack with in-vehicle solutions.
