By Vít Šembera (Senior Cybersecurity Researcher, VicOne and Trend Micro)
Modern vehicles are increasingly relying on software executed by embedded computers, and this dependence is expected to further expand with the integration of technologies that support traffic safety and enhance passenger interactions. Examples include autonomous driving systems and the incorporation of multiple screens within smart cockpits.
Automotive hardware and software solutions and the whole vehicle’s life cycle are becoming formally and technologically standardized, and mainstream consumer solutions are replacing proprietary ones. Given that powerful CPUs with virtualization and operating systems like Linux or Android are becoming more common in connected vehicles, the cost of automotive electronics is expected to become half of the vehicle’s total cost by the end of this decade.
Consequently, for car manufacturers (OEMs), revenue from selling advanced features is a crucial part of their balance sheets. From a manufacturing-economy-of-scale perspective, the most cost-effective solution is to build functions physically into the vehicle, which entails that the required hardware parts should also be mounted even though the customer didn’t order or pay for them at the time of purchase. So, all the vehicle’s functions are preconfigured, but not all features are activated. Some OEMs have already begun implementing subscription fees for aftermarket features activation as a possible means to improve profit margins. Additionally, there could be a gradual shift from selling these features as lifetime functions to adopting a subscription-based model.
Thriving unofficial markets for vehicle updates
The use of subscriptions for aftermarket features activation opens doors for the unauthorized selling of activation codes or electronic control unit (ECU) software hacking to circumvent activation code validation. Such illicit activities are offered today on specialized internet forums where a gray market is already established. One example is selling activation codes for navigational software maps running in in-vehicle infotainment (IVI) systems. Codes are needed to activate map updates and, of course, car owners must pay OEM dealerships a certain subscription fee — an OEM in the UK, for instance, charges £80 every year. These are uploaded either over the air (OTA) or via a flash drive inserted into a vehicle’s USB port.
We have been aware of several companies that are not officially linked to OEMs but offer cheaper features activation, map updates included. There are also unofficial update files floating around forums for car enthusiasts and OEM unlicensed garages, where they can be downloaded for free. Unscrupulous individuals may even sell these on eBay and other e-markets.
Anatomy of a sample malicious update file
We reverse-engineered a malicious update file downloaded from a community forum to understand what vulnerability it exploits and how its hack works. While it’s not explicitly stated for potential users that the file is malicious, it’s a common understanding on such forums that such files are unofficial and may be used at users’ own risk. Unauthorized changes in the vehicle firmware and/or configuration data can lead to ECU inoperability. Repairs can be expensive, and there is the risk of an accident in the event of unexpected failure.
After the file is loaded onto a USB flash drive and the flash drive is inserted into a vehicle’s USB port, the file should enable SSH (Secure Shell) access to the IVI system over the on-board diagnostics (OBD) II port. It’s mentioned in the forum that this file can be used only with IVI software versions up to mid-2019, and we can assume that the affected OEM has already patched the vulnerability exploited in this hack.
The malicious update file has the name “UPD44044.BIN”, a size of 51,200 bytes, and a .TAR format:
Figure 1. The content of the malicious update file
For comparison, an official Bluetooth update file for one vehicle model looks as follows:
Figure 2. The typical content of a regular update file
A typical update file contains an XML schema with updated definitions and binary files. On the other hand, the malicious update file has:
- an empty XML definition schema, which is invalid.
- a symbolic link to a target root directory.
- three files that will be uploaded into the /var directory (as referred to by the symlink).
One of the files, DebugConfig.cfg, contains only the following line:
Figure 3. The only line contained in the DebugConfig.cfg file
From this line, it looks like it is mounting the .SO file as a DOS file system into /mnt/data/nav. It’s worth noting that the first keyword is misspelled. Based on our checking, the .SO file contains a DOS MBR record with three partitions:
Figure 4. The content of the .SO file
The file names of the other two files — “.SO” and “.so” — are quite interesting. They evoke a shared library naming convention but with no library name specified. These files are also implicitly hidden as they start with a dot. The uppercase file, “.SO”, is a 32 kB-long file system image that contains a text file with the following strings:
Figure 5. The strings in the .SO file system, which execute the first stage of the malicious action: redirecting lib to the arbitrary .so file
The second file, “.so”, is even more interesting. It’s really a shared library, compiled with the original name “libEVO_SYSDEBUG.so.1”, and contains the following functions:
Figure 6. The functions defined in the .so file
The first three functions are dummy functions returning 0. Probing further, we found out that all the logic is stored in the createDbUpdate() function. Here’s what’s inside:
Figure 7. The second stage of the malicious action: the createDbUpdate() function
So, the createDbUpdate() function first unmounts the navigational data file system and deletes all traces of the malicious update on the IVI system. It then drops a script named “debugon.sh” in the memory file system and runs it. The script contains these commands:
Figure 8. The final stage of the malicious action
The debugon.sh script is exactly what is needed to enable a debug mode on the IVI system — using a proprietary config DB command to set the SYS_DEBUG flag to TRUE — allowing remote debugging and enabling SSH services to run during startup. Once this script is successfully run as root, any hostile action can be taken at this stage.
In addition, anybody can log in as root into the main IVI QNX cluster node over the OBD-II port. While a root password is still necessary, we have found posts on forums saying that it has already been shared within the closed community. We have also discovered ourselves that this can be broken easily via a brute-force attack.
It’s important to note that an IVI system is connected to a vehicle’s internal gateway over the CAN bus, MOST, and Ethernet. With a compromised IVI system, malicious actors can move laterally to disable other vehicle subsystems, access personally identifiable information (PII), implant ransomware or backdoor connection, monitor the movement of the vehicle, or even take complete control of it.
Securing the smart cockpit
This hack shows that malicious update files, especially those freely available outside official channels, can severely compromise the safety of a vehicle and its driver and passengers. But for malicious actors to stage a successful exploit that takes only several seconds to execute, they first should have physical access to the vehicle’s USB and OBD ports.
While the vulnerability this binary exploits is in a thread of the NBTCarHU daemon responsible for USB firmware updates, it has been mitigated by an IVI software version released in 2019. Be that as it may, OEMs should remain vigilant in protecting their connected cars against known and undisclosed vulnerabilities.
VicOne recommends a more comprehensive automotive cybersecurity strategy to better protect connected vehicles from similar vulnerabilities in the future. As a subsidiary of Trend Micro, VicOne leverages the cybersecurity leader’s over 30 years of industry expertise. VicOne offers the following solutions:
- xCarbon, an intrusion detection and prevention system (IDPS) for ECUs, can detect vulnerability exploitation and privilege escalation in the IVI system, providing superior detection and protection in vehicles.
- Smart Cockpit Protection, a security application installed in the IVI system, can detect and block malicious files (such as unlicensed IVI applications, especially those provided for free outside official channels), protecting IVI systems and preventing leakage of customers’ PII and private data.
Combining these two solutions provides OEMs with exceptional multilayered cybersecurity protection, extending attack-surface visibility — from the system level to the application level — for future threat detection and response.
To read more research on other possible vulnerabilities in connected vehicles and learn best security practices, visit our resource center.
