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序列化的数据即可通用。