Dubbo Kryo & FST RCE

Dubbo Kryo & FST RCE




漏洞简介

漏洞原理

Dubbo Provider即服务提供方默认使用dubbo协议来进行RPC通信,而dubbo协议默认是使用Hessian2序列化格式进行对象传输的,但是针对Hessian2序列化格式的对象传输可能会有黑白名单设置的限制,参考:https://github.com/apache/dubbo/pull/6378

针对这种场景,攻击者可以通过更改dubbo协议的第三个flag位字节来更改为使用Kryo或FST序列化格式来进行Dubbo Provider反序列化攻击从而绕过针对Hessian2反序列化相关的限制来达到RCE。

影响版本
  • Dubbo 2.7.0 to 2.7.8

  • Dubbo 2.6.0 to 2.6.9

  • Dubbo all 2.5.x versions (not supported by official team any longer)




环境复现

安装zookeeper和dubbo-samples,用idea打开dubbo-samples-api,然后修改其中的pom.xml如下:

Dubbo Kryo & FST RCE

注意,dubbo-common必须2.7.3版本。

在Dubbo<=2.7.3中fastjson的版本≤1.2.46 ,这也是我们这个洞的利用点,不过这里复现使用的更高版本所以需要添加依赖,

<dependency>    <groupId>com.alibaba</groupId>    <artifactId>fastjson</artifactId>    <version>1.2.46</version></dependency>

使用POC进行测试:

Dubbo Kryo & FST RCE
Dubbo Kryo & FST RCE




Dubbo的协议设计

由于Dubbo可以支持很多类型的反序列化协议,以满足不同系统对RPC的需求,比如:

•跨语言的序列化协议:Protostuff、ProtoBuf、Thrift、Avro、MsgPack

• 针对Java语言的序列化方式:Kryo、FST

• 基于Json文本形式的反序列化方式:Json、Gson

Dubbo中对支持的协议做了一个编号,每个序列化协议都有一个对应的编号,以便在获取TCP流量后,根据编号选择相应的反序列化方法,因此这就是Dubbo支持这么多序列化协议的秘密,但同时也是危险所在。

org.apache.dubbo.common.serialize.Constants中可见每种序列化协议的编号:

Dubbo Kryo & FST RCE

而在Dubbo的RPC通信时,对流量的规定最前方为header,而header中通过指定SerializationID,确定客户端和服务提供端通信过程使用的序列化协议。

Dubbo通信的具体数据包规定如下图所示:

Dubbo Kryo & FST RCE

虽然Dubbo的provider默认使用hessian2协议,但我们可以自由的修改SerializationID,选定危险的(反)序列化协议,例如kryo和fst。




Dubbo RPC数据包格式

Dubbo Kryo & FST RCE
•Magic(魔术) - Magic High & Magic Low (16 bits)用值标识dubbo协议:0xdabb•Req/Res (1 bit)标识这是一个请求或响应。请求 : 1;响应 : 0。•2 Way (1 bit)Only useful when Req/Res is 1 (Request), expect for a return value from server or not. Set to 1 if need a return value from server.Event (1 bit)Identifies an event message or not, for example, heartbeat event. Set to 1 if this is an event.•Serialization ID (5 bit)标识序列化类型:fastjson 的值为 6Status (8 bits)Only useful when Req/Res is 0 (Response), identifies the status of response20 - OK30 - CLIENT_TIMEOUT31 - SERVER_TIMEOUT40 - BAD_REQUEST50 - BAD_RESPONSE60 - SERVICE_NOT_FOUND70 - SERVICE_ERROR80 - SERVER_ERROR90 - CLIENT_ERROR100 - SERVER_THREADPOOL_EXHAUSTED_ERROR•Request ID (64 bits)Identifies an unique request. Numeric (long).Data Length (32)序列化后内容(可变部分)的长度,以字节为单位。数字(整数)。Variable PartEach part is a byte[] after serialization with specific serialization type, identifies by Serialization ID.Every part is a byte[] after serialization with specific serialization type, identifies by Serialization ID1.If the content is a Request (Req/Res = 1), each part consists of the content, in turn is:•Dubbo version–Service name–Service version–Method name–Method parameter types–Method arguments–Attachments1.If the content is a Response (Req/Res = 0), each part consists of the content, in turn is:Return value type, identifies what kind of value returns from server side: RESPONSE_NULL_VALUE - 2, RESPONSE_VALUE - 1, RESPONSE_WITH_EXCEPTION - 0.Return value, the real value returns from server.
注意:对于(Variable Part)变长部分,当前版本的dubbo框架使用json序列化时,在每部分内容间额外增加了换行符作为分隔,请选手在Variable Part的每个part后额外增加换行符,如:
Dubbo version bytes (换行符)Service name bytes  (换行符)...
案例
Dubbo Kryo & FST RCE




