自检代码中trustmanager漏洞_Fasterxml Jacksondatabind漏洞分析与利用

一、 Fasterxml Jackson-databind 组件介绍

FasterXML Jackson是美国FasterXML公司的一款适用于Java的数据处理工具。Jackson-databind是其中的一个具有数据绑定功能的组件。Jackson-databind可以将Java对象转换成json对象，同样也可以将json转换成Java对象。

二、各版本介绍

Fasterxml的jackson-databind使用至今，主要版本可以分为三类，分别是jackson-databind-2.10.x及以上，jackson-databind-2.9.10.x和jackson-databind-2.9.x及以下。当下所有漏洞涉及的范围为后两类，第一类版本的更新已经将目前已知的公开payload中的恶意类全部加入到了黑名单中，从而完成此类漏洞的修复。

三、 使用量及使用分布

根据全网数据统计，使用fasterxml jackson-databind的网站多达30万余，其中大部分集中在美国，而中国的使用量排在第二位。其中上海、北京、山东、浙江四省市使用量最高。通过网络空间搜索引擎的数据统计和柱状图表，如下图所示。

四、漏洞背景介绍

1. JNDI注入

JNDI( Java Naming and Directory Interface )，是Java平台的一个标准扩展，提供了一组接口、类和关于命名空间的概念。如同其它很多Java技术一样，JDNI是provider-based的技术，暴露了一个 API和一个服务供应接口(SPI)。这意味着任何基于名字的技术都能通过JNDI而提供服务，只要JNDI支持这项技术。JNDI目前所支持的技术包括 LDAP、CORBA Common Object Service(COS)名字服务、RMI、NDS、DNS、Windows注册表等等。很多J2EE技术，包括EJB都依靠JNDI来组织和定位实体。可以把它理解为一种将对象和名字捆绑的技术，对象工厂负责生产出对象，这些对象都和唯一的名字绑在一起，外部资源可以通过名字获得某对象的引用。

上述定义读起来有些拗口，但是实际上JNDI只是对于RMI，LDAP等服务的一层封装，通过统一上层的调用形式，来使开发人员不用在意底层各样的实现形式。

如上图中所展现的，从整个JNDI的架构来看，LDAP等SPI(service provider interface)都处在最底层，经过命名的管理，最终整合成统一的JNDI API提供给上层java 应用使用。

JNDI主要包含两大操作，一个是bind，另一个是lookup.可以将JNDI理解为一个大的字典表，其中bind来向其中放置键值对，而lookup用来搜索，给定名称，找到对应的对象，并加载进来，即由键取值，本批漏洞也主要是基于这一点。

2. Fasterxml使用

• 总述

  Fasterxml jackson-databind有两种多态类型绑定方法，分别是全局的DefaultTpying和局部的@jsonTypeInfo注解两种方式，下面分别来对其进行简单的介绍。

• 注解

  当对对象使用@jsonTypeInfo注解时，就可以通过指定@class或者@c等简写完成反序列化。

• EnableDefaultTyping

  DefaultType中一共有四个值如下：

其中JAVA_LANG_OBJECT指当对象属性类型为Object时生效; OBJECT_AND_NON_CONCRETE指当对象属性类型为Object或者非具体类型(抽象类和接口)时生效;NON_CONCRETE_AND_ARRAYS指当对象属性类型为Object或者非具体类型(抽象类和接口)或者所有的数组元素的类型都是非具体类型或者对象类型时生效；NON_FINAL对所有非final类型或者非final类型元素的数组。

一旦fasterxml使用了上述的任何一种性质，都可以造成本批漏洞的产生，即危险类的加载。

五、高危漏洞介绍

通过对fasterxml漏洞的收集和整理，过滤出其中影响版本在2.9.9及以前的高危漏洞，可以得出如下列表：

