追洞小组 | Jdbc反序列化漏洞复现浅析
2021-05-10 12:51:34 Author: mp.weixin.qq.com(查看原文) 阅读量:196 收藏

文章来源|MS08067 WEB攻防知识星球

本文作者:爱吃芝士的小葵(Ms08067实验室追洞小组成员)

漏洞复现分析  认准追洞小组

目录

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图标导入。

需要自行根据版本选择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字符串的地方,不妨可以试一试。

扫描下方二维码加入星球学习

加入后会邀请你进入内部微信群,内部微信群永久有效!

 

 

目前40000+人已关注加入我们


文章来源: http://mp.weixin.qq.com/s?__biz=MzU1NjgzOTAyMg==&mid=2247493465&idx=1&sn=8615fb11c43f9e170fd0a363bfdad761&chksm=fc3c5e58cb4bd74ea37e5c88537165111abe86828b5912855b0144fde8329def7a4bb8318022#rd
如有侵权请联系:admin#unsafe.sh