Log4j-core 2.6.1: Fix The 6 Vulnerabilities Now!
Hey guys! Today, we're diving deep into a critical issue affecting the log4j-core-2.6.1.jar library. This version has a whopping six vulnerabilities, with the most severe clocking in at a terrifying 10.0. If you're using this library, it's super important to understand the risks and take action ASAP. Let's break down what you need to know. This article provides comprehensive information about the vulnerabilities identified in log4j-core-2.6.1.jar, their potential impact, and recommended remediation steps. This information is crucial for developers and security professionals to secure their applications.
Vulnerable Library - log4j-core-2.6.1.jar
Before we get started, here’s a quick overview of the vulnerable library:
- Library: Apache Log4j Implementation
 - Home Page: http://www.apache.org
 - Dependency File Path: 
/bin/target/classes/META-INF/maven/org.whitesource/log4j-netty-sample/pom.xml 
This library is a direct dependency, meaning it's included directly in your project. Now, let's jump into the details of each vulnerability.
Findings
Here’s a summary table of the vulnerabilities found:
| Finding | Severity | 🎯 CVSS | Exploit Maturity | EPSS | Library | Type | Fixed in | Remediation Available | |--------------------------|------------|---------|------------------|---------|----------------------|--------|----------|-----------------------| | CVE-2021-44228 | 🟣 Critical | 10.0 | High | 94.4% | log4j-core-2.6.1.jar | Direct | 2.12.2 | ✅ | | CVE-2017-5645 | 🟣 Critical | 9.8 | Not Defined | 94.0% | log4j-core-2.6.1.jar | Direct | 2.8.2 | ✅ | | CVE-2021-45046 | 🟣 Critical | 9.0 | High | 94.3% | log4j-core-2.6.1.jar | Direct | 2.12.2 | ✅ | | CVE-2021-44832 | 🟠Medium | 6.6 | High | 35.2% | log4j-core-2.6.1.jar | Direct | 2.12.4 | ✅ | | CVE-2021-45105 | 🟠Medium | 5.9 | High | 66.2% | log4j-core-2.6.1.jar | Direct | 2.12.3 | ✅ | | CVE-2020-9488 | 🟡 Low | 3.7 | Not Defined | < 1% | log4j-core-2.6.1.jar | Direct | ch.qos.reload4j:reload4j:1.2.18.3 | ✅ |
Understanding Vulnerability Severity and Impact
Severity levels are crucial for prioritizing remediation efforts. Critical vulnerabilities, like those with a CVSS score of 9.0 or higher, demand immediate attention due to their potential for significant impact. Medium and low severity vulnerabilities should also be addressed, but can be scheduled based on risk assessment and available resources. Exploit Maturity indicates how readily a vulnerability can be exploited. High exploit maturity means that the vulnerability has known exploits available, increasing the risk. EPSS (Exploit Prediction Scoring System) provides a probability of exploitation, helping to further prioritize vulnerabilities. A high EPSS score, such as 94.4%, indicates a very high likelihood of the vulnerability being exploited in the wild. Understanding these metrics allows for a more informed and strategic approach to vulnerability management.
Details
Let's dive into the details of each vulnerability to understand the risks and how to mitigate them.
CVE-2021-44228
- Severity: Critical (10.0)
 - Description: This is the infamous Log4Shell vulnerability. Apache Log4j2 versions 2.0-beta9 through 2.15.0 are vulnerable to remote code execution (RCE) due to JNDI features not protecting against attacker-controlled LDAP and other JNDI-related endpoints. Basically, if an attacker can control log messages or parameters, they can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
 - Exploit Maturity: High
 - EPSS: 94.4%
 - Fix: Upgrade to version 2.12.2 or higher. Version 2.16.0 completely removes this functionality.
 - Why it matters: This vulnerability allows for complete system compromise. Attackers can gain full control over affected servers, making it a top priority to fix. This vulnerability is particularly concerning because it is easy to exploit and has been widely exploited in the wild. The high EPSS score further underscores the urgency of addressing this issue.
 
CVE-2017-5645
- Severity: Critical (9.8)
 - Description: In Apache Log4j 2.x before 2.8.2, using the TCP or UDP socket server to receive serialized log events can allow a specially crafted binary payload to execute arbitrary code upon deserialization.
 - Exploit Maturity: Not Defined
 - EPSS: 94.0%
 - Fix: Upgrade to version 2.8.2 or higher.
 - Impact: This vulnerability allows for remote code execution when the application is configured to receive serialized log events over TCP or UDP. Attackers can leverage this to execute arbitrary code on the server. Ensuring that your Log4j version is up-to-date is crucial to mitigate this risk.
 
