In the popular Java logging library log4j (version 2) a new critical zero-day vulnerability was discovered recently, and this zero-day is a Remote Code Execution (RCE) flaw that could be exploited by the threat actors by logging a certain string.
Due to this zero-day flaw, the home users and enterprises are exposed to ongoing remote code execution attacks. Log4j is widely utilized by both enterprise apps and cloud services since it is a Java-based logging utility that is developed by the Apache Foundation.
Flaw profile
- CVE ID: CVE-2021-44228
- Flaw Type: Remote Code Execution (RCE) flaw
- Description: Apache Log4j2 <=2.14.1 JNDI features used in the configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
- Source: Apache Software Foundation
- Severity: Critical
- Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
- Credit: This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.
Affected versions of Apache log4j2
Here we have mentioned below the affected versions of Apache log4j2:-
.png
)
- 2.0 <= Apache log4j <= 2.14.1
Flaws detected and fixed
Here below we have mentioned all the flaws that are detected and already fixed:-
- CVE-2021-44228 is fixed in Log4j 2.15.0.
- CVE-2020-9488 is fixed in Log4j 2.13.2.
- CVE-2017-5645 is fixed in Log4j 2.8.2.
PoC – Apache log4j
Who is affected?
This critical zero-day flaw has affected several popular services and apps like:-
- Steam
- Apple iCloud
- Minecraft
- Amazon
- Cloudflare
In Apple’s servers, a simple change in iPhone’s name triggers the vulnerability. However, after the discovery of this severe zero-day flaw several affected services have already started fixing their usage of log4j2.
While the LDAP attack vector has not affected the JDK versions greater than:-
- 6u211
- 7u201
- 8u191
- 11.0.1
Since the com.sun.jndi.ldap.object.trustURLCodebase is set to false in these versions due to which using LDAP attack vector the JNDI is not able to load remote code.
Temporary & Permanent Mitigation
Experts have recommended users to follow immediately all the mitigation properly, and here they’re:-
Temporary Mitigation:
- Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files (only works on versions >= 2.7).
OR
- Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class.
Permanent Mitigation:
Without the vulnerability, the latest version 2.15.0 of log4j has been released, and on the Maven Central, the log4j-core.jar is available. Moreover, from the Apache Log4j Download page, the latest release can also be downloaded.
The CVE-2021-44228 can only be exploited if the log4j2.formatMsgNoLookups parameter is set to false. As in Log4j 2.15.0 release this parameter is set to true, simply to prevent attacks.
This implies that the Log4j users who have upgraded to version 2.15.0 and then set the flag to false will again become vulnerable to attacks.
While the users who have not updated yet, and have set the flag to true, will be able to block these attacks even on the older versions as well. However, currently, all the older versions are vulnerable, where by default this parameter is set to “false.”
For this reason, the threat actors are actively scanning the network in search of apps that are vulnerable to Log4Shell, so, at this point to stay safe, it’s highly recommended by the experts to immediately apply all available patches and follow the mitigations properly.
You can follow us on Linkedin, Twitter, Facebook for daily Cybersecurity and hacking news updates.
