A vehicle firmware security vulnerability: an IVI exploitation

From 2018 to 2021, the cyber attacks on vehicles increased to 125% [1], so automotive cybersecurity has become a research trending topic. In particular, connected vehicles are prone to remote attacks and the infotainment can be considered one of the most vulnerable attack surfaces of the vehicle.

Preliminary studies on vehicle vulnerability assessment trace back to 2010 [2], wherein the authors showcased the ability to inject messages into the CAN bus communication and manipulate the Electronic Control Unit’s (ECU) behavior. This initial analysis was expanded upon in [3], where the authors delved into the attack surfaces of connected vehicles. The pivotal recognition of the need to integrate cybersecurity protection mechanisms and solutions into vehicles emerged in 2014. This realization materialized when Miller and Valasek [4] effectively compromised a Jeep Cherokee. Following these attacks, numerous papers in the literature have documented other highly significant incidents [5‐7]. The prevalence of cybersecurity attacks in the automotive domain prompted the automotive industry’s supply chain to contemplate solutions for addressing these security issues. In 2022, both the regulation UNECE WP29 R155 [8] and the standard ISO 21434 [9] on vehicle cybersecurity were published, signaling a concerted effort in this direction. Nevertheless, finding a singular, comprehensive solution remains complex. Consequently, vulnerability assessment and penetration testing activities persist as the foremost strategies to mitigate security issues.

For this aim, at the beginning of 2022, we started a vulnerability assessment of the In-Vehicle Infotainment (IVI) system Gen5W_L firmware which is part of Hyundai, Kia, and Genesis vehicles. As result, we found different issues that allow us to create our customized firmware. This study is part of one of our research activities to identify vulnerabilities in complex computer systems and publish the achieved results following the responsible disclosure process. This is not the first work that we have done in this field. At the end 2020, we published the [CVE-2020-8539]¹ that mainly targeted Gen5 IVI. This activity generated the KOFFEE (Kia OFFensivE)² exploit. It may allow an attacker in Kia Motors Head Unit (HU) to inject unauthorized commands, by executing the micomd executable daemon, to trigger unintended functionalities.

Leveraging the experience got with the Gen5, we analyzed a Gen5W firmware and, from a security perspective, we found a well-defined firmware with several security measures like the combined usage of different cryptosystems as public-key and private-key. However, we were able to discover several security issues, that allow us to create and encrypt a customized firmware and install it on a Gen5W LGE based IVI system of a Hyundai group motor vehicle. Upon concluding our work, we conducted a responsible disclosure with the Hyundai Motor Group, resulting in the publication of the following CVEs: CVE-2023-26243,³ CVE-2023-26244,⁴ CVE-2023-26245,⁵ and CVE-2023-26246.⁶

The litterature about cybersecuirty attacks to vehicles has to date back to 2010. In [2], the authors presented the first experimental studies and analysis of vehicle’s vulnerability. They demonstrate the fragility of the underlying intra-vehicle network by proving that an attacker can be able to inject CAN messages and alter the behavior of an ECU. Checkoway et al. [3] analyse the external attack surface of a connected vehicle by considering the I/O channels of the car, both physical and (short and long-range) wireless connections.

In 2014, the first successful attempts to hijack a vehicle was made by Miller and Valasek [4] is the one to the Jeep Cherokee. This proved that modern vehicles can be hacked like traditional PCs or smartphones. In 2015, both AUDI, Tesla and General Motors have been attacked. The AUDI TT airbag system has been hijacked [11] as well as other functions by exploiting a zero-day flaw in third-party software. On the other hand, the Tesla Model S, which is the world’s most connected car, after 2 years of in depth hacking, was hacked by Rogers and Mahaffey [12]. The same model was remotely hacked [13] in 2016 by a team of Chinese researchers that caused a havoc. Then, a 29-year-old software developer figured out a way to attack GM cars by using a personally revised version of OnStar, which is a built-in system built that allows owners to remotely manage some vehicles functionalities. The tampered version, called OwnStar activates some of the functionalities of OnStar by simply attaching a device somewhere on the targeted car. Similarly, the official BMW web domain and ConnectedDrive portal was attacked [14]: a research discovered two zero-day vulnerabilities in both of them. The year after, 2016, other attacks are reported. Mitshubishi Outlander hybrid car was hacked [15]: the alarm can be turned off via security bugs in its on-board Wi-Fi. Nissan Leaf was hacked via Mobile app and Web Browser [16]: once connected, the vehicle’s engine and brakes could be controlled remotely. The proliferation of automotive offensive security studies in the last decades increases over and over. Among the others, we recall the remote attack on the Bosch Drivelog Connector OBD-II Dongle pointed out by the Argus Research Team [17]. The vulnerabilities allowed the attackers to stop the engine of a moving vehicle using the drivelog platform. Also in 2017, Tesla model S was remotely hacked by the Keen Security Lab [18] that discovered a vulnerability allowing a full attack chain to implement arbitrary CAN BUS and ECUs remote controls on Tesla motors with latest firmware is possible. In [19], a social engineering attack was developed to grab information circulating on the CAN bus of a vehicle by using an Android based after market infotainment system while the Keen Security Lab, in 2018, presented a set of vulnerabilities of BMW cars [20] that make them prone to remote access. Also, Subaru [21], Volkswagen [22] and Tesla [23] again were affected by remote attacks. In 2018, the attackers pointed out a vulnerability that may allow a thief to steal a Tesla Model S in seconds by cloning its key fob. In 2019, the attack CANDY CREAM [24] exploited first a remote vulnerability discovered into an after-market infotainment system. In addition, the researcher were able to inject CAN bus frames when the infotainment system was connected to the CAN bus.

