追洞小组 | Jdbc反序列化漏洞复现浅析

墨蓝 2022-10-20 13:43 296阅读 0赞

**目录**

**1、前言+靶场搭建 **

**2、漏洞复现 **

**3、漏洞分析**

**4、漏洞修复 **

**5、心得**

**前言+靶场搭建**

很多时候我们获得密码之后进入后台管理的界面，有些上传的漏洞或者sql注入无法getshell，但是如果发现连接mysql服务的数据包中可以传参，那么我们就可以尝试控制链接mysql服务器，反序列化代码来得到shell。所以该漏洞的关键只需要能够控制客户端的jdbc连接，在连接阶段就可以进行触发反序列化。这篇文章也不深入理解mysql的协议。使用idea maven项目创建，在pom中导入jdbc的坐标。(5版本的在5.1.40以下，8版本的在8.0.20以下)导入之后在右边点击maven图标导入。

![图片][500868d6fbd11d8424827e4e8c90ade7.png]

需要自行根据版本选择JDBC连接串，最后有基于各版本Connector连接串的总结。

public class test1 {
        public static void main(String[] args) throws Exception {
            String driver = "com.mysql.jdbc.Driver";  //8版本是"com.mysql.cj.jdbc.driver"
            //String DB_URL = "jdbc:mysql://127.0.0.1:3306/test?autoDeserialize=true&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor&yso_CommonsCollections5_calc"; //8.x使用
            String DB_URL = "jdbc:mysql://127.0.0.1:3306/test?detectCustomCollations=true&autoDeserialize=true&user=yso_CommonsCollections5_calc"; //5.x使用
            Class.forName(driver);
            Connection conn = DriverManager.getConnection(DB_URL);
        }
    }

**漏洞复现**

**一、 准备伪造的mysql服务**

MySQL服务器使用：[https://github.com/fnmsd/MySQL\_Fake\_Server][https_github.com_fnmsd_MySQL_Fake_Server]

**二、 可控的mysql连接的字符串**

可以去找到"靶场"。这里当然以本地靶场搭建。

![图片][596065a029cdf8573fc2653bcccc82da.png]

**漏洞分析 **

**detectCustomCollations触发方式**

**测试环境中使用mysql-connector-java 5.1.32+java 1.8.221:**

我们在 com.mysql.jdbc\#buildCollationMapping()下上断点，初始化了一个Map indexTocharset;并且if判断为false再进入下一个if体。

![图片][5fab728bb1d9a3cba3f2970741d90519.png]

关键的语句在蓝色的那一行。前提条件是红框判断jdbc的版本大于4.1.0，然后执行show collation语句，再判断版本大于5.0.0，才将show collation的执行结果results传入的Util的resultSetToMap执行。

![图片][8ecd725db2c5ca53750f80d0f39f1992.png]

进入

![图片][6c992c1e415676c7ce9113308dc925de.png]

跟入com.mysqljdbc.result.ResultSetImpl\#getObject可以看到反序列化的触发点，因为刚刚传入的参数是2和3，所以只要这两个字段的sqlType属性为-4,那么我们就可以进入反序列化的入口。

![图片][fe7bfcc38060e1f4de323b8998a93326.png]

sqlType为-4,一直进入到-2的判断。这里我们可以看到field.mysqlType不能为255,并且field是Binary而且是Blob属性才能进入获取字段的data属性，并进行之后的反序列化。

![图片][9568609c5244d2c01caa4c0dd357efd1.png]

**ServerStatusDiffInterceptor触发方式**

**测试环境中使用mysql-connector-java 8.0.14+java 1.8.221:**

这部分有点长，解释一下为什么会执行四次命令。

***queryInterceptors:一个逗号分割的Class列表(实现了com.mysql.cj.interceptors.QueryInterceptor接口的Class),在Query"之间"进行执行来影响效果。(效果上来看是在Query执行前后各插入一次操作)autoDeserialize:自动检测与反序列化存在BLOB字段中的对象。***

所以如上所述，如果要触发queryInterceptors则需要触发SQL Query,而在getConnection过程中，会触发SET NAMES utf、set autocommit=1一类的请求，所以会触发我们所配置的queryInterceptors。

com.mysql.cj.protocol.a.NativeProtocol\#invokeQueryInterceptorsPre方法会调用ServerStatusDiffInterceptor的preProcess方法，再去调用了populateMapWithSessionStatusValues,以下是调用链:

![图片][49dc2f19cf1081e7b2fa53ad268f4666.png]

首先先大致说一下为什么会执行四次命令

![图片][8f67473155f227829b989b11df272fa3.png]

接下来我们细分一下到底查询了什么之后的细分步骤。

首先连接mysql服务器，并ConnectionImpl中设置客户端的字符集，我们进入这个方法。因为前面那个方法的charsetEncoding为空值，所以进入这个方法查询如何配置。

![图片][4d50475044c8dee67dd4d37bd3ba76b0.png]

在NativeSession.class里会获取当前mysql的环境然后会触发一次查询"SET NAMES utf",并发送该请求，在python中收到请求。

![图片][1290991dd7e4317f8a99109a8877a0bf.png]

走完之后完成了下断点的这句，紧接着走箭头所指向的这句话。还在com.mysql.cj.jdbc.ConnectionImpl这个类中。

![图片][1290991dd7e4317f8a99109a8877a0bf.png]

随后会调用com.mysql.cj.protocol.a.NativeProtocol类中的sendQueryString->sendQueryPacket里面再是sendCommand->send方法，有兴趣可以跟一下),在这里我们可以看到这个方法将setautocommit=1传入invokeQueryInteceptorsPre()方法中。而进入这里的方法只是将上次的set namesutf8的结果返回并反序列化中，而进入这里的方法只是将上次的set namesutf8的结果返回并反序列化。

