K. Dorozhkina Security event auditing of infotainment and communications control: implementation approaches Karina Dorozhkina Kaspersky, 39A/2 Leningradskoe Shosse, 125212, Moscow, Russian Federation [email protected] Abstract. Today’s cars are deservedly called smart because they are no longer merely vehicles but complex devices communicating with each other and the outside world. With integrated infotainment (head unit ECU or HU) and com- munication (telematics ECU or TCU) control domains, they offer numerous ways to make the driver's life more comfortable. HUs and TCUs are powered by Linux or Android OS, similar to your mobile phone or tablet, and their hardware performance is more on a par with PCs than embedded systems. But as well as greater convenience, these enhanced vehicle capabilities bring greater responsibilities as the attack surface grows. For instance, it has been shown by several research groups that unauthorised remote access can result in CAN bus injection. Countering complex cyberattack scenarios requires security event monitoring inside the vehicle’s ECUs and the ability to deliver this information to vehicle operators (e.g., OEM or fleet owner) for incident discovery and re- sponse. Continuous asset monitoring in Security Operations Centers became the standard in enterprise-grade security with Endpoint Detection & Response solu- tions (EDR). Upcoming automotive cybersecurity regulations (UNECE WP.29/GRVA and ISO/SAE 21434) also cover this process. This paper gives a detailed description of security events from HU and TCU critical for malicious activity analysis as well as key mechanisms for their extraction. The target plat- forms are automotive embedded Linux distributions such as Automotive Grade Linux (AGL) and GENIVI. Mature systems such as udev and Linux Auditing will be reviewed along with the relatively new extended Berkeley Packet Filter (eBPF). Keywords: Head unit, Telematics, Linux, Audit, eBPF 1 Introduction Complex and comprehensive vehicle attack scenarios include payload delivery to cloud and internally connected ECUs (like head units and telematic control units) through MiTM attacks or external interface exploitation, long-term persistence of malicious code in the compromised ECUs and its lateral movement to other domains. The target of such attacks are unlikely to be individuals, but rather enterprises with business processes tightly connected with vehicle fleets. For example, in 2018 and 16 Security event auditing of infotainment and communications control 2 2019 successful cyberattacks were carried out against large car-sharing fleets in the US and Australia. Infotainment control and telematics provide the driver with a lot of useful func- tionality. It’s hard to imagine driving now without navigation maps or a USB port for a device with your favourite music. But, more importantly, it’s not just entertainment that can be provided by these ECUs – safety functions such as crash reporting and emergency warning by eCall or over-the-air software update (OTA) are key features of modern vehicles. All this functionality leads to a growing number of external inter- faces in today’s smart cars (Fig. 1). Fig. 1. External interfaces of a smart car This transformation from a simple vehicle to a sophisticated connected device has a downside – a growing number of potential vulnerabilities. With the ability to con- nect to the outside world, HUs and TCUs can be used as an entry point to car inter- nals. These domains obviously need to be isolated from other domain networks. But it 17 K. Dorozhkina 3 turns out that in the real world the situation isn’t so clear cut and often it’s possible to gain access to the powertrain or body control via CAN bus, or hacking the TCU or HU via external interfaces. The main aim here is to make infotainment and communication control more se- cure and more resistant to potential attacks. Leaving prevention functionality for a future talk, this paper focuses on the important function of secure auditing. This func- tion makes it possible for incident specialists to analyse malicious activity and report to a driver or OEM. Of course, this is not the only mechanism that should be used. Strong authentication and authorisation, strict policies and critical updates to remove old vulnerabilities should all be applied. But secure auditing is also an important part of car protection, giving an understanding of what went wrong and how. And it’s not just for cases of remote hacking – secure auditing can assist insurance companies with forensic analysis in cases of physical theft [1]. Numerous studies [1, 2] as well as upcoming automotive cybersecurity regulations (UNECE WP.29/GRVA and ISO/SAE 21434) stipulate that security logging is an obligatory part of securing a modern car. But there is no definition of which events are important and should be logged. The aim of this paper is to address the theme of security events in detail. Before we go into an in-depth explanation of security events and extraction meth- ods, let’s define the scope of potential infotainment and communication control oper- ating systems (OS). Security event groups are independent from the OS, but the mechanisms for collecting events may differ. It’s impossible to describe all cases, so this paper will concentrate mainly on two popular automotive Linux distributives, Automotive Grade Linux (AGL) and GENIVI, which are both based on the yocto framework. Renesas R-Car H3 board, using ARM architecture, was used as a refer- ence hardware platform. 2 Security event groups 2.1 Defining the scope OSs such as GENIVI, AGL or QNX are highly complex software with a non-stop event flow. It’s impossible to collect and report all system activity due to disk space limitations or network bandwidth if we want to send these logs to the cloud. Moreo- ver, we need to filter out events to simplify future analysis and collect only those events that relate to possible incidents. Redundant event collecting can also lead to performance degradation. For example, we aren’t interested in open(), read() and write() syscalls for all filesystem nodes, but only for those that have restricted access, such as configuration files. Defining the full scope of security events requires a threat model covering all possible attack surfaces [1]. But for simplicity and as a case study for this paper, let’s review an existing Tesla attack (Fig. 2) [3]. The entry point was via Wi-Fi spoofing and the subsequent exploiting of a vulner- ability in a WebKit browser. In this context, the collecting of network events seems reasonable. Another step in this attack was patching setresuid() syscall to get the root privilege. This in turn leads to the idea of collecting specific syscalls information 18 Security event auditing of infotainment and communications control 4 related to privilege escalation and processes creation. Further manipulations led to access being gained to the gateway through its reprogramming. This indicates that the filesystem is heavily used in attempts by the intruder to achieve persistence. From this case we see three types of security events: network events, syscall events related to privilege escalation, and process creation and filesystem events. Fig. 2. TESLA attack scheme. As was mentioned above, it’s not only remote attacks that are possible but also physical attacks involving theft or cases of car sharing. TCU and HU external inter- face activity such as USB activity must be recorded and it adds one more event group for connected device information. The following sections will describe which mecha- nisms can be used for extracting these events. 2.2 Enabling auditing systems in yocto distributions As our target systems are AGL and GENIVI distributions, both based on the yocto framework, a custom setup for all systems is necessary that will be described below. Almost all systems for security auditing are disabled in yocto images built from scratch. So, it’s necessary to define a custom layer with a kernel and image recipes for adding extra kernel config options and deploying the required packages [11]. Below are some examples. Additional kernel config example for Linux Auditing system: CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y CONFIG_INTEGRITY_AUDIT=y Additional custom yocto layer packages: IMAGE_INSTALL_append += " audit" IMAGE_INSTALL_append += " audit auditd " 19 K. Dorozhkina 5 6 IMAGE_INSTALL_append += " udev-rules " IP address assigning to USB to Ethernet adapter: IMAGE_INSTALL_append += " iproute2 “ network_broadcast_address=169.254.255.255 network_interface_name=eth0 network_local_address=169.254.245.57 network_address_family=AF_INET network_address_action=added network_interface_address=169.254.245.57 network_address_mask_length=16 network_address_scope=global Such network events can serve as the start point in incident investigation as they relate to external interface activity. After a malicious connection is established an attacker may try to invoke syscalls like setresuid() in the Tesla example or launch binaries. It is then interesting to analyse the syscalls sequence and process tree crea- tion. 2.4 Syscall events The Linux Auditing system was first introduced in kernel version 2.6 and is available in all the latest distributions, including GENIVI and AGL. The core functionality is Fig. 3. Security event groups and collecting methods the logging of kernel activity for future incident investigation. As is shown in this paper, using only this mechanism is not enough because it doesn’t cover the full net- 2.3 Network events work or device activity (Fig. 3), but can give a lot of information about syscalls used, including process creation events. Based on these events we can track the whole pro- Linux distributions such as Genivi and AGL use the Netlink service for communica- cess tree with arguments and analyse executed sequences. For example, we can detect tion between the kernel and user space. This allows communication with the rtnetlink spoofed firmware updates and its initiator or compare the current process flow with a system that provides read/write access to routing tables.