CVE-2021-45046
- Severity: Critical (9.0)
 - Description: The fix for CVE-2021-44228 in Log4j 2.15.0 was incomplete. Attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern, leading to information leak and remote code execution in some environments, and local code execution in all environments.
 - Exploit Maturity: High
 - EPSS: 94.3%
 - Fix: Upgrade to version 2.12.2 (Java 7) or 2.16.0 (Java 8).
 - Why it matters: This is a bypass of the initial fix for Log4Shell. It highlights the importance of staying updated with the latest security patches, as initial fixes may sometimes be incomplete. The high EPSS score indicates a significant risk of exploitation, making it essential to apply the necessary updates.
 
CVE-2021-44832
- Severity: Medium (6.6)
 - Description: Apache Log4j2 versions 2.0-beta7 through 2.17.0 are vulnerable to RCE when a configuration uses a JDBC Appender with a JNDI LDAP data source URI and an attacker controls the target LDAP server. The fix limits JNDI data source names to the java protocol.
 - Exploit Maturity: High
 - EPSS: 35.2%
 - Fix: Upgrade to version 2.12.4, 2.17.1, or 2.3.2.
 - Why it matters: This vulnerability demonstrates the risk of using JDBC Appenders with JNDI LDAP data sources. If an attacker can control the LDAP server, they can execute arbitrary code. While the severity is medium, the high exploit maturity means there are known ways to exploit this.
 
CVE-2021-45105
- Severity: Medium (5.9)
 - Description: Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted.
 - Exploit Maturity: High
 - EPSS: 66.2%
 - Fix: Upgrade to version 2.12.3, 2.17.0, or 2.3.1.
 - Impact: This vulnerability can lead to denial of service (DoS) attacks. By exploiting uncontrolled recursion, an attacker can cause the application to consume excessive resources, leading to a crash. Promptly applying the fix is crucial to prevent potential service disruptions.
 
CVE-2020-9488
- Severity: Low (3.7)
 - Description: Improper validation of certificates with host mismatch in the Apache Log4j SMTP appender. This could allow an SMTPS connection to be intercepted by a man-in-the-middle attack, potentially leaking log messages sent through the appender.
 - Exploit Maturity: Not Defined
 - EPSS: < 1%
 - Fix: Upgrade to Apache Log4j 2.12.3, 2.13.1 or use 
ch.qos.reload4j:reload4j:1.2.18.3. - Why it matters: While the severity is low and the EPSS score is minimal, it's still important to address. Man-in-the-middle attacks can compromise sensitive data transmitted through the SMTP appender. This vulnerability highlights the need for proper certificate validation in secure connections.
 
Remediation
The primary solution for all these vulnerabilities is to upgrade your Log4j version. Here’s a quick recap of the recommended versions:
- CVE-2021-44228: Upgrade to 2.12.2 or 2.16.0
 - CVE-2017-5645: Upgrade to 2.8.2
 - CVE-2021-45046: Upgrade to 2.12.2 or 2.16.0
 - CVE-2021-44832: Upgrade to 2.12.4, 2.17.1, or 2.3.2
 - CVE-2021-45105: Upgrade to 2.12.3, 2.17.0, or 2.3.1
 - CVE-2020-9488: Upgrade to 2.12.3, 2.13.1 or use 
ch.qos.reload4j:reload4j:1.2.18.3 
Upgrading is the most effective way to mitigate these risks. Make sure to test the new version in a non-production environment before deploying it to production.
Additional Tips for Secure Log4j Configuration
- Disable JNDI Lookup: If you can't upgrade immediately, disable JNDI lookup by setting the 
log4j2.formatMsgNoLookupssystem property totrue. You can do this by adding-Dlog4j2.formatMsgNoLookups=trueto the Java command line. - Monitor Logs: Keep a close eye on your logs for any suspicious activity. Look for unusual JNDI requests or other anomalies.
 - Implement Network Segmentation: Isolate your systems to limit the potential impact of a successful exploit.
 - Use a Web Application Firewall (WAF): A WAF can help detect and block malicious requests targeting Log4j vulnerabilities.
 - Regularly Update Dependencies: Keep all your dependencies up to date to benefit from the latest security patches.
 
Conclusion
The log4j-core-2.6.1.jar library has multiple critical vulnerabilities that can lead to severe consequences, including remote code execution and denial of service. Upgrading to the latest version is crucial for mitigating these risks. Stay vigilant, monitor your systems, and keep your dependencies updated to maintain a secure environment. By taking these steps, you can significantly reduce your exposure to potential attacks. Remember, security is an ongoing process, and staying informed is key to protecting your applications and data.