When looking over the security architecture designed by Charlie Miller and Chris Valasek, we see some overlooked attack vectors.
Last week, 11 automotive industry leaders, including Daimler, Audi, FCA, Volkswagen, Baidu, and BMW issued a series of guidelines titled “Safety First for Automated Driving.” The guidelines, which were compiled along with Intel, HERE, and Continental, detail how the automotive industry can uphold safety standards for self-driving cars. The guidelines call on OEMS and tier-1s to include CFI in the ADAS ECU firmware in order to ensure the ECU’s runtime integrity and prevent exploit attempts.
The guidelines brought to mind two publications issued over the past year by Charlie Miller and Chris Valasek, aka “the guys that remote hacked a Jeep Cherokee,” and painted a clear contrast between two different approaches to cybersecurity.
In a Medium piece they posted in April, Charlie Miller and Chris Valasek described the automotive cybersecurity protection strategies they have devised. Several months earlier, the duo published a 25-page report entitled “Securing Self-Driving Cars (one company at a time),” a sort of intro to self-driving cars security and a look at Chris and Charlies’ experiences in automotive cybersecurity.
First things first, it must be said that they have designed a solid cybersecurity architecture. The decision to allow only outbound connectivity, with connections initiated only by the car, is smart and makes things more difficult for hackers. Using cellular data network Access Private Network (APN) and IPSec for encryption reduces attackers’ “over-the-air” access for data and spoofing.
They also push for the use of a read-only file system and a secure boot mechanism, which minimize the ability of hackers to create persistent exploits. When possible, they remove any attackable vectors like Bluetooth or Wi-Fi from the vehicle, and if removing them is not an option, they put them on separate networks with as few privileges as possible.
At Karamba Security, we are working closely with many automotive OEMs and Tier-1s on precisely these matters. We have seen a wide range of use cases and deployments and when looking over the architecture designed by Charlie & Chris, we still see some overlooked attack vectors, namely file-less attacks.
As the duo say in their Medium piece, “we know that we cannot solely count on a device — especially one that has connectivity — to never get owned.” Considering this, and in light of the fact that connected devices are always under attack, we must protect against in-memory file-less attacks in addition to persistent attacks. File-less attacks are commonly used in IT and mobile attacks and can also be implemented on vehicle ECUs. When implemented, they can send malicious CAN commands over the vehicle’s networks without requiring persistency, which may cause severe safety problems.
To block file-less attacks, cybersecurity teams are now using control flow integrity (CFI) solutions that instrument binaries against in-memory attacks. Google (Pixel 3) and Apple (iPhone XS) have implemented these solutions for in-memory attacks, and the time has come for automobile manufacturers to apply CFI on their connected devices.
Further, ECU level protection like CFI is especially important for self-driving cars because of all the needed additional external connectivity, such as RF, DSRC and C-V2X). We believe that CFI should be built into the vehicle architecture, be it on AUTOSAR RTOS or Linux or Android, in order to make the cybersecurity design more realistic to begin with, and to enable these additional services with minimal risk.
As recent industry publications indicate, even after reducing the attack vectors, software integrity is a must for autonomous vehicle safety and security.
The success of the autonomous vehicle industry depends on it.
