研究过这个问题。。。本来想写个笔记的,只写了个大纲,就干别的事情去了
JDBC Mysql Attack
关于JDBC Attack中对Mysql的利用,主要是通过两种方式触发反序列化,一是通过queryInterceptors,二是通过detectCustomCollations,原理细节不再赘述,具体可先学习参考fnmsd师傅这篇参考。
关于detectCustomCollations
在上面参考文章中,写到detectCustomCollations触发的方法不适用于5.1.41及以上和5.1.18以下,因为其不再使用getObject的方式获取SHOW COLLATION的结果,导致此方法失效,但在学习的过程中发现与原文章有一些差异,故此总结。
<=5.1.18
在5.1.18及以下版本中对SHOW COLLATION
返回的结果并未使用getObject(),导致无法触发反序列化。
5.1.19-5.1.39
而在5.1.19-5.1.39版本之间,对SHOW COLLATION
返回的结果处理逻辑如下
会对SHOW COLLATION返回结果调用Util.resultSetToMap
进行处理,而resultSetToMap
则和ServerStatusDiffInterceptor
相同,最后走到ResultSetImpl#getObject
触发反序列化。
流程如下:
5.1.40-5.1.48
而从5.1.40开始处理代码逻辑如下
确实不再直接调用ResultSetImpl#getObject
,但是对SHOW COLLATION
结果的第三列直接调用了results.getObject(),最后还是进入的ResultSetImpl#getObject中.
其中满足字段类型为-4,-3,-2(blob,bit,binary)时会进入getObjectDeserializingIfNeeded
方法,直接用恶意mysql服务器的设置,修改一下代码将第三个字段也填充为序列化数据即可.
该方法和之前类似进行了反序列化操作,其中通过this.connection.getAutoDeserialize()
来确定是否进行反序列化,在url中同之前一样设置autoDeserialize=true
即可.
5.1.49
而直到5.1.49才真正没有调用getObject().
6.0.2
但在6.0.2开始,版本中却又直接调用了ResultSetUtil.resultSetToMap
,又回到了ServerStatusDiffInterceptor
那条链中,同样可以触发反序列化,实测直到6.0.6版本都是这样。
8.x
而在8.x版本获取SHOW COLLATION
时又不一样了,才终于又无法利用该点触发了。
总结
detectCustomCollations可触发的版本:5.1.18< version <=6.0.6(5.1.49除外)。
在恶意mysql服务器的基础上修改一下填充第三个字段为yso序列化的数据即可通用。