![图片][e2a8906bd1e300073819c1092985409a.png]

而在上述的利用链中我们可以得知在com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor中的preProcess及postProcess都会触发populateMapWithSessionStatusValues这个方法，而这个方法是反序列化readObject方法的前置出发点。

一直走到反序列化的点，将结果返回后反序列化，弹出第一次计算机。

![图片][daa976ea70e7ad97614ef052ea4f6663.png]

resultSetToMap

![图片][9f777431e2fb22c5e1eb0570faf1640a.png]

getObject的反序列化方法

![图片][445ebeb4af2ca971d025e2b2638ecad0.png]

刚刚将set names utf8并结果返回的show session status invokeQueryInterceptorPre走完，到

![图片][7975439fff7e540a978f3ab239092a3e.png]

再到，可以看到调用了postProcess执行反序列化操作

![图片][95cc87de5b7621d4949bca79e90b6f99.png]

postProcess走完，控制台打印

![图片][23c329d673db75f611d8bd292ea73eab.png]

![图片][aa9aa78197cf5dfc645d5202bcac5dc1.png]

python

![图片][a06ca26233639ba24645b7c38213eab6.png]

至此第一部分结束。

第二部分流程也是类似的情况，就不列举了:

![图片][424954ae84a5139d3710db3f4ef86c14.png]

都是在第二次的show Session Status进行了反序列化的操作。刚刚是分析了第一个红框的两次反序列化操作，接下来是下一个红框的反序列化操作，可以看到左下角的调用栈。

![图片][0dd900bb592f88b88fb8255b19bab9e1.png]

随后服务器因为执行了SHOW SESSION STATUS会触发一次preProcess()

进而在触发SET sql\_mode='STRICT\_TRANS\_TABLES'

查询然后进入NativeProtocol\#sendQueryString触发一次postProcess

![图片][fc05d99efcc836348f1e34d6699e02a7.png]

postProcess中最后打印台的两句话印证了我们的思路并且将结果返回。

![图片][9d7fc7a39764863e8366fd763cb34b25.png]

**漏洞修复**

queryInterceptors参数是mysql-connector-java-8.0.7版本才开始支持的，21版本以上被修复。

![图片][db9ec9f057adddc45cdfaf131fb9cd0b.png]