In March 2020, the Keen Security Lab has been performed an experimental security assessment on Lexus Cars [25] pointed out a new vulnerability on the infotainment system of the Toyota Lexus car. Then in November 2020, Belgian researchers demonstrate a third attack on the car manufacturer’s keyless entry system [26] of Tesla Model X. In the spring of 2021, Weinmann and Schmotzle [27] remotely exploited the Tesla Model 3 and they were able to disable the car’s firewall and send a message through the car’s gateway to open its port. More recently, during Pwn2Own Vancouver 2022 [28], the Synacktiv team of David Berard and Vincent Dehors won $75,000 by demonstrating an exploit of the infotainment system with a sandbox escape. Later that same day, they provided this public demonstration. In 2024 [29], by using a device known as Flipper Zero, but potentially replicable with other equipment such as Raspberry Pi, the attacker can create a fake WiFi network called “Tesla Guest” to grab the credentials of the owner and theft the Tesla.

Over the last 15 years, the field of vehicle cybersecurity has grown increasingly complex. Particularly since 2014, numerous new attacks targeting various manufacturers have been recorded annually. Our research aligns with this evolving landscape by introducing a novel approach distinct from previous methodologies. Specifically, in this paper, we delve into the firmware of an infotainment system, aiming to identify vulnerabilities at the firmware level rather than focusing solely on system connectivity or misconfigurations. Leveraging these vulnerabilities, we can develop customized firmware and install it directly into the vehicle.

Figure 1 represents the working weeks with the different phases and the relative activities and findings. The diameters of the circles represent the effort spent for each phase and in bold we report the main activity for each phase. Following, we report a short description of the main phases as reported in Fig. 2. In particular, we describe the analysis of the executable file DecryptToPIPE, which, during the installation, is used to decrypt the firmware. Other significant executable files are AppDMClient and AppUpgrade, both involved in the installation checks like the verification of the digital signature, while the file lge.upgrade.xml contains some firmware information like the version number and date.

The target firmware is composed of different folders and files. The only file in clear text is IONIQ5_EU.ver, while all the others are encrypted. IONIQ5_EU.ver contains a list of the firmware files with some related information like the dimension. Besides, in the folders, some files are hidden like .lge.upgrade.xml. By opening this file, we noticed that an error occurred due to the fact that the xml file is not in clear format but it is encrypted together with the other downloaded files. In Fig. 3, we report the most significant files for our work. In particular, AppUpgrade is an executable program in charge to decrypt and install the firmware. Other relevant files are mango.rootfs.tar.gz and new_gui.tar.gz, which are compressed archives.

Once the firmware file tree has been analyzed, we use an already existing project⁷ on GitLab to decrypt the DecryptToPIPE file that is in charge of performing the decryption operation of each encrypted file sent as input and it is encrypted into the Gen5W_L IVI system. The Key_file and DecryptToPIPE can be retrieved from the HU using a specific procedure.⁸

We decode every encrypted file of the Gen5W_L software with the command in Listing 1.

DecryptToPIPE can be executed as a C program and takes in input the Key_file, the file to decrypt, and 0 which represents an offset of bytes to obtain in the decryption phase. To understand the behavior of DecryptToPIPE, we use Ghidra which allows us to reverse the DecryptToPIPE executable file. In Fig. 4, we show the selected parameters to import DecryptToPIPE ELF file in Ghidra.

After the import, Ghidra analyzes the file and returns the assembly and decompiled code. Starting from the main entry, we analyze the code and rename functions variable to make the code more readable. For instance, in Fig. 5, we show the decompiled code of the start main function. There are three different functions that we renamed properly after the complete analysis. The first function, identified is RSA_decrypt_and_AES_key, reads the Key_file and obtains a 128 bits key to decrypt the software file. The second function allocates some area of memory, while the third function calculates the Initialization Vector (IV) and uses it together with the 128 bits key to decode the file using AES-CBC. In any case, before proceeding with the decryption, the third function calculates and compares the SHA256 saved into the input file itself. If this check fails, then the decoding operation is quit and it is not executed.

