Automotive Cybersecurity: Progress, But Still Room for Improvement
June 14, 2021
Blog
This blog is the second of three that will review cyberattacks that exposed severe vulnerabilities. My goal is to help you improve the cybersecurity of your IoT devices by presenting security features that would have mitigated each of the attack vectors used. I’ll also partake in a webinar where we’ll dive into these security features using BG Networks security automation tools, open-source software, and WINSYSTEMS off-the-self hardware.
Cybersecurity attacks that affect our daily lives serve as massive wake-up calls to improve IoT security for critical infrastructure. While the recent cyber-attack on the Colonial Pipeline caused a significant disruption, the millions of cars on our roads also represent critical infrastructure that could have catastrophic effects if disrupted by a cyber-attack.
Imagine over a million cars, instantly and simultaneously having their brakes disabled. This could have happened if Charlie Miller and Chris Valasek, ethical hackers, had not been the first to find critical vulnerabilities and sent a wake-up call to the automotive industry. Their work serves as a reference to the abysmal state of automotive cybersecurity five years ago.
Security research commissioned by Mercedes Benz and disclosed last year is an updated reference that we’ll compare to Miller/Valasek’s research. The penetration testing company hired by Mercedes was 360 Group’s Skygo automotive cybersecurity team. Both teams exploited vulnerabilities that can be found in any IoT device, not just automobiles.
For both teams, it wasn’t a single vulnerability that led to remote control of the functions of these vehicles. Exploiting a series of vulnerabilities to compromise IoT devices is common and is why a cybersecurity defense-in-depth approach is important. That means including redundant cybersecurity features.
1. The principal vulnerabilities exploited by the Miller/Valasek work are shown, in order.
2015 Chrysler Vehicle Disclosure
Some of the principal vulnerabilities disclosed by Miller/Valasek’s work were obvious because cars were in the early stages of becoming network-connected at the time (Figure 1). The most obvious vulnerability was being able to connect to a vehicle over a cellular network without authentication. The next series of vulnerabilities included an open TCP port that gave access to D-bus software services (inter-process communication, remote procedure call mechanism) running on a TI OMAP processor and lack of user authentication allowing commands to be run at root.
Next in the exploit chain was the flashing of firmware updates, without authentication, to a Renesas V850 MCU with CAN bus access. This allowed a back door to be added to the V850’s firmware, enabling flashing from a remote location over the cellular network. This backdoor allowed for CAN commands to be sent from the TI processor, which they already had control of, via SPI to the microcontroller and enabled CAN bus access to other electronic control units (ECUs) with physical controls.
Preemptive Measures
Three security features would have most likely stopped the Miller/Valasek attack. A secure firmware update scheme that included authentication would have prevented valid firmware in the V850 from being overwritten. Implementation of secure boot would have complemented the secure update capability by preventing code from executing, which was directly programmed into the flash. These security features can now be found in off-the-shelf hardware such as that from WINSYSTEMS, and are ready to use out-of-the-box. However, memory corruption bugs were discovered in the SPI interface code that needed a fix.
These three cybersecurity improvements, authenticated firmware downloads, secure boot, and fixes for the memory corruption bugs, would have made the exploitation much more difficult. Reaching the vehicle’s physical controls from the head unit was dependent on interfacing with the CAN bus. If access to that bus were prevented, control of the steering, braking, and engine would have also been stopped.
2. Exploit Chain for Skygo’s work
2020 Mercedes Benz Disclosure
The first step in Skygo’s attack chain was to set up a test bench with “used” ECUs (Figure 2). Adversaries have an advantage when hacking IoT devices because they can often reverse engineer devices, as Skygo did. Once the test bench was set up, they gained debug access through misconfiguration of the Qualcomm processor and then dumped firmware from a NAND flash. The dumping of flash memory to get access to plain text code for reverse engineering is a widespread step for hackers (Note: In my next blog, I’ll write about the surprising number of available hacking tools to do this.) In the Skygo case, they spent ample time obtaining access to plain text code because it was critical for finding additional vulnerabilities.
With the plaintext listing of the code, they discovered that the telematics control unit (TCU) ran a Linux OS, an engineering debug program with the ability to send CAN messages to other ECUs, regional certificates for access to Mercedes Benz back-end servers, and hard-coded keys to decrypt the certificates. In other words, they hit the jackpot. The ability to send CAN messages via the debug program gave Skygo physical control of the car. The back-end services connection led to the access of an estimated two million Mercedes vehicles.
What Should Have Been
Suppose the debug interfaces were secure and the code in the flash memory was encrypted. In that case, the subsequent steps to obtain the ability to send CAN message and finding the certificates would have been far more difficult. These security features have become much easier to implement using security automation tools such as those from BG Networks.
The conclusion from comparing the work done by these teams, five years apart, is that automotive cybersecurity has improved significantly. SkyGo did not find obvious vulnerabilities like unauthenticated interfaces or open ports. The cybersecurity of the Mercedes vehicles tested was extremely good. With Mercedes’ secure over-the-air (OTA) update capability, they were able to patch vulnerabilities in millions of cars in a matter of hours after disclosure.
Skygo’s penetration capabilities are exceptional, and the effort required to find the initial vulnerabilities was significant. In fact, the first ECU they targeted, the head unit, could not be penetrated. SkyGo couldn’t access critical safety functions, such as the brakes and steering, as Miller/Valasek did. But there is still work to do as the vulnerabilities that Skygo did find, that led to remote control of a fleet of vehicles, is unacceptable.
The automotive industry is not standing still when it comes to cybersecurity. They are working hard to improve security further as mandatory cybersecurity regulations in the EU require it. Other industries do not have this sort of strong regulation. It remains to be seen if cybersecurity laws are needed for other industries.
Colin Duggan is the CEO of BG Networks. Before founding BG Networks, Duggan worked at Analog Devices for 29 years in various engineering, management, and marketing leadership roles, managing teams in the U.S., China, Europe, and India. Colin’s experience includes work in automotive, consumer, industrial, and aerospace, and defense industries.
I’m currently working on one of my bucket list items: starting a company. I’m excited by the prospects of developing products that make a difference and growing something new. My 29 years at Analog Devices (ADI) prepared me well for the challenge of starting a company. One of the great things about ADI is that continuous learning is highly encouraged, and this is reinforced by the opportunity to engage in a diversity of tasks and roles.
