帆软channel接口反序列化漏洞分析

影响版本

FineReport10.0、FineReport11.0、FineBI5.1 系列均受影响

环境搭建

FineBI5.1环境 链接: https://pan.baidu.com/s/1AOPKgy-Rt3fGjBqlyG2qzA?pwd=4th9 提取码: 4th9（环境来源于网络不保证安全性）

代码分析

官网发布漏洞路径：webroot/decision/remote/design/channel

漏洞jar包：fine-decision-report-10.0.jar

代码位置：RemoteDesignResource.class

首先将POST传入进来的数据传递到WorkContext.handleMessage()方法，跟进查看

继续跟进messageListener.handleMessage(var0)，发现这里将之前POST获取的值传入到deserializeInvocation方法中

跟进deserializeInvocation方法，这里SerializerHelper.deserialize()会传入两个参数

第一个参数是之前传入的POST数据

第二个参数是通过用InvocationSerializer来封装了GZipSerializerWrapper类。

继续跟进deserialize()方法，这里会调用之前用InvocationSerializer来封装了GZipSerializerWrapper类的deserialize方法进行反序列化数据。

这里先通过GZIPInputStream()方法进行数据进行解压一次，然后在调用this.serializer的deserialize方法，而这里this.serializer就是之前InvocationSerializer，具体可以看下面两张图

继续跟进InvocationSerializer类的deserialize方法，这里就很明了直接调用readObject反序列化。

FineReport 和 FineBi区别

测试发现FineReport的InvocationSerializer的deserialize多了一次CustomObjectInputStream封装,而FineBi则直接调用readObject进行反序列化。

利用链

目前有了入口点需要找利用链，晃眼一看没有常见的CC、CB的依赖库，后面分析发现其实都封装在fine-bi-engine-third-5.1.jar包里面。

漏洞利用

需注意：commons-beanutils版本与服务器版本相同（之前没注意导致一直反序列化失败）。

这里我就采用比较简单的方法，把目标源码的jar包来作为依赖重新写一遍CB链。