Zero-day flaw – Log4j

December 14, 2021
|In Security
|By Security Team

Threat actors are actively weaponizing unpatched servers affected by the newly identified “Log4Shell” vulnerability in Log4j to install cryptocurrency miners, Cobalt Strike, and recruit the devices into a Muhstik and Mirai botnets, even as telemetry signs point to exploitation of the flaw nine days before it even came to light.

The internet has a fast-spreading, malignant exploit known as the Apache Log4j logging library exploit – that’s been rapidly mutating and attracting swarms of attackers. Most of the attacks focus on cryptocurrency mining done on victims’ dimes, as seen by security firms. Attackers are actively trying to install far more dangerous malware on vulnerable systems as well.

The Log4j flaw (also now known as “Log4Shell”) is a zero-day vulnerability (CVE-2021-44228) that first came to light on December 2nd week, with warnings that it can allow unauthenticated remote code execution and access to servers.

The complete list of flaws discovered to date in the logging framework after the original Log4Shell remote code execution bug was disclosed is as follows —

  • CVE-2021-44228 (CVSS score: 10.0) – A remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.14.1
  • CVE-2021-45046 (CVSS score: 9.0) – An information leak and remote code execution vulnerability affecting Log4j versions from 2.0-beta9 to 2.15.0, excluding 2.12.2.
  • CVE-2021-45105 (CVSS score: 7.5) – A denial-of-service vulnerability affecting Log4j versions from 2.0-beta9 to 2.16.0.
  • CVE-2021-4104 (CVSS score: 8.1) – An untrusted deserialization flaw affecting Log4j version 1.2.

Log4j is used in many forms of enterprise and open-source software, including cloud platforms, web applications and email services, meaning that there’s a wide range of software that could be at risk from attempts to exploit the vulnerability.

Description of log4j Vulnerability:

The Apache log4j library allows for developers to log various data within their application. In certain circumstances, the data being logged originates from user input. Should this user input contain special characters and be subsequently logged within the context of log4j, the Java method lookup will finally be called to execute the user-defined remote Java class in the LDAP server. This will in turn lead to RCE on the victim server that uses the vulnerable log4j 2 instances.

Affected Version

  • Apache Log4j 2.x <= 2.15.0-rc1

Affected Software

A significant number of Java-based applications are using log4j as their logging utility and are vulnerable to this CVE. To the best of our knowledge, at least the following software may be impacted:

  • Apache Struts
  • Apache Solr
  • Apache Druid
  • Apache Flink
  • ElasticSearch
  • Flume
  • Apache Dubbo
  • Logstash
  • Kafka
  • Spring-Boot-starter-log4j2

The complete list of vendors and software affected by the Apache Log4J vulnerability is available here.

Log4j Discovery & Detection:-

CVE-2021-44228 Log4J Vulnerability can be detected at runtime and attack paths can be visualized by Threat Mapper Tool.

Alerts with the following titles in the Security Devices can indicate threat activity on the network related to exploitation of CVE-2021-44228.

  • Suspicious remote PowerShell execution
  • Download of file associated with digital currency mining
  • Process associated with digital currency mining
  • Cobalt Strike command and control detected
  • Suspicious network traffic connection to C2 Server
  • Ongoing hands-on-keyboard attacker activity detected (Cobalt Strike)

Remediation actions:

Necessary steps to ensure applications are protected against this vulnerability, as outlined below:

  • Internet-facing devices running Log4j and upgrade them to version 2.17.0 or later, or to apply the mitigations provided by vendors “immediately” and setting up alerts for probes or attacks on devices running Log4j.
  • Updating to version 2.17.0 or later, and – where not possible – mitigating the flaw in Log4j 2.10 and later by setting system property “log4j2.formatMsgNoLookups” to “true” or removing the JndiLookup class from the classpath.
  • Enumerating any external facing devices with Log4j installed; ensuring the security operations center actions every alert with Log4j installed; and installing a web application firewall (WAF) with rules to focus on Log4j.
  • Implementation of AWS WAF rule set – AWSManagedRulesKnownBadInputsRuleSet AMR – to detect and mitigate Log4j attack attempts and scanning.
    • It can be enabled for CloudFront, Application Load Balancer (ALB), API Gateway, and AppSync.
    • It’s updating all Amazon OpenSearch Service to the patched version of Log4j.
  • Palo Alto Next-Generation Firewalls with a Threat Prevention can automatically block sessions related to this vulnerability using Threat IDs 91991, 91994 and 91995.
  • For users who rely on Snort or Suricata, the following rules have been released:
  • 2034647
  • 2034648
  • 2034648
  • 2034649
  • 2034650
  • 2034651
  • 2034652