漏洞名称	漏洞ID	影响版本	漏洞披露日期
Fasterxml 远程 代码执行漏洞	无	Fasterxml Jackson-databind < 2.9.0	2017/6/27
Fasterxml 远程 代码执行漏洞	CVE-2018-12022	Fasterxml Jackson-databind < 2.9.5	2018/5/30
Fasterxml 远程 代码执行漏洞	CVE-2018-12023	Fasterxml Jackson-databind < 2.9.5	2018/6/8
Fasterxml 远程 代码执行漏洞	CVE-2018-19361	Fasterxml Jackson-databind < 2.9.7	2018/11/19
Fasterxml 远程 代码执行漏洞	CVE-2018-19361	Fasterxml Jackson-databind < 2.9.7	2018/11/19
Fasterxml 远程 代码执行漏洞	CVE-2019-14379	Fasterxml Jackson-databind < 2.9.9	2019/7/23
Fasterxml 远程 代码执行漏洞	CVE-2019-14439	Fasterxml Jackson-databind < 2.9.9	2019/7/23
Fasterxml 远程 代码执行漏洞	CVE-2019-14540	Fasterxml Jackson-databind < 2.9.9	2019/8/6
Fasterxml 远程 代码执行漏洞	CVE-2019-14540	Fasterxml Jackson-databind < 2.9.9	2019/8/6
Fasterxml 远程 代码执行漏洞	CVE-2019-14439	Fasterxml Jackson-databind < 2.9.9	2019/9/11
Fasterxml 远程 代码执行漏洞	CVE-2019-14439	Fasterxml Jackson-databind < 2.9.9	2019/9/11
Fasterxml 远程 代码执行漏洞	CVE-2019-17267	Fasterxml Jackson-databind < 2.9.9	2019/9/17
Fasterxml 远程 代码执行漏洞	无	Fasterxml Jackson-databind < 2.9.9	2019/9/20

从上表可以看出，这些漏洞大多都是2018/2019两年爆出，并且都是集中在2.9.x版本。

这些都是高风险的远程代码执行漏洞，并且不需要任何的二次开发与复杂的配置，只需要用户使用的组件或者框架集成了上述fasterxml jackson-databind版本并且配置了enableDefaultTyping且依赖库中存在有漏洞的依赖即可。攻击者通过用户暴露出的fasterxml 序列化接口，直接构造恶意流量便可以在服务器上先反序列化之后再序列化(如果在属性的get方法中出现问题则需要再次序列化)时执行任意代码。

这些漏洞的成功利用依赖于三个条件，其一是高危依赖库，包括JDK中自带的某些类和外部引用的依赖。第二是enableDefaultTyping函数的使用，该函数的使用通过设置四种情形，都可以导致类的加载，从而造成漏洞的产生，所以不使用其是最可靠的，但是同时也会牺牲很大一部分的功能；最后是先反序列化再序列化的逻辑，这一点似乎看上去很可笑，但是在大量代码堆积的情况下，很有可能忽略了该问题，从而导致了上述代码逻辑的产生。另一个实际应用中的可能是为了将输入的字符串进行标准化，过滤一些无用字符从而先反序列化再序列化。还有一点需要注意的就是，本条件仅仅是一些在get方法中触发漏洞的恶意类需要，而一些已存在或者潜在的直接使用set触发漏洞的恶意类却并不需要。总体来说，此类漏洞利用难度较高，但是一旦成功利用，便可以轻松获取服务器的最高权限，影响较大，所以，开发者在集成fasterxml进行开发的过程中，一定需要关注其历史风险点，尽量规避高危依赖库，enableDefaultTyping函数的使用以及先反序列化再序列化的执行逻辑。

六、漏洞利用链

下面总体给出了每个漏洞想要利用成功的必要条件：

从图中很容易可以看出，在满足上述的三个条件下，最终可以实现RCE并getShell.

下面给出本次使用的全部jar包，每一个jar包都可以导致远程代码执行：

七、 高可利用漏洞分析

1. Fasterxml 远程代码执行1

1.1 威胁等级

严重

1.2 影响范围

Fasterxml Jackson-databind < 2.9.0

1.3 利用难度

困难

1.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind < 2.9.0版本中缺少com.sun.rowset.JdbcRowSetImpl黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

1.5 漏洞分析

• 漏洞触发点

首先定位到com.sun.rowset中的JdbcRowSetImpl类，搜索用于jndi连接的lookup方法，可以定位到326行如下：

可以看出这里面lookup方法将dataSourceName的值当做JNDI连接的地址，并且只要调用connect方法时conn为空且dataSourceName不为空即可触发，于是继续寻找connect方法的调用位置。

最终定位到我们想要的set方法中，到此，payload的构造的方法就呼之欲出了。

• 漏洞触发流程

通过上述漏洞触发点的分析，容易看出只需要最终反序列化时能够成功调用setAutoCommit方法即可。并且根据fasterxml反序列化的特性，反序列化时会调用给定属性的set方法，于是这里面我们只需要对包含JNDI地址的传入数据进行反序列化即可。给出整个的调用栈如下：

