Since 2017, Lexus has equipped several models (including Lexus NX, LS and ES series) with a new generation infotainment, which is also known as AVN (Audio, Visual and Navigation) unit. Compared to some Intelligent connected infotainment units, like Tesla IVI and BMW ConnectedDrive system, the new Lexus AVN unit seems to be a bit more traditional. From a security perspective, it may highly reduce the possibility of being attacked by potential cybersecurity issues. But a new system is always introducing new security risks. After conducting an ethical hacking research on a 2017 Lexus NX300, Keen Security Lab [1] has discovered several security findings in Bluetooth and vehicular diagnosis functions on the car, which would compromise AVN unit, internal CAN network and related ECUs. By chaining the findings, Keen Security Lab are able to wirelessly take control of AVN unit without any user interaction, then inject malicious CAN messages from AVN unit into CAN network to cause a vulnerable car to perform some unexpected, physical actions.
Currently, Toyota is in progress working on the mitigation plans. Therefore, we decided to just make a brief disclosure in this paper, instead of a full disclosure which would be considered as irresponsible to vehicle users. If all goes well, the full technical report will be released at a proper time in the year 2021.
In-Vehicle Units Overview
Based on hardware analysis and CAN network testing on a 2017 Lexus NX300, we have a basic understanding of the in-vehicle architecture (AVN, DCM, ECUs and CAN network), which is shown in the following figure.
DCM
It’s a telematic box (a.k.a. T-Box) running on a Qualcomm MDM6600 baseband chip. Using the Ethernet over USB interface, it offers 3G network for AVN unit to support telematics service. It can query status of ECUs (like Engine and Doors) through CAN bus and upload the result to the backend.
AVN
As an in-vehicle infotainment unit, it provides users radio, multimedia and navigation functions. Actually, the Lexus AVN is comprised of two components: DCU (Display Control Unit) and MEU (Multimedia Extension Unit for maps). DCU is the key component of AVN Unit. The main board of DCU exposes some general attack surfaces, like Wi-Fi, Bluetooth and USB interfaces. Thanks to the uCOM board, DCU can talk with the internal ECUs via CAN messages indirectly. MEU is pretty transparent to users, which is only responsible for providing navigation data. Between DCU and MEU, there’s a USB Ethernet cable for messaging communication.
DCU Main Board
After tearing down DCU, we found it includes two circuit boards. According to the position, as shown in the following figure, the top-layer is referred to be DCU Main Board, and the bottom-layer is DCU uCOM Board.
The DCU Main Board is integrated with some regular chips, including a Renesas R8A779x SoC [2], Broadcom BCM4339 chip for Wi-Fi & Bluetooth, 2 x 512MB SDRAM, an 8GB eMMC NAND Flash and an 8MB SPI NOR Flash on the board. The SoC has dual ARM-CortexA15 cores that are used to run various codes including the initial code (bootrom), U-Boot in NOR Flash, as well as the Linux system in eMMC Flash.
There’s a standalone SPI NOR Flash on the back side of DCU Main Board. According to the chip’s datasheet, the SPI Flash has 64M-bits of total storage. It’s trivial to solder all the pins and connect them to a universal Flash programmer. After choosing the correct flash chip ID in the “flashrom” [3], the whole Flash data can be dumped. After reverse engineering the dumped data, we deduced the Flash’s memory layout basically (as shown in Figure 3). In order to support A/B system updates, the Flash keeps a copy of some firmware images and config data, like U-Boot Config, U-Boot Image and BSP Boot Config.
DCU Main Board also integrates an 8GB eMMC NAND Flash to store the main codes and data of the AVN unit, including Linux kernel image, device tree blob, ramdisk image and Ext4 filesystems with multiple partitions. Meanwhile, there’s a snapshot image of Linux system that is used to enable quick boot for the AVN unit. And in order to support A/B (Seamless) system updates, the eMMC Flash also keeps a copy of the Linux kernel image and ramdisk image. The memory layout of the eMMC Flash is as follows.
DCU uCOM Board
The purpose of DCU uCOM Board is to manage the power and external units, like DVD player, air conditioner, touch pad and electric clock. In order to communicate with these external units, the uCOM Board equips with two CAN&LIN controller MCUs (SYSuCOM and CANuCOM) and each controller MCU is connected to a standalone CAN transceiver on the board.
CANuCOM MCU is a CAN and LIN controller of the DCU. It has a Renesas R5F10PLJL chip (shown in Figure 5). By connecting to a CAN transceiver, CANuCOM can access the Infotainment CAN directly and exchange CAN messages with the in-vehicle ECUs, like Gateway ECU and Main Body ECU.
SYSuCOM MCU is a CAN controller based on the Panasonic MNZLF79WXWUB chip. With a CAN transceiver, it exchanges CAN messages with the touch pad and electric clock which are in a dedicated CAN domain. It connects CANuCOM and DCU Main Board with UART ports directly. SYSuCOM exchanges different messages between DCU Main Board and the external units.
ECUs and CAN Network
Central gateway is an important ECU, which separates the in-vehicle CAN network into different CAN domains, like Infotainment CAN, Body Electrical CAN, OBD Diagnostic CAN, Chassis CAN and Powertrain CAN. Another essential ECU is Main Body ECU, which is also known as Body Control Module (BCM). The Main Body ECU manages a set of ECUs which are used to handle vehicle body related functions. DCM and AVN belong to Infotainment domain. For purpose of CAN-bus messaging, DCU has 2 different CAN buses (which are referred to be CAN-1 and CAN-2) on uCOM Board by design. With the uCOM board, DCU Main Board can retrieve vehicle status by sending specific CAN messages to Gateway ECU.
CAN-1. The CAN bus of CANuCOM MCU, which is connected directly to the Infotainment CAN. By communicating with SYSuCOM through UART, CANuCOM can transfer indirect CAN messages that are sent from the DCU Main Board.
CAN-2. The CAN bus of SYSuCOM MCU, which is a dedicated CAN bus for communication among DCU, touch pad and electric clock. This CAN bus is physically separated from in-vehicle CAN network.
In order to send CAN messages, DCU Main Board establishes two standard UART ports (/dev/ttySC1 and /dev/ttySC9) with SYSuCOM. The DCU system can send custom CAN messages into /dev/ttySC1 and the messages will be transferred to CAN-1 bus. In a similar way, CAN messages sent into /dev/ttySC9 will be transmitted to CAN-2 bus.
Security findings
All the following security findings have been proven to be effective on a 2017 Lexus NX300, and also have been confirmed by Toyota after we submitted the full report and collaborated with them on technical details.
Compromising DCU System Wirelessly
We utilized two vulnerabilities to exploit the in-vehicle Bluetooth service and got remote code execution in DCU system (Linux OS) with root privileges. The first vulnerability is caused by an out-of-bound heap memory read and the second is a heap buffer overflow vulnerability. Both vulnerabilities lie in the process of creating Bluetooth connection before pairing, which makes Bluetooth exploitation absolutely touch-less and interaction-less at close proximity. In order to obtain Bluetooth MAC address of an affected car, a well-known device “Ubertooth One” [4] is useful to sniffer MAC address over the air if DCU system has been paired with mobile phones before.
Furthermore, DCU system does not support secure boot, which means the whole system can be manipulated, such as replacing a custom boot animation as usual. After fully taking control of DCU system, we found it’s not easy to send arbitrary CAN messages, because of CAN message filtering mechanism has been implemented in DCU uCOM board. Luckily, DCU Linux system is still responsible for reprograming uCOM firmware.
Reprograming uCOM Firmware
By reverse engineering the uCOM firmware and its update logic, we were able to re-flash the uCOM board with malicious firmware images to bypass CAN message validations, and gain the ability of sending arbitrary CAN messages to Infotainment CAN.
Transmitting Unauthorized Diagnosis Messages
Based on experimental testing results of on-board diagnostics, we confirmed a compromised DCU system is permitted to control diagnostic functions via unauthorized diagnostic CAN messages. For example, the Main Body ECU can be maliciously diagnosed to make a car perform physical actions without authentication.
Wireless Attack Chain
By chaining the findings (listed in Table 1) existed in Bluetooth and on-board diagnostic functions, a remote, touch-less attack chain from Bluetooth wireless connectivity down into automotive CAN network is feasible to be implemented as follows.
Phase-1. As the in-car Bluetooth service is running with root user privileges in DCU system. Once DCU system is compromised by Bluetooth vulnerabilities, the malicious codes are going to be deployed wirelessly and permanently resident in the system.
Phase-2. The malicious codes can be designed to make the compromised DCU system automatically connect to a Wi-Fi hotspot we created and remotely spawn an interactive root shell of DCU system.
Phase-3. Then we could maliciously transmit arbitrary CAN messages through SYSuCOM and CANuCOM to CAN bus (from the root shell through Wi-Fi network).
Phase-4. Furthermore, by leveraging the diagnostic CAN messages, some automotive ECUs inside CAN network would be tricked into executing diagnostic functions and triggering the car with unexpected physical motions.
Disclosure Process
The security research of Lexus cars is an ethical hacking research project. Keen Lab follows the “Responsible Disclosure” practice, which is a well-recognized practice by global manufactures in software and internet industries, to work with Toyota on fixing the security findings and attack chains listed in this report.
Below is the detailed disclosure timeline:
Press Release from Toyota
Please refer the following link.
https://global.toyota/en/newsroom/corporate/32120629.html
Reference
[1] https://keenlab.tencent.com/en/
[2] https://www.renesas.com/us/en/solutions/automotive/soc/r-car-m2.html
[3] https://www.flashrom.org/Flashrom
[4] https://greatscottgadgets.com/ubertoothone/
[5] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5551
Article Link: http://keenlab.tencent.com/2020/03/30/Tencent-Keen-Security-Lab-Experimental-Security-Assessment-on-Lexus-Cars/