追洞小组 | Jdbc反序列化漏洞复现浅析
追洞小组 | Jdbc反序列化漏洞复现浅析
文章来源｜MS08067 WEB攻防知识星球
本文作者：爱吃芝士的小葵（Ms08067实验室追洞小组成员）
漏洞复现分析 认准追洞小组
前言+靶场搭建
很多时候我们获得密码之后进入后台管理的界面，有些上传的漏洞或者sql注入无法getshell，但是如果发现连接mysql服务的数据包中可以传参，那么我们就可以尝试控制连接mysql服务器，反序列化代码来得到shell。所以该漏洞的关键只需要能够控制客户端的jdbc连接，在连接阶段就可以进行处发反序列化。这篇文章也不深入理解mysql的协议。使用idea maven项目创建，在pom中导入jdbc的坐标。(5版本的在5.1.40以下，8版本的在8.0.20以下)导入之后在右边点击maven图标导入。
需要自行根据版本选择JDBC连接串，最后有基于各版本Connector连接串的总结。
漏洞复现
一、 准备伪造的mysql服务
MySQL服务器使用：
https://github.com/fnmsd/MySQL_Fake_Server
二、 可控的mysql连接的字符串
可以去找到"靶场"。这里当然以本地靶场搭建。
漏洞分析
detectCustomCollations触发方式
测试环境中使用mysql-connector-java 5.1.32+java 1.8.221：
我们在 com.mysql.jdbc#buildCollationMapping() 下上断点，初始化了一个Map indexTocharset;并且if判断为false再进入下一个if体。
关键的语句在蓝色的那一行。前提条件是红框判断jdbc的版本大于4.1.0，然后执行 show collation 语句，再判断版本大于5.0.0，才将 show collation 的执行结果results传入Util的resultSetToMap执行。
进入
跟入com.mysqljdbc.result.ResultSetImpl#getObject 可以看到反序列化的触发点，因为刚刚传入的参数是2和3，所以只要这两个字段的sqlType属性为-4那么我们就可以进入反序列化的入口。
sqlType为-4，一直进入到-2的判断。这里我们可以看到field.mysqlType不能为255，并且field是Binary而且是Blob属性才能进入获取字段的data属性并进行之后的反序列化。
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 ，一下是调用链：
首先先大致说一下为什么会执行四次命令
接下来我们细分一下到底查询了什么之后的细分步骤。
首先连接mysql服务器，并ConnectionImpl中设置客户端的字符集，我们进入这个方法。因为前面那个方法的charsetEncoding为空值，所以进入这个方法查询如何配置。
在NativeSession.class里会获取当前mysql的环境然后会触发一次查询”SET NAMES utf”,并发送该请求，在python中收到请求。
走完之后完成了下断点的这句，紧接着走箭头所指向的这句话。还在com.mysql.cj.jdbc.ConnectionImpl
这个类中。
随后会调用com.mysql.cj.protocol.a.NativeProtocol类中的sendQueryString->sendQueryPacket
里面再是sendCommand->send方法，有兴趣可以跟一下），在这里我们可以看到这个方法将setautocommit=1传入invokeQueryInteceptorsPre()方法中。而进入这里的方法只是将上次的 set namesutf8 的结果返回并反序列化。
一直走到反序列化的点，将结果返回后反序列化。弹出第一次计算机。
resultSetToMap
getObject的反序列化方法
刚刚将 set names utf8 并结果返回的 show session status invokeQueryInterceptorsPre走完，到
再到，可以看到调用了postProcess执行反序列化操作
postProcess走完，控制台打印
python
至此第一部分结束。
第二部分流程也是类似的情况，就不列举了：
都是在第二次的show Session Status进行了反序列化的操作。刚刚是分析了第一个红框的两次反序列化操作，接下来是下一个红框的反序列化操作，可以看到左下角的调用栈。
随后服务器因为执行了SHOW SESSION STATUS会触发一次preProcess()
进而在触发SET sql_mode=’STRICT_TRANS_TABLES‘
查询然后进入NativeProtocol#sendQueryString触发一次postProcess
postProcess中最后打印台的两句话印证了我们的思路并且将结果返回。
漏洞修复
queryInterceptors参数是mysql-connector-java-8.0.7版本才开始支持的，21版本以上被修复。
取消了反序列化的操作，getObject改成了getString。
心得
这个也是在反序列化的过程中没有对数据做严格的校验导致的，利用起来的化反序列化的操作还是需要环境有可利用的类。所以这个漏洞有可能利用起来很鸡肋，但是如果能够找到这样一个控制mysql字符串的地方，不妨可以试一试。