首先进入反序列化入口如下：

这里面的readValue是使用set方法将rmi的值设置进去，后面的writeValueAsString则再次进行序列化，使用get方法。此漏洞中，直接在反序列化过程中使用set方法即可触发漏洞。

进入ObjectClass类的readValue方法

这里面将传入的payload和Object分别封装在两个类中，并进行下一步的处理。接着进入到ObjectMapper类中的_readMapAndClose方法中：

第1528行的_initForReading方法获取了正常情况下(即以’[‘开始)的标识位START_ARRAY,接着进入1534行的else，首先是获取到序列化配置信息cfg, 接着将其和将要解析的内容p一起放置在ctxt中，而findValueDeserializer则可以获取带有valueType的序列化器。接着会进入1540行开始进行反序列化。

然后不断下移，一直进入到UntypedObjectDeserializer类的deserializeWithType方法，继续进入序列化

一直到AsArrayTypeDeserializer类中的_deserializer方法

其中第67行获取到了该类字符串，单步进入68行的TypeDeserializerBase类中的_findDeserializer方法

其中86行因为this._deserializer是空的，所以deser也是null，88行实现了payload中类的反射，104行将反射出的类放入到了序列化器中。

下面进入到BeanDeserializer类中的vanillaDeserialize方法中

第189行确认了payload中的属性，如果出现不存在的属性就会在这里出现问题。接着进入198的序列化。

最后进入到MethodProperty类中的deserializeAndSet方法中：

78行的invoke将会一步步嵌套调用到set方法来设置属性，并触发上述提到的lookup方法实现攻击。

• 补丁对比

首先通过github的补丁比较，可以发现在BeanDeserializerFactory类中将该恶意类加入到了黑名单中

下面来分析一下该黑名单是怎么实现防护的。继续深入代码查看，回到上面ObjectMapper类中的_readMapAndClose方法中，第1536行中的方法内部就对黑名单进行了过滤，接下来继续深入该方法。

然后不断深入，在反射出恶意类时继续进入DeserializerCache类的_createAndCacheValueDeserializer方法的第113行的方法

一直进入到BeanDeserializerFactory类中的createBeanDeserializer方法如下：

可以轻松发现其中的checkIllegalTypes方法，进入查看

这里面就用到了前面的黑名单，一旦包含恶意类，就将报错退出。

另外，这里需要提到的一点是，fasterxml的黑名单变更过位置：

• 2.9.0之前不存在黑名单

• 2.9.0-2.9.3黑名单放在BeanDeserializerFactory类中

• 2.9.4-2.11.3黑名单放在SubTypeValidator类中

2. Fasterxml 远程代码执行2

2.1 威胁等级

严重

2.2 影响范围

FasterXML Jackson-databind <= 2.9.5

2.3 利用难度

困难

2.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind <= 2.9.5版本中缺少jodd.db.connection.DataSourceConnectionProvider黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

2.5 漏洞分析

• 漏洞触发点

首先定位到jodd.db.connection包中的DataSourceConnectionProvider类，搜索用于jndi连接的lookup方法，可以定位到27行如下：

可以看出这里的lookup存在于构造函数中，并且lookup的参数是直接传入的，该构造函数同时被另外另一单参数构造函数调用，到此，payload的构造就很明朗了。

• 漏洞触发流程

这里面漏洞的触发与上一个略有不同，是在构造函数中直接触发的，下面来逐步分析一下整个的调用过程。首先给出整个的调用栈如下：

通过此调用栈和上一个漏洞的调用栈对比，可以发现差别在BeanDeserializer类中的deserializer方法中：

如上图所示，差别出在第87行的判断，对于第一种的set形式，判断为真，对于第二种的构造函数形式，判断为假所以进入另一个序列化的方法。对于这里进入另一个序列化方法之后的内容，我们暂且不进行探究，先带着已知的结论去探索这里的true或者false是怎么确定的。

首先定位到this._vanillaProcessing属性值的修改位置，发现并没有set方法，只在父类BeanDeserializerBase中存在一个构造函数如下：

由图中可以发现，该属性值同时由上面几个属性同时决定，所以一步步来分析上面的属性。

首先通过比较构造方法的payload与set方法的payload在创建BeanDeserializer对象时的关键词区别，可以发现导致this._vanillaProcessing值不一样的根本原因就是this._nonStandardCreation值的不同，而从该属性的名称来看，似乎也可以验证创建方法不同而导致反序列化流程不同的猜想。于是继续深入追踪该参数。

通过上面的图可以看出，this._nonStandardCreation由五个值确定，分别是this._unwarppedPropertyHandler, this._valueInstantiator.canCreateFroomObjectWith(), this._valueInstantiator.canCreateUsingDelegate(), this._valueInstantiator.canCreateUsingArrayDelegate(), this._valueInstantiator.canCreateUsingDefault()，并且通过下面的比较，可以发现，差别体现在最后一个参数，于是继续去深入该值。

继续走到StdValueInstantiator类中的canCreateUsingDefault方法，显然，该方法的返回值取决于this._defaultCreator的值。

到这里，看到这个名字，基本也猜到大概了，应该是看是否能够使用默认的空构造方法。第一种set显然就可以直接使用空构造方法，所以该值为true, 而第二种不可以，所以值为false。出于严谨的态度，继续溯源this._defaultCreator值的来源。顺便提一句，之前提到的其他四个参数也分别对应其他类型的构造方法。

经过溯源，发现该参数的来源如下：

由CreatorCollector类中的constructValueInstantiator方法中的defaultCtor传入，而该值由this._creators[0]决定，对于set的情况，this._creators[0]有值，为空构造方法，而对于第二种情况，this._creators[0]为空，从而导致了后面值为空。

为验证上述流程分析的正确性，比较一下两种情况的构造函数如下：

显然第二种确实没有空构造方法，至此，上述判断上的分支原因以及一目了然了。至于其他情况，例如有空构造方法但是仍然使用了带参构造方法的情况，出现分支的原因大致也就是上述几大影响属性的值有所变化了，尤其是后面的几个其他构造方法的依赖，这里就不做过多阐述了。

下面接着上面的分支处继续向下分析。在分支判断处进入BeanDeserializer类中的_deserializeOther方法中。并顺势进入BeanDeserializerBase类中的deserializerFromString方法中，之后进入StdValueInstantiator类中的createFromString方法中，内容如下：

这里因为不是从String的构造方法过来的，所有使用指定类的构造方法，进入206行，调用call1方法，接着就从之前提取的构造方法调用到构造方法如下：

到此，整个流程也就梳理完毕了。

• 补丁对比

同样的，官方补丁将该类加入了黑名单。

3. Fasterxml 远程代码执行3

3.1 威胁等级

严重

3.2 影响范围

FasterXML Jackson-databind <= 2.9.5

3.3 利用难度

困难

3.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind <= 2.9.5版本中缺少oracle.jdbc.connector.OracleManagedConnectionFactory黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

3.5 漏洞分析

• 漏洞触发点

首先定位到oracle.jdbc.connector包中的OracleManagedConnectionFactory类，搜索用于jndi连接的lookup方法，可以定位到150行如下：

可以看到在setupXADataSource方法中调用了lookup函数寻址，由此可以触发漏洞。向上回溯到setupXADataSource方法的调用位置。

可以看到在getLogWriter方法中调用了该方法，至此，此漏洞的触发点就寻找完毕了。

• 漏洞触发流程

通过上述漏洞触发点的分析，容易看出只需要最终反序列化时能够成功调用getLogWriter方法即可。并且根据fasterxml反序列化的特性，反序列化时会调用给定属性的set方法，并在序列化时调用get方法，于是这里面我们需要先对包含JNDI地址的传入数据进行反序列化之后再进行序列化操作。其中反序列化的过程与第一个一样，不再重复阐述，而序列化的调用栈如下：

下面，本文将顺着上述调用栈梳理本漏洞的序列化过程。

首先来到刚开始的writeValueAsString方法，并进入ObjectMapper类中的该方法中。

接着进入1193行的ObjectMapper类中的_configAndWriteValue

该函数传入了一个buffer和我们payload中的恶意类对象，1447行首先初始化序列化配置，这个序列化配置和之前的反序列化配置内容基本差不多，接着进入1453行开始序列化。这里的buffer带有我们原来的字符串，正常情况下应该是不存在的，这里估计是因为之前反序列化和这里的序列化用的是同一个序列化对象，之前的数据有存储在里面。接着进入DefaultSerializerProvider类中的serializerValue方法中：

在165行传入恶意类，找到序列化的配置，进入184行SerializerProvider类中的findTypedValueSerializer方法中开始序列化。

298行首先查找是否存在已知的序列化配置，这里面没有，接着302行在缓存中查找，发现也没有，于是进入386行找到序列化配置。

最后遍历所有的属性，进入invoke，最后触发get，触发lookup，从而完成漏洞的利用。

• 补丁对比

同样的，官方补丁将该类加入了黑名单。

4. Fasterxml 远程代码执行4

4.1 威胁等级

严重

4.2 影响范围

FasterXML Jackson-databind <= 2.9.7

4.3 利用难度

困难

4.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind <= 2.9.7版本中缺少org.apache.openjpa.ee.RegistryManagedRuntime黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

4.5 漏洞分析

• 漏洞触发点

首先定位到org.apache.openjpa.ee包中的RegistryManagedRuntime类，搜索用于jndi连接的lookup方法，可以定位到35行如下：

可以看到这里直接在get方法中调用lookup方法，所以到此漏洞触发点就找到了。

• 漏洞触发流程

通过上述漏洞触发点的分析，容易看出只需要最终反序列化时能够成功调用getTransactionManager方法即可。并且根据fasterxml反序列化的特性，反序列化时会调用给定属性的set方法，并在序列化是会调用get方法，于是这里面我们需要先对包含JNDI地址的传入数据进行反序列化之后再进行序列化操作。并且这两个过程都与上面的流程一样，不再重复阐述，仅仅给出反序列化和序列化的调用栈。

• 补丁对比

同样的，官方将该类加入到了黑名单中。

5. Fasterxml 远程代码执行5

5.1 威胁等级

严重

5.2 影响范围

FasterXML Jackson-databind <= 2.9.7

5.3 利用难度

困难

5.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind <= 2.9.7版本中缺少org.apache.openjpa.ee.JNDIManagedRuntime黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

5.5 漏洞分析

• 漏洞触发点

首先定位到org.apache.openjpa.ee包中的JNDIManagedRuntime类，搜索用于jndi连接的lookup方法，可以定位到32行如下：

可以看到这里直接在get方法中调用lookup方法，所以到此漏洞触发点就找到了。

• 漏洞触发流程

通过上述漏洞触发点的分析，容易看出只需要最终反序列化时能够成功调用getTransactionManager方法即可。并且根据fasterxml反序列化的特性，反序列化时会调用给定属性的set方法，并在序列化是会调用get方法，于是这里面我们需要先对包含JNDI地址的传入数据进行反序列化之后再进行序列化操作。并且这两个过程都与上面的流程一样，不再重复阐述，仅仅给出反序列化和序列化的调用栈。

• 补丁对比

同样是加入黑名单。

6. Fasterxml 远程代码执行6

6.1 威胁等级

严重

6.2 影响范围

FasterXML Jackson-databind <= 2.9.9

6.3 利用难度

困难

6.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind <= 2.9.9版本中缺少net.sf.ehcache.transaction.manager.DefaultTransactionManagerLookup黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

6.5 漏洞分析

• 漏洞触发点

同样的，首先去net.sf.ehcache.transaction.manager包中的DefaultTransactionManagerLookup类中搜索lookup的位置，但是这次很可惜，并没有直接搜索到，仅仅搜索到一个带有lookup的函数如下：

继续向下跟进，进入102行的getTransactionManager方法中：

来到Selector类中的该方法，可以明显看到有一个doLookup函数，进入该函数查看：

进入到Selector类的子类JndiSelector类的doLookup函数中，可以发现第43行就调用了lookup方法，并且lookup参数也是前面set进去的，具体的set方法如下：

至此，此漏洞的触发点分析完毕。

• 漏洞触发流程

通过上述漏洞触发点的分析，容易看出只需要最终反序列化时能够成功调用getTransactionManager方法即可。并且根据fasterxml反序列化的特性，反序列化时会调用给定属性的set方法，并在序列化是会调用get方法，于是这里面我们需要先对包含JNDI地址的传入数据进行反序列化之后再进行序列化操作。并且这两个过程都与上面的流程一样，不再重复阐述，仅仅给出反序列化和序列化的调用栈。

• 补丁对比

同样的加入到了黑名单之中。

7. Fasterxml 远程代码执行7

7.1 威胁等级

严重

7.2 影响范围

FasterXML Jackson-databind <= 2.9.9

7.3 利用难度

困难

7.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind <= 2.9.9版本中缺少ch.qos.logback.core.db.JNDIConnectionSource黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

7.5 漏洞分析

• 漏洞触发点

首先去ch.qos.logback.core.db包的JNDIConnectionSource类中搜索lookup方法的调用，成功在如下位置找到：

接着溯源lookupDataSource方法，成功找到顶层的getConnection方法如下：

至此，漏洞触发点就寻找完成了。

• 漏洞触发流程

通过上述漏洞触发点的分析，容易看出只需要最终反序列化时能够成功调用getConnection方法即可。并且根据fasterxml反序列化的特性，反序列化时会调用给定属性的set方法，并在序列化是会调用get方法，于是这里面我们需要先对包含JNDI地址的传入数据进行反序列化之后再进行序列化操作。并且这两个过程都与上面的流程一样，不再重复阐述，仅仅给出反序列化和序列化的调用栈。

• 补丁对比

同样加入到了黑名单之中。

8. Fasterxml 远程代码执行8

8.1 威胁等级

严重

8.2 影响范围

FasterXML Jackson-databind <= 2.9.9

8.3 利用难度

困难

8.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind <= 2.9.9版本中缺少com.zaxxer.hikari.HikariConfig黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

8.5 漏洞分析

• 漏洞触发点

首先去com.zaxxer.hikari包的HikariConfig类中搜索lookup方法的调用，成功在如下位置找到：

之后向上溯源，可以找到getObjectOrPerformJndiLookup方法的调用位置，这里一共有两个调用位置，这里只给出其中一个，另一个放在下一个漏洞的描述当中：

至此，此漏洞的触发点就寻找完毕了。

• 漏洞触发流程

可以发现这里是直接set调用了lookup，所以只需要有一个反序列化的过程即可。下面给出其调用栈：

• 补丁对比

同样加入到了黑名单之中。

9. Fasterxml 远程代码执行9

9.1 威胁等级

严重

9.2 影响范围

FasterXML Jackson-databind <= 2.9.9

9.3 利用难度

困难

9.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind <= 2.9.9版本中缺少com.zaxxer.hikari.HikariConfig黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

9.5 漏洞分析

• 漏洞触发点

首先去com.zaxxer.hikari包的HikariConfig类中搜索lookup方法的调用，成功在如下位置找到：

之后向上溯源，这里给出getObjectOrPerformJndiLookup方法的另一个调用位置如下：

至此，此漏洞的触发点就寻找完毕了。

• 漏洞触发流程

可以发现这里是直接set调用了lookup，所以只需要有一个反序列化的过程即可。下面给出其调用栈：

• 补丁对比

同样加入到了黑名单之中。

10. Fasterxml 远程代码执行10

10.1 威胁等级

严重

10.2 影响范围

FasterXML Jackson-databind <= 2.9.9

10.3 利用难度

困难

10.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind <= 2.9.9版本中缺少com.zaxxer.hikari.HikariDataSource黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

10.5 漏洞分析

• 漏洞触发点

首先去com.zaxxer.hikari包的HikariDataSource类中搜索lookup方法的调用，发现并没有该方法的调用，于是查看其父类，发现正是上一个漏洞中的HikariConfig类，那么剩下的内容就和之前的一样了。

之后向上溯源，可以找到getObjectOrPerformJndiLookup方法的调用位置，这里一共有两个调用位置，这里只给出其中一个，另一个放在下一个漏洞的描述当中：

至此，此漏洞的触发点就寻找完毕了。

• 漏洞触发流程

可以发现这里是直接set调用了lookup，所以只需要有一个反序列化的过程即可。下面给出其调用栈：

• 补丁对比

同样加入到了黑名单中。

11. Fasterxml 远程代码执行11

11.1 威胁等级

严重

11.2 影响范围

FasterXML Jackson-databind <= 2.9.9

11.3 利用难度

困难

11.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind <= 2.9.9版本中缺少com.zaxxer.hikari.HikariDataSource黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

11.5 漏洞分析

• 漏洞触发点

首先去com.zaxxer.hikari包的HikariDataSource类中搜索lookup方法的调用，发现并没有该方法的调用，于是查看其父类，发现正是上一个漏洞中的HikariConfig类，那么剩下的内容就和之前的一样了。

之后向上溯源，这里给出getObjectOrPerformJndiLookup方法的另一个调用位置如下：

至此，此漏洞的触发点就寻找完毕了。

• 漏洞触发流程

可以发现这里是直接set调用了lookup，所以只需要有一个反序列化的过程即可。下面给出其调用栈：

• 补丁对比

同样加入到了黑名单中。

12. Fasterxml 远程代码执行12

12.1 威胁等级

严重

12.2 影响范围

FasterXML Jackson-databind <= 2.9.9

12.3 利用难度

困难

12.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind <= 2.9.9版本中缺少net.sf.ehcache.hibernate.EhcacheJtaTransactionManagerLookup黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

12.5 漏洞分析

• 漏洞触发点

首先去net.sf.ehcache.hibernate包的EhcacheJtaTransactionManagerLookup类中搜索lookup方法的调用，发现并没有该方法的调用，于是查看其父类，发现正是之前存在漏洞的DefaultTransactionManagerLookup类，那么剩下的内容就和之前的一样了。

继续向下跟进，进入102行的getTransactionManager方法中：

来到Selector类中的该方法，可以明显看到有一个doLookup函数，进入该函数查看：

进入到Selector类的子类JndiSelector类的doLookup函数中，可以发现第43行就调用了lookup方法，并且lookup参数也是前面set进去的，具体的set方法如下：

至此，此漏洞的触发点分析完毕。

• 漏洞触发流程

通过上述漏洞触发点的分析，容易看出只需要最终反序列化时能够成功调用getTransactionManager方法即可。并且根据fasterxml反序列化的特性，反序列化时会调用给定属性的set方法，并在序列化是会调用get方法，于是这里面我们需要先对包含JNDI地址的传入数据进行反序列化之后再进行序列化操作。并且这两个过程都与上面的流程一样，不再重复阐述，仅仅给出反序列化和序列化的调用栈。

• 补丁对比

同样加入到了黑名单之中。

13. Fasterxml 远程代码执行13

13.1 威胁等级

严重

13.2 影响范围

FasterXML Jackson-databind <= 2.9.9

13.3 利用难度

困难

13.4 漏洞描述

FasterXML远程代码执行漏洞是由于JNDI注入导致远程代码执行， Jackson-databind <= 2.9.9版本中缺少oadd.org.apache.xalan.lib.sql.JNDIConnectionPool黑名单类，攻击者可以利用上述缺陷，绕过限制，实现JNDI注入，最终在受害主机上执行任意代码。

13.5 漏洞分析

• 漏洞触发点

首先去oadd.org.apache.xalan.lib.sql包的JNDIConnectionPool类中搜索lookup方法的调用，成功在如下位置找到其调用位置：

接着向上回溯，找到了findDatasource的调用位置如下：

至此，漏洞的触发点就很明确了。

• 漏洞触发流程

通过上述漏洞触发点的分析，容易看出只需要最终反序列化时能够成功调用getConnection方法即可。并且根据fasterxml反序列化的特性，反序列化时会调用给定属性的set方法，并在序列化是会调用get方法，于是这里面我们需要先对包含JNDI地址的传入数据进行反序列化之后再进行序列化操作。并且这两个过程都与上面的流程一样，不再重复阐述，仅仅给出反序列化和序列化的调用栈。

• 补丁对比

同样加入到了黑名单之中。

八、漏洞利用

1. Fasterxml 远程代码执行1

2. Fasterxml 远程代码执行2

3. Fasterxml 远程代码执行3

4. Fasterxml 远程代码执行4

5. Fasterxml 远程代码执行5

视频同Fasterxml 远程代码执行4

6. Fasterxml 远程代码执行6

7. Fasterxml 远程代码执行7

8. Fasterxml 远程代码执行8

9. Fasterxml 远程代码执行9

视频同Fasterxml 远程代码执行8

10. Fasterxml 远程代码执行10

视频同Fasterxml 远程代码执行7

11. Fasterxml 远程代码执行11

视频同Fasterxml 远程代码执行7

12. Fasterxml 远程代码执行12

13. Fasterxml 远程代码执行13

九、参考链接

1. https://github.com/FasterXML/jackson-databind/compare/jackson-databind-2.8.9...jackson-databind-2.8.10
2. https://github.com/FasterXML/jackson-databind/blob/3124dde9828caf80379a9483fbba3d095b9f0c00/src/main/java/com/fasterxml/jackson/databind/jsontype/impl/SubTypeValidator.java