不乱于心,不困于情。
不畏将来,不念过往。如此,安好。

Jdbc反序列化漏洞复现浅析

前言+靶场搭建

很多时候我们获得密码之后进入后台管理的界面,有些上传的漏洞或者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字符串的地方,不妨可以试一试。

转自:MS08067

赞(0) 打赏
未经允许不得转载:seo优化_前端开发_渗透技术 » Jdbc反序列化漏洞复现浅析

相关推荐

  • 暂无文章

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