(cve-2021-45046) log4j2 DOS rce mode reproduction

Posted by kidd1270 on Fri, 24 Dec 2021 00:29:51 +0100

On December 9, I saw an article on research ideas related to log4j2 DOS vulnerabilities. Unfortunately, I was busy and didn't have time to do it

See, most of the log4j2 versions have been upgraded to 2.17 these days. I have squeezed some time to reproduce it

Statement: for vulnerability understanding and learning and security reinforcement solutions, do not use vulnerabilities in illegal ways, and bear the consequences

I Environment preparation (spring boot+log4j2):

(1) Complete environment construction

It is recommended to build a complete spring boot framework and log4j2 log configuration. Spring boot uses logback log structure by default and is configured as log4j2. You can refer to the following two articles for configuration methods:

springboot integrated log4j2 log full solution: https://www.cnblogs.com/keeya/p/10101547.html

springboot log4j2 configuration: https://blog.csdn.net/qq_35192741/article/details/82629041

Full Environment Download:

Spring-boot: https://github.com/spring-projects/spring-boot

Log4j-core-2.15.0.jar: https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-core/2.15.0/log4j-core-2.15.0.jar

(2) Simple replication environment

Log4j2 dos env: https://github.com/EmYiQing/Log4j2DoS

I've seen that the replication environment only retains the spring boot basic http service and log log service, and the service vulnerabilities are replicated separately. We use this simple spring boot+log4j2 environment to replicate the CVE-2021-45046 vulnerability

II Two local environment configurations and trigger replication

Vulnerability triggering principle:

Found Apache log4j 2.15 The fix for CVE-2021-44228 in 0 is incomplete in some non default configurations. When the log configuration uses the JNDI lookup mode to make malicious input data with context lookup (for example, $${ctx:loginId}) or thread context mapping mode (% X,% mdc or% MDC), resulting in information disclosure and remote code execution in some environments and local code execution in all environments. Log4j 2.16.0 (Java 8) and 2.12 2 (Java 7) solves this problem by removing support for message lookup mode and disabling JNDI function by default.

1. The first trigger method: log configuration uses $${ctx:loginId} with context lookup

(1) Vulnerability trigger location

http://localhost:8080/cve?userId=payload

(2) Condition: log configuration uses $${ctx:loginId} with context lookup

<pattern>%d %p %c{1.} [%t] $${ctx:loginId} %m%n</pattern>

(3) Reproduction steps

(1) Modify the log.4j2.xml configuration file:

File location: X: \ XXX \ XXX \ XXX \ XXX \ XXX \ log4j2dos master \ SRC \ main \ resources \ log4j2 xml

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="warn" name="MyApp" packages="">
    <appenders>
        <console name="STDOUT" target="SYSTEM_OUT">
            <PatternLayout>
                <pattern>%d %p %c{1.} [%t] $${ctx:loginId} %m%n</pattern>
            </PatternLayout>
        </console>
    </appenders>
    <Loggers>
        <Root level="info">
            <AppenderRef ref="STDOUT"/>
        </Root>
    </Loggers>
</Configuration>

(2) Start the spring boot server:

Startup file:

X:\XXX\XXX\XXX\XXX\XXX\Log4j2DoS-master\src\main\java\com\example\demo\Demo1Application.java

Test whether the web service is accessed normally: http://localhost:8080 , normal start

backstage

Access vulnerability location (here we use 1 for paload):

http://localhost:8080/cve?userId=1

Then change 1 to MQ = = input (MQ = = is the result of base64 encoding of 1). Access:

http://localhost:8080/cve?userId=MQ==

Access the vulnerability location. This time, we change the payload to ${java:version} to display the current java version. Of course, base64 is also used to pass parameters, that is, JHtqYXZhOnZlcnNpb259. Access:

http://localhost:8080/cve?userId=JHtqYXZhOnZlcnNpb259

2. The second trigger mode: thread context mapping mode (% X,% mdc or% MDC)

(1) Vulnerability trigger location

http://localhost:8080/test?message=payload

(2) Condition: thread context mapping mode (% X,% mdc, or% MDC)

<PatternLayout pattern="%msg{lookups}%n"/>

(3) Reproduction steps

(1) Modify the log4j2.xml configuration file:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="warn" name="MyApp" packages="">
    <appenders>
        <console name="STDOUT" target="SYSTEM_OUT">
            <PatternLayout pattern="%msg{lookups}%n"/>
        </console>
    </appenders>
    <Loggers>
        <Root level="info">
            <AppenderRef ref="STDOUT"/>
        </Root>
    </Loggers>
</Configuration>

(2) Start the spring boot server:

Startup file:

X:\XXX\XXX\XXX\XXX\XXX\Log4j2DoS-master\src\main\java\com\example\demo\Demo1Application.java

We still take the payload as 1 to test. Visit:

http://localhost:8080/test?message=MQ==
As in the previous time, change the payload to ${java:version}. The payload is jhtqyxzhonzlcnpb259. Visit:
http://localhost:8080/test?message=JHtqYXZhOnZlcnNpb259

I don't understand, but I'm shocked

This is not RCE. What is it???

Continuous update

Topics: Java security hole log4j2