Spring Cloud Function SpEL表达式注入

漏洞概述

Spring Cloud Function 是基于Spring Boot 的函数计算框架(FaaS),该项目提供了一个通用的模型,用于在各种平台上部署基于函数的软件,包括像 Amazon AWS Lambda 这样的 FaaS(函数即服务,function as a service)平台。它抽象出所有传输细节和基础架构,允许开发人员保留所有熟悉的工具和流程,并专注于业务逻辑。

在版本3.0.0到当前最新版本3.2.2 (@dc5128b80c6c04232a081458f637c81a64fa9b52),默认配置下,都存在Spring Cloud Function SpEL表达式注入漏洞。

漏洞复现

在IDEA中选择新建项目,然后选择Spring Initializr,项目名称随便输入,然后选择java版本和jdk版本后点击下一步。

接着选择Spring WebFunction作为依赖项后点击完成。

这时漏洞环境就搭建完成了,因为当前官方还没出新版本,所以最新版本3.2.2也是存在漏洞的,若在官方出新版本后想要复现此漏洞,那么需要修改pom中spring-cloud-function-web的版本为3.2.2,如下图所示

确认项目中的spring-cloud-function-web是存在漏洞版本后,就可以直接启动项目了,无需进行任何修改。


然后对本地8080端口发送payload即可。

Payload

漏洞分析

先看git提交记录,https://github.com/spring-cloud/spring-cloud-function/commit/0e89ee27b2e76138c16bcba6f4bca906c4f3744f
在这个提交描述中,明确的指出修复了RoutingFunction SpEL代码注入漏洞,并且可以看到他只更新了两个文件,其中一个文件还是单元测试。

而且在测试用例中也清楚的写明了漏洞位置以及相关测试Payload.

通过测试用例我们已经知道,在给Spring Cloud Function的web服务发送包的时候,加一个相关的Header头,然后后面跟上SpEL表达式即可执行命令。

在文件org.springframework.cloud.function.context.config.RoutingFunction中,请求进入到apply方法,接着调用了route方法,然后通过判断特定的消息头信息是否为空,如果不为空则调用functionFromExpression方法


然后就调用到了SpEL对routingExpression进行解析,从而导致了SpEL表达式注入。

整个逻辑中由于完全信任从开始传入的header信息,并且在解析SpEL表达式时候的evalContext使用的是功能更强同时安全隐患较大的StandardEcalutionContext.

在官方最新的修补文件中,可以看到新增了headerEvalContext对象,该对象所对应的是使用了仅支持最基本功能的SimpleEvaluationContext

且在调用functionFromExpression方法的时候新增了一个isViaHeader布尔类型的参数,用来判断该值是否是取自消息的header中,如果是则使用headerEvalContext对象来解析SpEL表达式。

TIPS

最后修改:2022 年 03 月 28 日
如果觉得我的文章对你有用,请随意赞赏