The third function, which we call AES_and_SHA is mainly dedicated to the calculation of the SHA256 and its verification, as well as to the decryption of the software file passed to DecryptToPIPE. In particular, we notice that the third function read the file to decrypt from the bottom and look for a string of two subsequent HEX characters in the file: “TE” (0x54,0x45 in HEX). Then, the function controls the next character after “TE” to determine if it is a “2” or a “R”. In our case, we notice that all firmware files have “2” while checking another firmware for Genesis vehicles the terminators are “R”, so we can state that, according to the vehicle model, the file terminator is different. Continuing analyzing the disassembly and decompiled code from Ghidra of the function AES_and_SHA, we discover that it starts a series of integrity checks that we properly link to mbedtls_sha256_starts, mbedtls_sha256_update, and mbedtls_sha256_finish functions. Moreover, by reverse engineering the HEX values of each file, as reported in Fig. 9, we found that after the “TE2”, there is an extra HEX character, which we call “x”, that can vary from file to file. In any case, we observed that the “x” value is not used.

With the mbedtls SHA256 instructions, the AES_and_SHA function computes the SHA256 of the file content starting from the first byte position up to the sequence “TE2+x” (0x54,0x45,0x32,0xFF). When calculating the SHA256, the “TE2+x” sequence is not considered. Then, to verify that the calculated SHA256 corresponds to that one present in the file firmware, DecryptToPIPE starts reading the 32 byte values after the “TE2+x” sequence. If the two SHA256 are equal then DecryptToPIPE goes ahead with the decryption otherwise it quits.

As shown in Fig. 9, each file has a content, which can span from few kB to some GB. Then, we find the file delimiter “TE2” (0x54, 0x45, 0x32 in HEX), which is just a predefined string to delimiter the end of the file. Note that in a file, we find different times the string “TE2”, however, only the last string is considered by DecryptToPIPE. After the string, there is a HEX char, which is the first character of the following digital signature. The next 32-byte are the SHA 256, computed on the file content. After the file content, we have 36-byte which needs to be written in this defined order, however, the firmware installation fails the checks. Then, we find 16,384 byte which contains a digital signature, generated with the private RSA key. In this situation, we can not replicate the digital signature because we have retrieved only the public RSA key and it is not feasible to try to find a private RSA key from a public RSA. With different tests, we discover that the lack or incorrect signature can block the installation of any file generated by us. This happens since AppDMClient first, and AppUpgrade then, are in charge of validating the digital signature of any encrypted file. With the retrieved information, to modify a file correctly, for example, to install a backdoor, we need to follow the next steps:

Studying the software process installation into the Gen5W head unit, we noticed that AppDMClient and AppUpgrade, two binaries involved in the installation process, check for the valid digital signature of each encrypted file. Thus, to process with a complete and effective installation process of a customized software into the head unit, we need to i) skip the digital firmware check or ii) create a valid digital signature. Since, we cannot afford the case ii) since we do not have the private key, we can only work on skipping the digital signature check. However, to reach this goal, we need to modify AppDMClient and AppUpgrade:

Starting from the previous findings, this section describes step-by-step our procedure to create a customized firmware. Firstly, we need the customized files AppDMClient, AppUpgrade. Then, we have to create the files that we want to customize. In our case, we decide to modify three main files:

To install the custom firmware in the head unit, we firstly replace the original AppDMClient with our modified version to skip the digital signature check. Then to start the installation, we have just to prepare a USB key in which we put the original firmware file but we replace our encrypted version of AppUpgrade plus our encrypted files like new_gui.tar.gz. At this point, we insert the USB stick into the head unit and the update button will be enabled to start the installation of our custom firmware. In addition to the customized images, a proof of our work is the installation of the firmware with a different version number written within the .lge.upgrade.xml file. We create a new .lge.upgrade.xml where the version number is AE_E_PE.EUR.CHIMAERA_CF01.808489, we encrypt and test it on the head unit that reads and accepts it (Fig. 15).

In this section, we highlight two key functionalities that can be remotely managed using Chimaera: the injection of CAN messages and the remote control of the cellular Head Unit’s cellular connection. We have selected these two functionalities because we believe they are the most security-relevant (Fig. 16).

To perform a proper and seamless firmware customization, we developed two Python scripts with different aims: the first, chimaera_build automatically reproduces the encryption process and encrypts the custom firmware to install; the second, chimaera_image, to compress in the right format the images of the custom firmware.

In conclusion, our research on the security vulnerabilities within the IVI system firmware of Hyundai, Kia, and Genesis vehicles has unveiled critical weaknesses that could be exploited by malicious actors. The Chimaera attack, utilizing a printf function in the statically compiled mbedtls library, allows for a format string attack leading to the injection of malicious code and manipulation of the IVI system. Performing a reverse engineering process, we were able to exploit these vulnerabilities, bypass digital signature checks, and remotely control the IVI system. The importance of our findings lies in the potential risks associated with compromised IVI systems in modern vehicles. The number of connected vehicles has increased the vulnerability to remote attacks, and the IVI, as a crucial entry point, demands cybersecurity measures. Our responsible disclosure of these vulnerabilities aims to prompt necessary actions to address and correct these issues, ensuring the safety and security of vehicle systems.

Future activities could include collaborative efforts with automotive manufacturers to implement robust cybersecurity measures, conduct thorough security audits, and develop intrusion detection and prevention systems for IVI systems. Additionally, ongoing research should explore emerging technologies like generative language model-based that can be used by attackers to generate malicious code in a relative short amount of time.