1. Principle of destruction
What is the damage method of Log4j2 bug? In fact, it is very simple. It is similar to SQL injection. This is more powerful. It is directly code injection. Code execution permission is naturally equivalent to application permission. This is a village where a toolman who prints logs does not work hard and introduces Japanese soldiers.
So what is the main principle? When printing a log, if the keyword ${ } is found in the log content, the content contained in { } will be replaced as a variable, allowing the attacker to execute commands arbitrarily. Detailed vulnerability disclosure can be found at: https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-3201?filter=allissues.
In fact, it is mainly because of a big problem with a plug-in in Log4J2: Lookup. This is an infrequently used plug-in, but the code is triggered very frequently. It is so high that every time your code triggers the writing of info, warn, error and other logs, it will check whether the Lookup logic is executed. Among them, the more serious problems are the JndiLookup and RMILookup functions. JNDI can find and look up data and resources, while RMI can make remote calls. If you use your host to remotely call the destructive code (application service) I started, then your service host will be meat on the chopping board, ready to be slaughtered.
2. Solution
Change JVM running parameters
Some projects may have complex dependencies and are inconvenient to recompile. You can directly add the following JVM parameters at runtime to disable Lookup from taking effect.
-Dlog4j2.formatMsgNoLookups=true
Reference link: https://blog.csdn.net/qq_22136439/article/details/121906595