Log4j is a popular and widely spread java logging tool incorporated in many services across the web making potentially everyone using Log4j a possible victim, including Apple, Twitter, Steam, Tesla and probably many other car manufacturers and suppliers. The vulnerability rated with a severity score of 10 may not directly affect the vehicles driving on the streets, however, it is a serious threat to the enterprise infrastructure to which these vehicles connect.

About the vulnerability: Apache Log4j is widely used in many systems and applications as it is an easy-to-use and open-source logging tool. In order to provide informative logging messages, the library allows online lookups via JNDI (Java Naming Directory Interface), which is used to execute, for instance, an LDAP request to resolve the user ID to the corresponding username. The problem causing this vulnerability is that these requests can be triggered by the data, which is being logged, enabling an attacker to perform remote code execution by crafting a string that points to an attacker-controlled endpoint.

The timeline: The vulnerability was found by the Alibaba Cloud Security team which notified Apache about their findings on November 24th. Yet, the first proof of concept exploiting this vulnerability was posted online two weeks later, on December 9th and was quickly exploited against servers of the popular game Minecraft. Through this game, attackers were able to perform a remote code execution attack by manipulating the log content, when, for instance, posting chat messages. The vulnerability was, however, already exploited before the release of the proof of concept. The CEO of Cloudflare posted on Twitter that they found evidence that the vulnerability was exploited from December 1st [1]. In the meantime, Apache released an update to version 2.16.0 and provides a mitigation solution for older versions of log4j [2]. Nevertheless, it is safe to say that this vulnerability will haunt us for quite some time.

Like Free Wortley, the CEO of the security platform LunaSec, said, “It’s a design failure of catastrophic proportions,” [3]; highlighting that Log4j was implemented as specified. Since the past days, organisations work on identifying whether they are using Log4j and consequently where they are using it. This is not necessarily a trivial task and highlights the need for tools managing open-source dependencies and vulnerability management solutions.

Relevant news articles:

[1] https://twitter.com/eastdakota/status/1469800951351427073
[2] https://logging.apache.org/log4j/2.x/security.html
[3] https://www.wired.com/story/log4j-flaw-hacking-internet/

Written by Thomas Rosenstatter