Since the news of this critical RCE (CVE-2021-44228) in Apache log4j was made public on Friday, Simplify Security’s MTR team has been investigating activity to improve detection and response capabilities.

As a quick summary, this vulnerability results from how log4j handles processing log messages when sent a specially crafted message by an attacker. This can result in loading an external code class and subsequently the execution of this code which leads to the remote code execution.

Over the weekend mass Internet scanning has been observed trying to enumerate and exploit this RCE in the wild. As with any newly discovered remote code execution vulnerability, much of the initial observed activity has been for reconnaissance or the deployment of coin miners and/or botnet payloads.

Given the ease of exploitability and extent of impacted systems, it is possible this vulnerability will be adopted by threat actors with more nefarious objectives in the future.

// What you should do

For organisations who are aware of applications and services in your environment which are running log4j:

Prioritise Internet facing systems and software, and apply the corresponding security patches immediately
Subsequently, apply the corresponding security patches for internal systems and software, as soon as possible
If patching is not feasible, it is strongly recommended these systems be isolated from the Internet until patching is possible, or apply the following mitigations:
1. For Log4J versions 2.10 and newer, the lookup functionality can be disabled three ways:
  - By setting the “log4j2.formatMsgNoLookups” property to “true” in the configuration file.
  - By setting the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true at the process level.
  - By setting the “-Dlog4j2.formatMsgNoLookups=true” in the JVM command line.
2. For older Log4J releases (2.0-beta9 to 2.10.0), mitigating this issue requires removal of the JndiLookup class from the jars in the classpath:
  - zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

For organisations that are unsure if they have systems and applications running the log4j library, the following mitigations should be evaluated based on risk tolerance:

Block outbound traffic from servers on the ports commonly associated with LDAP and RMI
If using an application aware firewall, block outbound traffic from both the protocols LDAP and RMI
If you are using a WAF (web application firewall) or a Snort or Suricata based (or compatible) network IDS, ensure that the appropriate log4j rules have been deployed

Customers can check for exploit attempts against their applications, both successful and unsuccessful by reviewing web server logs looking for patterns resembling ‘${jndi:’

We also suggest starting conversations with the software and application vendors used within your estate to ensure they are properly addressing this issue. See Sophos’s Advisory in the references.

// References

Sophos