fastjson反序列化TemplatesImpl
环境参考第一个链接,直接用IDEA打开
编译EvilObject.java成EvilObject.class
先看poc,其中NASTY_CLASS为TemplatesImpl类,evilCode是EvilObject.class base64编码:
final String evilClassPath = "E:\\Struts2-Vulenv-master\\PoCs-fastjson1241\\src\\main\\java\\org\\lain\\poc\\TemplatesImpl\\EvilObject.class";
String evilCode = readClass(evilClassPath);
final String NASTY_CLASS = "Lcom.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl;";
String payload = "{\"@type\":\"" + NASTY_CLASS +
"\",\"_bytecodes\":[\""+evilCode+"\"],'_name':'a.b','_tfactory':{ },\"_transletIndex\":0,\"_auxClasses\":{},\"_outputProperties\":{ }";
下面看下Poc是怎么构造的,当使用fastjson解析json时,会自动调用其属性的get方法。
TypeUtil.clss 813行下断点,会加载TemplatesImpl类
f8会对传入的payload做处理将_去掉,这是构造payload的关键一步。先处理_bytecodes
当处理_bytecodes时,f7跟进bytesValue
对传进的做base64解码处理,这就是为什么payload做base64编码处理的原因
为什么_tfactory为{}?
fastjson只会反序列化公开的属性和域,而com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl中_bytecodes却是私有属性,_name也是私有域,所以在parseObject的时候需要设置Feature.SupportNonPublicField,这样_bytecodes字段才会被反序列化。_tfactory这个字段在TemplatesImpl既没有get方法也没有set方法,这没关系,我们设置_tfactory为{ },fastjson会调用其无参构造函数得_tfactory对象,这样就解决了某些版本中在defineTransletClasses()用到会引用_tfactory属性导致异常退出。
当处理_outputProperties时,也会把_去掉。
调用outputProperties属性的get方法:
调用newTransformer类
调用TransformerImpl类,继续f7跟进
调用getTransletInstance,为什么poc中的_name和_class不为null的原因如下,387行实例化了传入了EvilObject.class类。
这里调用了EvilObject的构造函数,恶意代码执行。
上面是漏洞调试分析,关于pop链执行的构成如下分析:
首先_bytecodes会传入getTransletInstance方法中的defineTransletClasses方法,defineTransletClasses方法会根据_bytecodes字节数组new一个_class,_bytecodes加载到_class中,最后根据_class,用newInstance生成一个java实例:
触发getTransletInstance,看谁调用这个类,alt+f7
在newTransformer中触发了getTransletInstance方法,那问题又来了怎么触发newTransformer?alt+f7
getOutputProperties会调用newTransformer,而fastjson会调用属性的get方法,所以传入_outputProperties导致此方法执行,完整的形成了pop链。
调用链如下:
参考链接:
https://github.com/ZH3FENG/PoCs-fastjson1241.git
这篇文章写得最好
https://p0sec.net/index.php/archives/123/
http://xxlegend.com/2017/04/29/title-%20fastjson%20%E8%BF%9C%E7%A8%8B%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96poc%E7%9A%84%E6%9E%84%E9%80%A0%E5%92%8C%E5%88%86%E6%9E%90/
https://paper.seebug.org/636/