取消了反序列化的操作，getObject改成了getString。

**心得**

这个也是在反序列化的过程中没有对数据做严格的检验导致的，利用起来的话，反序列化的操作还是需要环境有可利用的类，所以这个漏洞有可能利用起来很鸡肋，但是如果能够找到这样一个控制mysql字符串的地方，不妨可以试一试。

[500868d6fbd11d8424827e4e8c90ade7.png]: /images/20221020/76f8c35b406e426f817f90ac94497fbf.png
[https_github.com_fnmsd_MySQL_Fake_Server]: https://github.com/fnmsd/MySQL_Fake_Server
[596065a029cdf8573fc2653bcccc82da.png]: /images/20221020/cc753007aeab4bcb92d2965be928344d.png
[5fab728bb1d9a3cba3f2970741d90519.png]: /images/20221020/945a7c7a5b2444e981b50ab444534d7d.png
[8ecd725db2c5ca53750f80d0f39f1992.png]: /images/20221020/bfcc15ce2fbf43dc926143c8461f503b.png
[6c992c1e415676c7ce9113308dc925de.png]: /images/20221020/5cadd43c440c4884b0736bbec146040b.png
[fe7bfcc38060e1f4de323b8998a93326.png]: /images/20221020/844a506c169d46cfb3b7372679bdee63.png
[9568609c5244d2c01caa4c0dd357efd1.png]: /images/20221020/d0954f63bbc94bfeb8d3b1477a6413a0.png
[49dc2f19cf1081e7b2fa53ad268f4666.png]: /images/20221020/4402e09c3326484abfa2d8f4c2f49e3d.png
[8f67473155f227829b989b11df272fa3.png]: /images/20221020/86a47ca3bdde490b902c83367965d2a3.png
[4d50475044c8dee67dd4d37bd3ba76b0.png]: /images/20221020/e7c882d8f54549c1aa22c41aabb5870f.png
[1290991dd7e4317f8a99109a8877a0bf.png]: /images/20221020/72cacd65d28242b69886d8c59b3e96ee.png
[e2a8906bd1e300073819c1092985409a.png]: /images/20221020/e27402112edb4df9aed4173890e265f6.png
[daa976ea70e7ad97614ef052ea4f6663.png]: /images/20221020/42be345303d64c06ac4422a220ea79da.png
[9f777431e2fb22c5e1eb0570faf1640a.png]: /images/20221020/ac4a6155523247dcb1cfe3859458f29e.png
[445ebeb4af2ca971d025e2b2638ecad0.png]: /images/20221020/22c83a284f034e8d8d7f902f2424ad77.png
[7975439fff7e540a978f3ab239092a3e.png]: /images/20221020/3a1548f7c0144f809da0ddd504d8ee7a.png
[95cc87de5b7621d4949bca79e90b6f99.png]: /images/20221020/3067a47f592e4d46a4b93235bb4414df.png
[23c329d673db75f611d8bd292ea73eab.png]: /images/20221020/c9aced230b1045e2b86c560820b49c93.png
[aa9aa78197cf5dfc645d5202bcac5dc1.png]: /images/20221020/62560e0829ee403fb8298833beae81e9.png
[a06ca26233639ba24645b7c38213eab6.png]: /images/20221020/9c080e5cb4f44a58ae0e2b67a9293cf9.png
[424954ae84a5139d3710db3f4ef86c14.png]: /images/20221020/83bc54a3b05f4c288c29f4e64c96497c.png
[0dd900bb592f88b88fb8255b19bab9e1.png]: /images/20221020/414f96520df34099a842c9b65b2cb4b6.png
[fc05d99efcc836348f1e34d6699e02a7.png]: /images/20221020/3f55fff653e2402aa0bc16aabff26669.png
[9d7fc7a39764863e8366fd763cb34b25.png]: /images/20221020/69dfbf6da66547e1b8497736a3c5853c.png
[db9ec9f057adddc45cdfaf131fb9cd0b.png]: /images/20221020/b8f808c0c29646e3bedee0fd04caddc3.png