暂无简介
前言
我看完CVE-2022-22963,便着手深入Spel表达式,希望能够深入研究Spel究竟出现在哪些地方,怎么挖掘新的漏洞。挺感谢导师的帮助的,毕竟我实在太菜了,连反馈邮箱都不会写。
项目
考虑到这么多的组件如果一个个去尝试,显得太累了,我把自己实验时的代码都做成一个集合,放出来,方便有兴趣的师傅们一起讨论(项目:spel search)。先介绍各个组件使用Spel的情况。
spring-cloud-starter-netflix-turbine
application.properties
turbine.cluster-name-expression="T(Runtime).getRuntime().exec('calc')"
无法配合actuator,需要/actuator/env、/actuator/restart
其中/actuator/restart时,会异常,导致服务崩溃
spring-cloud-stream
@StreamListener注解
@StreamListener(value = Sink.INPUT, condition = "T(Runtime).getRuntime().exec('calc')")
注解是一个不可控的点
Spring-cloud-kubernetes
application.properties
spring.cloud.kubernetes.discovery.filter=T(Runtime).getRuntime().exec('calc')
可配合/actuator/env,但是无法命令执行,原因如下
执行Spel时需要执行上下文,SimpleEvaluationContext并不支持T(Runtime)
因此如果执行会报以下问题
Spring-data-jpa
@Query
@Query(value="select * from user where id = ?#{T(Runtime).getRuntime().exec('calc')}", nativeQuery=true)
可以getshell,但是可以忽略危害性。
Spel场景总结
基本上可以确定的是,Spel的存在可能基本是存在于配置类与注解中的。我在其他与Spring cloud相关的组件也存在一些Spel解析的地方但都是在配置类或者注解中,并且还是硬编码,这就没有放出来的意义了。
CVE-2022-22980
在我不断的挖掘过程中,终于找到了一个算是有问题的Spel表达式注入了。Spring-data-mongodb。说实话,这个漏洞挖掘起来应该没个运气都找不到。本人开始也不觉得是个漏洞,但是综合考虑了@Query和@Aggregation设计的目的,以及spring data jpa也支持这个,但是两者解析却存在十分大的差距,便觉得这个问题从正常角度确实不太算一个合法的漏洞,只能算是一个危险的API。但是从设计的角度,我觉得它是属于安全BUG。
spring data jpa与spring data mongodb
其实拿spring data jpa来说,jpa也同样支持@Query中做spel。但是如果你尝试用类似于
@Query(value="?#{?0}", nativeQuery=true)
jpa的Spel解析
spring data jpa也支持spel,如下
@Query(select * from user where name= ?#{?1},nativeQuery=true)
public User getUserByName(String name);
spring data jpa有两处会解析spel,第一次在启动的时候会触发,第二处在收到请求时触发。
启动解析Spel
先会经过if(!containsExpression(query))判断,这里的比较属于硬编码比较
即比较查询语句是否存在