In Singapore (as in many countries) owning a car is a status symbol. My brother once showed me a building in his gated community that housed only one kind of item – the owner’s many cars.
So when Dennis Kengo Oka, principal automotive security strategist for Synopsys Software Integrity Group wrote the blog “Analysis of an attack on automotive keyless entry systems” posted the story about how Lennert Wouters (at PhD student and security researcher) at University of Leuven in Belgium hacked into a Tesla Model X, I just had to read more about what he did.
Watch the video below for the process.
How Wouters did it
The attacker uses a pre-prepared attack device consisting of a modified body control module (BCM), a modified key fob, and a Raspberry Pi. Modifications include replacing the Secure Element (SE) chip with Python scripts running on the Raspberry Pi that emulate the SE.
- The attacker approaches the target vehicle, reads the VIN through the windshield, and configures the emulated SE for the modified BCM in the attack device to use the target VIN.
- The attacker locates the target key fob and brings the attack device close to it and connects over low frequency (LF) at a distance up to about 5 meters by pretending to be the target vehicle. The attacker uses an identifier derived from the VIN to force the previously paired target key fob to advertise as connectable over Bluetooth Low Energy (BLE).
- The attacker pushes a malicious firmware update over BLE from the Raspberry Pi to the target key fob in order to gain full control of the key fob. This update can be performed by using the over-the-air download service on the target key fob from a distance of up to 30 meters.
- After the target key fob has been updated, the attack device reconnects over BLE. Since the key fob is running the malicious attacker-controlled firmware, which allows sending arbitrary application protocol data unit (APDU) commands to the SE in the target key fob, the attacker is able to extract a number of valid one-time unlock commands (e.g., unlock door, trunk, etc.) for the target vehicle from the SE in the key fob.
- The attacker approaches the target vehicle and uses the valid unlock commands to unlock the target vehicle. The unlock commands are sent over BLE from the Raspberry Pi to the target BCM.
- The attacker gains physical access to the interior of the vehicle and can physically connect the attack device to the in-vehicle network over the diagnostics port located below the central display. The attack device connects to the target BCM over controller area network (CAN).
- The attack device instructs the target BCM to pair with the modified key fob. After passing a challenge-response authentication with the BCM to add the modified key fob, the necessary credentials are stored in the emulated SE for the key fob.
- The attacker starts the vehicle using the newly paired key fob on the attack device to successfully perform a challenge-response authentication using the previously stored credentials in the emulated key fob SE, and is able to drive away with the target vehicle.
Key to exploiting the vulnerability
Literally, Wouter exploited the vulnerability on the Tesla’s key fob.
According to Oka although signature verification is implemented on the key fob, a vulnerability allows the attacker to update the key fob over BLE with malicious firmware. He added that although valid key fobs typically store signed certificates received from the back end and acquired during provision, these certificates are not verified by the vehicle BCM while pairing with the key fob.
Embrace security measures
There are already multiple ongoing activities in the automotive industry to help improve cyber security, such as the development of a new cyber security engineering standard called ISO SAE 214342 and regulations such as UN regulation 155 cyber security.
“There are several potential approaches for discovering and addressing the type of issues just described. Our focus here is not on describing a specific technical security solution to address a particular vulnerability, but rather on providing a broader discussion to emphasise the approaches and security activities that automotive organisations should engage in to help improve security and reduce the risks of vulnerabilities and weaknesses in the final product before release,” he elaborated.
Address implementation and design issues with application security testing
Oka said the first issue is the improper signature verification in the implementation on the key fob.
“These types of implementation issues can often be found using static code analysis, software composition analysis (to identify known vulnerabilities), and fuzz testing (to detect unknown vulnerabilities). It may be possible to detect these types of issues during penetration testing, focusing on high-risk areas such as security-related functions and firmware updates.”
“The second issue is a missing certificate verification in the design of the pairing protocol between the BCM and the key fob. These type of design issues can often be identified through security design reviews,” said Oka.
He warned that it’s imperative to perform a proper threat analysis and risk assessment of the target system to identify high-risk areas, which helps define appropriate security requirements and assists in designing suitable security controls. Additionally, it may be possible to detect these types of issues during penetration testing, focusing on high-risk areas such as security-related functions and pairing functions.
Patch, patch, patch
“This example also highlights the need for automotive organisations to establish internal processes and workflows to monitor, gather, and process vulnerability information, such as what is provided by security researchers, in order to respond accordingly,” concluded Oka.
