Jackson基础操作
主要功能就是在java类与json字符串中间进行序列化与反序列化的操作。
序列化与反序列化
java bean
1 | public class Person { |
序列化
1 | public static void main(String[] args) throws Exception{ |
反序列化
1 | ObjectMapper mapper = new ObjectMapper(); |
这也就是最基础的json序列化与反序列化操作
当然,这样简单的demo是没有什么安全问题的,问题出在于一些可选配置上
DefaultTyping
1 | public enum DefaultTyping { |
默认情况下,mapper.enableDefaultTyping()
什么参数都不加时,会默认调用OBJECT_AND_NON_CONCRETE
1 | public ObjectMapper enableDefaultTyping() { |
重点说下OBJECT_AND_NON_CONCRETE
这个参数
考虑如下这一种情况,序列化的对象的成员变量中,数据类型是一个 抽象类/接口 (或者直接看代码来的易懂点
1 | public class Person { |
这时候对这个类进行反序列化的时候,可以看到是无法进行反序列化的
1 | Person p = new Person(); |
大意就是说由于Cls
这个变量是一个抽象类,所以反序列化失败。因为jackson也不知道要反序列化它的哪一个实现。
这时候就需要开启enableDefaultTyping
,对数据类型进行指定
将上面的代码加一条mapper.enableDefaultTyping();
,就可以看到反序列化成功了
1 | Person p = new Person(); |
比较两次序列化后的json字符串,可以看到,多了指定的数据类型。
1 | 未开启enableDefaultTyping // {"name":"kingkk","age":20,"cls":{"name":"cls1"}} |
jackson也就可以根据数据类型去自动反序列化 出对应的类
那假如有一个Cls2
,将传入的json字符串变成{"name":"kingkk","age":20,"cls":["cls.Cls2",{"name":"cls2"}]}
是否也可以反序列化出对应的类呢,显然是可以的。
修改下
1 | String json = "{\"name\":\"kingkk\",\"age\":20,\"cls\":[\"cls.Cls1\",{\"name\":\"cls1\"}]}"; |
那假如将数据类型Cls
改成Object
呢?是否就可以反序列化出任意类?
修改下Person
类型
1 | public class Person { |
假设此时有一个存在危险函数的类
1 | public class Vuln { |
尝试去反序列化这个Vuln
类
1 | ObjectMapper mapper = new ObjectMapper(); |
可以看到是可以反序列化到任意类的,而且当setter
或构造函数中存在危险函数时也会自动触发。
CVE-2017-7525
显然,实际代码中开发也几乎不可能写出那样不靠谱的Vuln
类,也为了寻找一种更为通用的反序列化链,也就是所说的Gadget
CVE-2017-7525
中就是利用JDK7u21的com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl
作为Gadget。
具体的触发流程我也没具体跟进了,总的原理和之前Vuln
类中的原理类似。
触发的调节为
- jackson databind 2.7.10 及2.8.9以下版本
- 开启了
enableDefaultTyping
- 类中存在
Object
类型的成员变量,或者想要反序列化类的抽象类/接口?
在这篇文章中也了解到http://www.leadroyal.cn/?p=630
当java bean的字段上加上了
@JsonTypeInfo(use = JsonTypeInfo.Id.CLASS)
@JsonTypeInfo(use = JsonTypeInfo.Id.MANIMAL_CLASS)
两个注解时,即使没有开启enableDefaultTyping
也可以进行指定类的反序列化。亲测有效。
漏洞修复
至于漏洞的修补比较惊讶的是基于黑名单的修复,仅仅限制了可以反序列化的类,导致之前的Poc失效。
https://github.com/FasterXML/jackson-databind/commit/60d459cedcf079c6106ae7da2ac562bc32dcabe1
也就意味着只要找到新的Gadget就还是可以利用这个洞(咋感觉比之前Weblogic XMLDecoder的修复还要不靠谱!
References
http://www.leadroyal.cn/?p=594
http://www.leadroyal.cn/?p=616
http://www.leadroyal.cn/?p=630
https://github.com/vulhub/vulhub/tree/master/jackson/CVE-2017-7525