问答
发起
提问
文章
攻防
活动
Toggle navigation
首页
(current)
问答
商城
实战攻防技术
漏洞分析与复现
NEW
活动
摸鱼办
搜索
登录
注册
SpringFramework CVE-2024-38816 路径穿越浅析
漏洞分析
当使用 RouterFunctions 来处理静态资源且资源处理通过 FileSystemResource 进行配置时,攻击者可以通过构造恶意 HTTP 请求,利用路径遍历漏洞获取相关受影响版本文件系统中的任意文件。
0x00 CVE-2024-38816 =================== ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-a8b49d89fb351d5c006a579855110da10e20174b.png) **主要影响范围:** Spring Framework - 5.3.0 - 5.3.39 - 6.0.0 - 6.0.23 - 6.1.0 - 6.1.12 - Older, unsupported versions are also affected 当使用 RouterFunctions 来处理静态资源且资源处理通过 FileSystemResource 进行配置时,攻击者可以通过构造恶意 HTTP 请求,利用路径遍历漏洞获取相关受影响版本文件系统中的任意文件。以WebFlux为例,分析具体的成因。 0x01 漏洞分析与复现 ============ 1.1 分析过程 -------- 查看具体的修复commit:<https://github.com/spring-projects/spring-framework/commit/d86bf8b2056429edf5494456cffcb2b243331c49#diff-25869a3e3b3d4960cb59b02235d71d192fdc4e02ef81530dd6a660802d4f8707> 可以看到主要是对`PathResourceLookupFunction`进行了相关的加固处理,调整了 RouterFunctions 资源处理逻辑。 `org.springframework.web.reactive.function.server.PathResourceLookupFunction` 是 Spring WebFlux 中用于查找资源的函数,它通常与 `RouterFunction` 一起使用,以便在响应式路由中处理静态资源请求。这个函数的作用是将请求的路径映射到文件系统中的资源,如图片、样式表或 JavaScript 文件等。 主要解析处理是在apply方法进行的,下面看看具体的解析过程: - 首先从 ServerRequest 中提取路径容器 PathContainer,它包含了应用程序上下文中的路径。首先检查提取的路径是否与预定义的模式匹配。如果不匹配,返回一个空。 - 如果路径匹配,使用 `this.pattern.extractPathWithinPattern` 方法提取模式内的路径部分,并将其传递给 `processPath` 方法进行进一步处理。 - 如果处理后的路径包含百分号编码,则使用 `StringUtils.uriDecode` 方法对其进行解码。检查解码后的路径是否有效,主要是是否非空且不是非法路径(通过isInvalidPath进行判断) - 最后如果是有效的路径,尝试创建一个 `Resource` 对象。并返回对应的内容。 ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-9e1d3440e8ceb605ffa9dbf75b39badf31eb3015.png) 查看下processPath方法的具体实现,其主要用于处理和规范化文件路径字符串。该方法的主要作用是确保路径以正斜杠(`/`)开始,并且移除路径中不必要的部分: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-61e06ef0237d63b89b0b1e0bfee7388d80fe7493.png) isInvalidPath方法实现如下,主要是限制了一些路径中常出现的字符字符,防止目录穿越攻击: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-5a5136794ebed951e490460abb3d663425b30bd6.png) 以上是`PathResourceLookupFunction`的大致处理过程。具体的安全措施可以看到主要是对`../`这类的穿越符进行了处理。 下面对比下加固后的`PathResourceLookupFunction`,看看具体的安全措施: 首先processPath进行了相关的改动,首先替换反斜线为斜线: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-c96015ad81275f06c6ba81586b7bd9c566f14c21.png) 并调用cleanDuplicateSlashes去掉了多余的斜线: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-0305d09178644ed5588fe2cba85d9b92dfa51185.png) 在调用processPath处理后,还调用了isInvalidEncodedInputPath方法进行安全检查,如果为true则返回空: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-740ab1dc3829b98feb8ff295c87b9efe3722a132.png) isInvalidEncodedInputPath具体实现如下,主要作用是检查给定的路径字符串是否包含不合法的编码输入,可以看到当path路径中存在%号时,首先会进行URL解码,然后通过isInvalidPath进行判断,然后再经过一层processPath转换,这里意图应该是替换反斜线为斜线并去除多余的斜线,然后再进行一次isInvalidPath检查: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-4f417bec9da7c4398cc8f608c2acf365d4ad696d.png) 最后还修改了isResourceUnderLocation的判断逻辑,把原来的解码后判断是否包含`../`修改成了isInvalidEncodedInputPath方法进行检查: - 风险版本 ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-f5ec6692470655e611230925ffbaca2fc790a4a8.png) - 修复版本 ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-ff658b9b4d51369dc3c69975b51cdf240cff14ab.png) 从修复代码看,猜测相关的利用主要与反斜线以及URL编码有关。尝试进行复现。 ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-9d8ad75b2e752fba8ac4591ad5e28cb083491900.png) 1.2 漏洞复现 -------- ### 1.2.1 环境搭建 根据之前的分析,反斜线很自然就联想到在Windows中能通过..\\的方式来目录穿越。尝试在Windows环境下进行复现,通过RouterFunction模拟相关的静态资源映射: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-9aec2db4244a10a30813e8ac17c708a4dd087cbe.png) 通过上述映射,即可以通过/portal路由访问C盘Log目录下的静态资源。 spring相关版本: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-bc09907d49226faee2eefe99dd14f706d10ac0a0.png) ### 1.2.2 复现过程 直接`..\/..\/windows/win.ini`方式尝试利用肯定是不行的。因为在isInvalidPath中会调用cleanPath进行处理,然后判断处理后的路径是否包含`../`。其中会对反斜线进行相关的转换,最终会认为是非法路径: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-56c501015b34fb0474eba019f2671b44cef304f9.png) 结合前面的分析可以考虑URL编码,首先Spring自身会对路径做一层解码。所以得编码两次。例如下面的例子,此时isInvalidPath判断的是`..%5c`,不会认为是非法字符: ```Java ..%255c/..%255c/..%255c/windows/win.ini ``` 然后调用createRelativeURL完成相应的封装: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-46e1a0b35a2b8e47b090ba14504f6c5ae9ec929c.png) 在对应URL调用时,getInputStream中openConnection会再解码一次。此时即可绕过相关的安全限制。以读取Downloads下的test.txt为例。可以看到最终成功绕过对应的限制,跨目录获取到了相关的文件: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-bd7228f526c9ddf212345b3ba71b28aee223562c.png) 0x02 其他 ======= 实际上Spring历史上也出现过类似的风险,`ResourceHttpRequestHandler` 是 Spring MVC 中用于处理静态资源请求的一个关键组件。它实现了 `HttpRequestHandler` 接口,专门用于映射和处理静态资源文件的请求。 对比ResourceHttpRequestHandler和PathResourceLookupFunction的代码,其实在processPath的实现上是类似的。 org.springframework.web.reactive.function.server.PathResourceLookupFunction(Spring-WebFlux): ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-37eb903383703a13d930d55dbeaf0fd46acca9fe.png) org.springframework.web.servlet.resource.ResourceHttpRequestHandler#getResource: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-e838ad948f5723631b29e6da64c94b337124f96f.png) 两者均是对反斜线进行了相关的处理,相对于ResourceHttpRequestHandler而言,主要是为了修复CVE-2018-1271: ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-6891a1243da7532d48aa529871361d3b95b5187d.png) 除此之外,还可以看到其他漏洞的痕迹,spring-cloud-config历史目录穿越中,对于CVE-2019-3799的利用同样也是基于createRelative的逻辑,才会有类似双重URL编码的绕过利用: ```Plain ..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252Fetc%252Fpasswd ``` ![image.png](https://shs3.b.qianxin.com/attack_forum/2024/09/attach-652a89f13e871fc86f578b3d2d50b52f97ff2e37.png) 感觉**CVE-2024-38816**的利用类似**CVE-2019-3799**和**CVE-2018-1271**的结合。
发表于 2024-09-20 14:46:37
阅读 ( 2524 )
分类:
开发框架
2 推荐
收藏
0 条评论
请先
登录
后评论
tkswifty
1 篇文章
×
发送私信
请先
登录
后发送私信
×
举报此文章
垃圾广告信息:
广告、推广、测试等内容
违规内容:
色情、暴力、血腥、敏感信息等内容
不友善内容:
人身攻击、挑衅辱骂、恶意行为
其他原因:
请补充说明
举报原因:
×
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!