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




Rumble Security

Recent blog posts

The Forgetting Curve – Security Training

The Forgetting Curve – Security Training

It’s something we all know instinctively, if a whole load of new information is thrown at you, your recall of it will be somewhat cloudy one week later. This is exactly what German psychologist Hermann Ebbinghaus showed back in 1885 when he developed the forgetting...

Possible Okta Breach By Threat Actor

Okta has provided additional information on the timeline of the incident affecting their services. In summary, the Okta service confirmed the breach by Lapsus$ group yesterday. As per Okta has confirmed 'The Okta service is fully operational, and there are no...

CVE-2021-44228 Apache Log4j 2 RCE – log4s

CVE-2021-44228 Apache Log4j 2 RCE – log4s

On December 9, 2021, the Apache Log4j project’s GitHub publicly disclosed a high severity vulnerability that impacts Apache Log4j 2 versions 2.0 to 2.14.1.   The vulnerability allows for unauthenticated remote code execution on Log4j 2, an open-source Java logging...