漏洞分析

FTS反序列化

FTS反序列化发生在RPC协议反序列化。

Dubbo Kryo & FST RCE
org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation#decode(org.apache.dubbo.remoting.Channel, java.io.InputStream)

在上述方法中首先通过serializationType索引序列化器,当TypeId为8时使用Kryo,TypeId为9时使用Fst。

Dubbo Kryo & FST RCE
Dubbo Kryo & FST RCE
kryo和fst的调用链都比较类似,使用map序列化器反序列化时触发,
Dubbo Kryo & FST RCE
instantiate:79, FSTMapSerializer (org.nustaq.serialization.serializers)instantiateAndReadWithSer:497, FSTObjectInput (org.nustaq.serialization)readObjectWithHeader:366, FSTObjectInput (org.nustaq.serialization)readObjectFields:708, FSTObjectInput (org.nustaq.serialization)instantiateAndReadNoSer:562, FSTObjectInput (org.nustaq.serialization)readObjectWithHeader:370, FSTObjectInput (org.nustaq.serialization)readObjectFields:708, FSTObjectInput (org.nustaq.serialization)instantiateAndReadNoSer:562, FSTObjectInput (org.nustaq.serialization)readObjectWithHeader:370, FSTObjectInput (org.nustaq.serialization)readObjectInternal:327, FSTObjectInput (org.nustaq.serialization)instantiate:77, FSTMapSerializer (org.nustaq.serialization.serializers)instantiateAndReadWithSer:497, FSTObjectInput (org.nustaq.serialization)readObjectWithHeader:366, FSTObjectInput (org.nustaq.serialization)readObjectInternal:327, FSTObjectInput (org.nustaq.serialization)readObject:307, FSTObjectInput (org.nustaq.serialization)readObject:102, FstObjectInput (org.apache.dubbo.common.serialize.fst)decode:116, DecodeableRpcInvocation (org.apache.dubbo.rpc.protocol.dubbo)decode:73, DecodeableRpcInvocation (org.apache.dubbo.rpc.protocol.dubbo)decodeBody:132, DubboCodec (org.apache.dubbo.rpc.protocol.dubbo)


核心部分调用堆栈入手,根据调用堆栈可知获取了FstSerialization解析器进行反序列化,在反序列化的过程中必然涉及到还原对象以及相关字段,而在还原HashMap 的时候对其成员进行还原时候会调用HashMap#put方法将键值对进行放入,而这个放入的过程就是触发漏洞的关键点,在放入的过程中存在两个口子,一个是hashCode,另一个是 equals。
Dubbo Kryo & FST RCE
Dubbo Kryo & FST RCE
Dubbo Kryo & FST RCE
这里调用equals口子进入toString方法,由此可知这里使用的:
org.springframework.aop.target.HotSwappableTargetSource#equals -> com.sun.org.apache.xpath.internal.objects.XString#equals(java.lang.Object) -> xxxx.toString()
Dubbo Kryo & FST RCE
这里再次触发equals方法,参数是我们构造的恶意JSONObject对象,
Dubbo Kryo & FST RCE
com.sun.org.apache.xpath.internal.objects.XString#equals(java.lang.Object)
在上述方法中触发了传入的恶意JSONObject对象的toString方法:
Dubbo Kryo & FST RCE
fastjson中JSONObject是可以被序列化的,当其显式或隐式被调用toString方法时,会触发绑定对象的getter方法:Dubbo Kryo & FST RCE
Dubbo Kryo & FST RCE
这里将会触发这个JSONObject中成员的值,也就是触发了这个TemplatesImpl对象的get系列方法,而我们的Payload入口就是getOutProperties方法,至于后面就是常规的TemplatesImpl利用手法。
下图是POC中对应的链的构造:
Dubbo Kryo & FST RCE
Dubbo Kryo & FST RCE
Dubbo Kryo & FST RCE

完整漏洞调用栈

