Spring Cloud Function Spel表达式注入漏洞分析
0x0 背景
Spring Cloud Function 是基于Spring Boot 的函数计算框架（FaaS），当其启用动态路由functionRouter时， HTTP请求头 spring.cloud.function.routing-expression参数存在SPEL表达式注入漏洞，攻击者可通过该漏洞进行远程命令执行。主要影响的版本包括 3.0.0.RELEASE <= Spring Cloud Function <= 3.2.2
0x1 本地环境搭建
简单了解了一下FaaS的的函数交付模式，和之前研究的容器安全场景下的微服务架构非常的契合，以往的大多数环境主要通过虚拟机交付逐渐演变了成了VPS、容器、API到现在的函数即服务；资产被更加充分的利用，为此本地以Jdk1.8的环境，IDE用了IntelliJ IDEA搭建一个漏洞环境；
首先需要创建一个项目文件，选择Spring Initalizr；需要事先配置好项目Java环境，避免后续build的时候需要用到tools.jar和dt.jar
依赖性此处主要选择Function和Spring Web二个关键项目
相关的配置项目可以在pom.xml当中进行修改，从项目当中可以看到依赖的组件版本为3.2.2是存在漏洞的版本，即可直接启动项目，无需其他的修改；
0x2 POC复现与分析
项目需要bulid、后run直接运行，可以在控制框当中看到启动的输出内容；默认启动tomcat容器开放8080端口
通过web浏览器可直接进行访问，此处主要使用Postman进行一个发包测试；通过poc的代码解读，利用方式相对比较简单直接在请求的headers头上添加一个spring.cloud.function.routing-expression参数，SpringCloud Function会直接将其参数内容直接带入到SPEL中查询，造成SPEL漏洞注入。
Spring web首先会确认当前的请求是否为RoutingFunction，确认后并将我们提交的请求头和请求体内容编译成Message并且传入FunctionInvocationWrapper的apply方法中 找到对应方法的RoutingFunction.class的文件内容，定位到对应的第80行的代码出，可以发现该方法主要Message的内容已经被传递过来；
F7跟进后可以看到恶意内容被Expression expression = this.spelParser.parseExpression(routingExpression)进行了执行从而产生的表达式注入的风险；
由于此类攻击行为可以远程执行任意命令，危害度较高很多开发人员没有安全意识的背景下直接新建项目后都会出现此类攻击数据的行为；但是此类攻击普遍没有回显攻击者须要借助于DNSLOG类的平台或者通过RCE进行下一步的payload运行、反弹shell等操作；
该攻击从流量层面也比较简单识别，比较难得是识别攻击成功的场景；只能结合后续的上下文的因果关联监听后续网络行为了；
0x3 修复
国内这一块的影响相对还是比较小，目前FasS还没有大规模的使用开；官方提供的功能有Spel表达式解析能力，但都没有对指定EvaluationContext，采用默认的StandardEvaluationContext从而导致了命令执行。具体措施可更新Spring Cloud Function到3.2.3。
