前言
shiro的k1/k2链条其实之前我已经分析过了,但是呢,没以文章的形式发出来。可能有点懒惰了。上篇文章我们一起看了t3协议,t3反序列化的修复手段是在resolveClass方法添加检查,增加黑名单的形式。而shiro是重写了resolveClass方法导致很多利用链无法使用,但是shiro在编写的时候,并不是为了防御反序列化漏洞才去重写的resolveClass,但是就是这么一个无意间的举动,导致了防御住了大部分攻击。下面我们分析。
直接使用cc6
cc6的利用链我们前面有,拿来直接用,默认keykPH+bIxk5D2deZiIxcaaaA==
去加密,再base64编码。
发送后我们可以看到tomcat报错:
看到错误栈中最下面的那个类:
org.apache.shiro.io.ClassResolvingObjectInputStream.resolveClass
resolveClass方法是反序列化中用来查找类的方法,shiro反序列化的函数不是我们述职的ObjectInputStream().readObject,而是ClassResolvingObjectInputStream类,他继承了ObjectInputStream类,重写了resolveClass方法,原因就出现 再重写后的resolveClass方法,跟进ClassUtils.forName(osc.getName());
出异常时加载的类名为 [Lorg.apache.commons.collections.Transformer;。这个类名看起来 怪,其实就是表示org.apache.commons.collections.Transformer的数组。
跟进Class clazz = THREAD_CL_ACCESSOR.loadClass(fqcn);
,
加载和获取当前线程的类,参考phith0n的结论:如果反序列化流中包含非Java自身的数组,则会出现无法加载类的错误。 所以CC6,CC1都无法使用,网络上很多其他文章都是用的CommonCollections2,但CommonCollections2依赖的是CommonCollections4.0版本。
K1
package org.example.k1;
import com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet;
import com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl;
import com.sun.org.apache.xalan.internal.xsltc.tr