exec:-1, Runtime (java.lang):-1, Pwner8957425893700 (ysoserial)newInstance0:-1, NativeConstructorAccessorImpl (sun.reflect)newInstance:-1, NativeConstructorAccessorImpl (sun.reflect)newInstance:-1, DelegatingConstructorAccessorImpl (sun.reflect)newInstance:-1, Constructor (java.lang.reflect)newInstance:-1, Class (java.lang)getTransletInstance:-1, TemplatesImpl (com.sun.org.apache.xalan.internal.xsltc.trax)newTransformer:-1, TemplatesImpl (com.sun.org.apache.xalan.internal.xsltc.trax)getOutputProperties:-1, TemplatesImpl (com.sun.org.apache.xalan.internal.xsltc.trax)write:-1, ASMSerializer_1_TemplatesImpl (com.alibaba.fastjson.serializer)write:270, MapSerializer (com.alibaba.fastjson.serializer)write:44, MapSerializer (com.alibaba.fastjson.serializer)write:280, JSONSerializer (com.alibaba.fastjson.serializer)toJSONString:863, JSON (com.alibaba.fastjson)toString:857, JSON (com.alibaba.fastjson)equals:-1, XString (com.sun.org.apache.xpath.internal.objects)equals:104, HotSwappableTargetSource (org.springframework.aop.target)putVal:-1, HashMap (java.util)put:-1, HashMap (java.util)instantiate:79, FSTMapSerializer (org.nustaq.serialization.serializers)instantiateAndReadWithSer:497, FSTObjectInput (org.nustaq.serialization)readObjectWithHeader:366, FSTObjectInput (org.nustaq.serialization)readObjectInternal:327, FSTObjectInput (org.nustaq.serialization)readObject:307, FSTObjectInput (org.nustaq.serialization)readObject:102, FstObjectInput (org.apache.dubbo.common.serialize.fst)decode:116, DecodeableRpcInvocation (org.apache.dubbo.rpc.protocol.dubbo)decode:73, DecodeableRpcInvocation (org.apache.dubbo.rpc.protocol.dubbo)decodeBody:132, DubboCodec (org.apache.dubbo.rpc.protocol.dubbo)decode:122, ExchangeCodec (org.apache.dubbo.remoting.exchange.codec)decode:82, ExchangeCodec (org.apache.dubbo.remoting.exchange.codec)decode:48, DubboCountCodec (org.apache.dubbo.rpc.protocol.dubbo)decode:90, NettyCodecAdapter$InternalDecoder (org.apache.dubbo.remoting.transport.netty4)decodeRemovalReentryProtection:508, ByteToMessageDecoder (io.netty.handler.codec)callDecode:447, ByteToMessageDecoder (io.netty.handler.codec)channelRead:276, ByteToMessageDecoder (io.netty.handler.codec)invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)fireChannelRead:357, AbstractChannelHandlerContext (io.netty.channel)channelRead:1410, DefaultChannelPipeline$HeadContext (io.netty.channel)invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)fireChannelRead:919, DefaultChannelPipeline (io.netty.channel)read:166, AbstractNioByteChannel$NioByteUnsafe (io.netty.channel.nio)processSelectedKey:719, NioEventLoop (io.netty.channel.nio)processSelectedKeysOptimized:655, NioEventLoop (io.netty.channel.nio)processSelectedKeys:581, NioEventLoop (io.netty.channel.nio)run:493, NioEventLoop (io.netty.channel.nio)run:989, SingleThreadEventExecutor$4 (io.netty.util.concurrent)run:74, ThreadExecutorMap$2 (io.netty.util.internal)run:30, FastThreadLocalRunnable (io.netty.util.concurrent)run:-1, Thread (java.lang)

Kryo反序列化

在DecodeableRpcInvocation类的decode()方法(该方法会在处理RPC请求时候调用)中,通过serializationType为8、获取到反序列化器Kryo,然后调用readUTF()函数来读取dubbo协议对应的字段信息如dubbo协议版本、服务名称、服务版本、方法名、方法参数类型等:
Dubbo Kryo & FST RCE
提取方法参数类型为类数组后,再循环对参数进行Kryo反序列化。
从input中读取解析到type为HashMap,因此会调用Kryo的MapSerializer序列化器来读取input中的信息:
Dubbo Kryo & FST RCE
Dubbo Kryo & FST RCE
其中会将解析到的key和value都通过调用map.put()来放入HashMap对象中,发生在com.esotericsoftware.kryo.serializers.MapSerializer#read方法调用中,这里是有两对键值对放进去了:
Dubbo Kryo & FST RCE
往下putVal()函数中会调用key即XString类的equals()函数来判断两个key值是否相等:
Dubbo Kryo & FST RCE
到这和前面FST反序列化基本上一样了。




修复

dubbo-common 2.7.3的版本中存在kryo和fst的序列化需要的类,而在dubbo-common 2.7.4.1中,这三个包并不存在,需要自行导入。
在高版本中已将com.esotericsoftware:kryo依赖去掉了,在使用Kryo序列化器进行反序列化获取KryoObjectInput对象时会报找不到KryoException类的错误,自带的Fastjson版本为1.2.70,AutoType会自动拦截掉TemplatesImpl类。


原文始发于微信公众号(雁行安全团队):Dubbo Kryo & FST RCE

版权声明:admin 发表于 2022年11月23日 上午10:50。
转载请注明:Dubbo Kryo & FST RCE | CTF导航

相关文章

暂无评论

暂无评论...