Log4j Zero-Day Exploit: The Most Critical Vulnerability of the Decade That Puts Countless Servers at Risk

Log4j Zero-Day Exploit The Most Critical Vulnerability of the Decade That Puts Countless Servers at Risk

Background

The Apache Software Foundation released an emergency security update on 10th December 2021 to patch a vulnerability in Log4j (version 2) nicknamed Log4Shell. It was discovered on 9th December as a 0-day exploit with publicly available POC. The Log4j Java library provides logging capabilities. The vulnerability initially disclosed to Apache several weeks ago by Alibaba’s security team is named CVE-2021-44228. It is claimed to be severely critical with a 10–resides CVSS score in Log4J’s lookup capability in combination with JNDI (Java Naming and Directory Interface). The Apache Software Foundation released the 2.15.0 version to fix this remote code execution vulnerability (CEV).

Impact

The open-source logging library developed by the Apache Software Foundation is used by millions of applications of both small and large sizes. Some of these applications are enormously popular, such as — Elasticsearch, Elastic Logstash, GrayLog2, HELK, Wazuh, Minecraft, Neo4J, many Apache projects (Druid, Dubbo, Flink, Flume, Hadoop, Kafka, Solr, Spark, Struts, Tapestry, Wicket), many VMware products (Horizon, vCenter, vRealize, HCX, NSX-T, UAG, Tanzu), Grails, and more. The broad popularity of Log4J–coupled with the relative ease of exploiting this vulnerability–creates potential conditions for far-reaching exploitation (similar to Shellshock).

Referring to one of the Github attack surface trackers, major players such as Apple, Amazon, Twitter, Cloudflare, and many more are confirmed to be vulnerable to Log4j2.

Mitigation

According to Apache guidelines, even if you are unable to upgrade to the 2.15.0 release, you can still mitigate this in 2.10.0 or higher with the below configuration tweaks:

  • Sett “log4j2.formatMsgNoLookups” property to “true”
  • Set environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true
  • Set “-Dlog4j2.formatMsgNoLookups=true” in the JVM parameters

For older releases from Apache versions 2.0-beta9 to 2.10.0, you can remove the JndiLookup class from the jars in the classpath.

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Apart from the above modifications, you could take the below preventive measures:

  • Implement a Web Application Firewall (WAF) to protect applications from various attacks
  • Restrict outbound connections made by application servers at Firewall or WAF
  • Periodic vulnerability assessment to identify and patch vulnerabilities or configuration weaknesses

Post Exploitation Detection

One can use several approaches for threat hunting to identify exploitation attempts made by threat actors. Here are some of them:

To exploit the Log4j vulnerability, the vulnerable java component needs to make an outbound connection attempt to LDAP, RMI or standard DNS. Monitoring this attempt for connection using the below detection rules can indicate any possible attempts made by the adversaries:

  • Monitor all outbound connections made by parent process “java” with child process containing “sh, bash, ksh, tcsh, curl, perl, python, ruby, pho, or wget.”

sequence by host.id with maxspan=1m

[network where event.action == “connection_attempted” and

process.name : “java” and

destination.port in (1389, 10389, 10636, 636, 389, 1099, 53, 5353)] by process.pid

[process where event.type == “start” and

process.parent.name : “java” and

process.name : (“sh”,

“bash”,

“dash”,

“ksh”,

“tcsh”,

“zsh”,

“curl”,

“perl*”,

“python*”,

“ruby*”,

“php*”,

“wget”)] by process.parent.pid

  • Well-integrated SIEM (Security Information and Event Management) or XDR (Extended Detection and Response) solutions can ingest the logs generated either from Web Application Firewall (WAF), Reverse Proxy (Such as NGINX), or Web Servers (Apache/IIS). These are important logs to check if any attempts were made to exploit the vulnerable application.

Below are the strings that could be matched in the log statements for user-agent or cs-User-Agent or cs-uri or cs-referrer contains:

    • ‘${jndi:ldap:/’
    • ‘${jndi:rmi:/’
    • ‘${jndi:ldaps:/’
    • ‘${jndi:dns:/’
    • ‘/$%7bjndi:’
    • ‘%24%7bjndi:’
    • ‘$%7Bjndi:’
    • ‘%2524%257Bjndi’
    • ‘%2F%252524%25257Bjndi%3A’
    • ‘${jndi:${lower:’
    • ‘${::-j}${‘
    • ‘${jndi:nis’
    • ‘${jndi:nds’
    • ‘${jndi:corba’
    • ‘${jndi:iiop’
    • ‘${${env:BARFOO:-j}’
    • ‘${::-l}${::-d}${::-a}${::-p}’
    • ‘${base64:JHtqbmRp’
  • Searching for all the known footprints in the log files of your applications using a manual approach is another best possible approach. This GitHub repository lists all the commands that you can use to check compressed or non-compressed logs files within your Linux or Windows servers.
  • The Apache Log4j vulnerability affects versions 2.0 to 2.14.1. The information of all vulnerable versions is given A detection rule could be created to detect any file with matching hashes:
Apache Log4j vulnerability versions

SharkStriker Customers

It was a really extended weekend for our security experts. SharkStriker’s 24/7 security operations center has worked extensively on this major security event. Below is a list of activities done on a war foot level:

  • Quick vulnerability assessment on all managed assets to identify vulnerable applications and servers
  • On-going live and retrospective threat hunting process to detect any attempt made by the threat vectors
  • Continuous blocking of known threat actors at perimeter and application level