Log4j Vulnerability: Impact Analysis

By now, you’ve likely heard of the latest Java-based vulnerability CVE-2021-44228, a critical zero-day vulnerability related to Apache Log4j Java logging library. In our video below, our Bishop Fox offensive security experts (Joe Demesy, Dan Petro, Justin Rhinehart, and Ori Zigindere) dive into the impact of the vulnerability and what they’re seeing.

Affecting everything from enterprise software to web applications and well-known consumer products, CVE-2021-44228 impacts any organization using the Apache Log4j framework including Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and others.

Published on GitHub on December 9, 2021, the first proof-of-concept exploit enables unauthenticated remote code execution resulting in complete system takeover. On December 10, 2021, public and private cyber intelligence groups around the world reported the first usage of the exploit, identifying massive scanning from multiple hosts for servers using vulnerable versions of Apache Log4j. Receiving a rating of 10 on the CVSS scale, Apache has already released Log4j 2.15.0 to address the maximum severity rating. However, given the pervasive nature of the Java logging library and multiple points of entry (the extent of which is not known yet), Log4j presents significant challenges for security teams to address potentially numerous points of entry.

While all organizations are encouraged to quickly act on Apache’s latest release, Bishop Fox’s Adversarial Operations Team is already researching open-source projects that appear to use Log4j by default. The list below is likely incomplete at this time; however, it begins to highlight the breadth of systems that can be affected:

• Elasticsearch
• Grails
• Hadoop
• Kafka
• Kibana
• Solr
• Spark
• Struts
• Tapestry
• Wicket

The following projects don't appear to use Log4j by default, though they may optionally be configured to use it:

• ATG
• Dropwizard
• Hibernate
• Java Server Faces
• Spring Framework
• Tomcat

Like Heartbleed and Shellshock, we suspect the number of vulnerable environments to grow over the coming weeks. The list above is available on our GitHub Gist and will be updated in real time as new systems are identified.

Detecting Log4j RCE Exploitation

The following commands and rules can be used to search for exploitation attempts against vulnerable versions of log4j:

This command searches for exploitation attempts in uncompressed files in folder /var/log and all sub folders

sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log

This command searches for exploitation attempts in compressed files in folder /var/log and all sub folders

sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+'

Preliminary YARA rules (work in progress)

rule EXPL_Log4j_CVE_2021_44228_Dec21_Soft {
   meta:
      description = "Detects indicators in server logs that indicate an exploitation attempt of CVE-2021-44228"
      author = "Florian Roth"
      reference = "https://twitter.com/h113sdx/status/1469010902183661568?s=20"
      date = "2021-12-10"
      score = 60
   strings:
      $x1 = "${jndi:ldap:/"
      $x2 = "${jndi:rmi:/"
      $x3 = "${jndi:ldaps:/"
      $x4 = "${jndi:dns:/"
   condition:
      1 of them
}

rule EXPL_Log4j_CVE_2021_44228_Dec21_Hard {
   meta:
      description = "Detects indicators in server logs that indicate the exploitation of CVE-2021-44228"
      author = "Florian Roth"
      reference = "https://twitter.com/h113sdx/status/1469010902183661568?s=20"
      date = "2021-12-10"
      score = 80
   strings:
      $x1 = /\$\{jndi:(ldap|ldaps|rmi|dns):\/[\/]?[a-z-\.0-9]{3,120}:[0-9]{2,5}\/[a-zA-Z\.]{1,32}\}/
      $fp1r = /(ldap|rmi|ldaps|dns):\/[\/]?(127\.0\.0\.1|192\.168\.|172\.[1-3][0-9]\.|10\.)/
   condition:
      $x1 and not 1 of ($fp*)
}

rule SUSP_Base64_Encoded_Exploit_Indicators_Dec21 {
   meta:
      description = "Detects base64 encoded strings found in payloads of exploits against log4j CVE-2021-44228"
      author = "Florian Roth"
      reference = "https://twitter.com/Reelix/status/1469327487243071493"
      date = "2021-12-10"
      score = 70
   strings:
      /* curl -s  */
      $sa1 = "Y3VybCAtcy"
      $sa2 = "N1cmwgLXMg"
      $sa3 = "jdXJsIC1zI"
      /* |wget -q -O-  */
      $sb1 = "fHdnZXQgLXEgLU8tI"
      $sb2 = "x3Z2V0IC1xIC1PLS"
      $sb3 = "8d2dldCAtcSAtTy0g"
   condition:
      1 of ($sa*) and 1 of ($sb*)
}

It’s important to note that security teams must be logging data before it hits the application (and Log4j) for the Yara rules to work. Credit for these techniques and real-time updates can be located here: https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b.

For more information on Log4j and exploitation of Java vulnerabilities, please join the Bishop Fox webcast on Tuesday December 14th @ 3:00 p.m. EST.