CVE-2018-1274 漏洞分析与总结

CVE-2018-1274 漏洞分析与总结

安全脉搏SecPulse.Com独家发文，如需转载，请先联系授权。

0x01 漏洞描述

Spring Data Commons, versions prior to 1.13 to 1.13.10, 2.0 to 2.0.5, and older unsupported versions, contain a property path parser vulnerability caused by unlimited resource allocation. An unauthenticated remote malicious user (or attacker) can issue requests against Spring Data REST endpoints or endpoints using property path parsing which can cause a denial of service (CPU and memory consumption).

漏洞出于 spring-data-commons 中的 PropertyPath 里

同时影响到了 spring-data-rest

0x02 spring-data-commons

先来分析 spring-data-commons

同样，直接跟漏洞描述中的关键字就好： * property path *

结果如下图：

但是找到后不知道从哪里下手......看了下 commit ，如下：

补丁的情况就是，当 base 的大小超过 1000 的时候直接抛错，看下这个 create 函数的逻辑中发现了迭代过程，当满足一定条件的时候，会根据传入的 source ，一直迭代调用 create

那么现在就去看看触发条件，反向跟踪

跟出三条线

1.  QuerydslPredicateArgumentResolver#resoveArgument

2.  MapDataBinder->MapPropertyAccessor#setPropertyValue

3.  PartTree

0x03 querydsl

第一条触发流程线，是 dsl query 功能中对函数参数预绑定过程中触发的

直接从 QuerydslPredicateArgumentResolver 开始看

如下：

上图中，在 for 循环里将所有请求参数放入了 parameters 中，随后又带入了 getPredicate 函数里，跟进去

如上图，完全可控的 values 中的键，被带入了 getPropertyPath 中，继续跟

带入了 of 函数中，继续跟

最后就放入到了 PropertyPath.form 函数里，并且 path 是完全可控的，官方给出的测试 demo 就是直接使用了 PropertyPath.from 函数，在 from 函数流程中也调用了分析开头的 create 函数，所以dsl query 功能的触发流程是已经分析完了，那么如何构造payload？

看下官方测试demo：

上图中，先是生成了大量的 foo.bar.foo.bar.... 重复字符串，然后带入了 PropertyPath.from 中，指定 type 为 Left 类，主要作用是以 path 为成员变量名，然后在指定类中搜寻其信息

那么我们再去看一下官方给出的 Left 测试类是啥情况：

结合着 payload 来看，foo 指向 Right 类，bar 指向 Left 类，那么意味着两个类互相成为彼此的类成员了，并且在调用 from 函数的时候，是以 Left 类中的类成员变量名 foo 开始的.....这里就感觉到要触发 dos 要求还是有点高：

1. 目标类中存在另一个类的类成员变量

2. 同时在那个类中也有目标类的成员变量

3. 需要知道这两个成员变量的变量名

于此同时，这里分析的是 querydsl 功能，它是可以暴露在web端的。在 spring-data-examples 项目中可以找到 demo

路径如下：

要能让 QuerydslPredicateArgumentResolver 出现在调用流程中的话，必须在 controller 类中函数参数里加上 @QuerydslPredicate 注解，因为本质上它是一种参数绑定的实现

上图中可以见到，为 querydsl 指定的目标类是 User.class ，那么为了要触发dos，我们还得自己改一下代码

User 类：

图里的 User2 是我自己添的一个新类

最后的payload放在键值对的键里，如下图：

当然，url 有长度限制，采用post之类的更好，这里只是演示下

0x04 MapDataBinder

第二条线其实和 CVE-2018-1273 的点在同一处地方，因为使用了 PropertyPath 做解析，如下图

propertyName 是我们完全可控的，由上图课件，先是经过了 spel 解析，然后带入了 getPropertyPath 中，跟进去看看

也是带入了 from 函数中，与之前第一条线构造payload一样了，仅仅将 CVE-2018-1273 中的 spel 表达式的payload换成 foo.bar.foo.bar..... 之类的就行了

0x05 PartTree

这个纯粹是工具类，测试代码如下：

0x06 spring-data-rest

其实和去年的 CVE-2017-8046 是同样的触发流程，只是呢在补丁中使用了  PropertyPath 去验证 path 段的值是否是目标类中的成员，如果不是的话，直接抛出异常，所以杜绝了 spel 的rce，但是 CVE-2018-1274 正是利用的  PropertyPath 的解析漏洞，所以触发了 dos

如下图：

思路就是，还是以前的payload，只需要改 path 段，然后有两个类相互嵌套调用，进去之后。由于会在解析 spel 表达式前，先用  PropertyPath 检查 path ，所以就造成了 dos

0x07 referer：

https://pivotal.io/security/cve-2018-1274

相关文章<Spring Security Oauth RCE(CVE-2018-1260)漏洞复现与分析>

本文作者：orich1

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/71762.html