Spring处理参数值出错时会将参数中${}中的内容当作SPEL解析实现，造成RCE漏洞
当使用JSON PATCH对数据修改时，传入的PATH参数会解析SPEL
在Model的数据绑定上存在漏洞，但漏洞出发条件比较苛刻
由于没有明确指定相关Model的具体属性，导致从表单可以提交恶意的表达式SPEL被执行
其中的STOMP模块发送订阅命令时，支持选择器标头，该选择器充当基于内容路由的筛选器
这个筛选器selector属性的值会解析SPEL导致RCE
请求参数中如何包含SPEL会被解析，参考下方Payload
username[#this.getClass().forName("java.lang.Runtime").getRuntime().exec("calc.exe")]
该漏洞的利用条件是可出网，可以POST访问/env接口设置属性，且可以访问/refresh刷新配置
在VPS上开启HTTP Server并放入基于ScriptEngineManager和URLClassLoader的yml，制作特殊的JAR并指定
通过/env设置spring.cloud.bootstrap.location属性再刷新配置即可利用SnakeYAML的反序列化漏洞实现RCE
该漏洞的利用条件同样是可出网，可以POST访问/env接口设置属性，且可以访问/refresh刷新配置
首先搭建恶意的XStream Server其中包含了Payload
通过/env设置eureka.client.serviceUrl.defaultZone属性再刷新配置即可访问远程XStream Payload触发反序列化达到RCE
如果目标可出网且存在/jolokia或/actuator/jolokia接口
通过/jolokia/list查看是否存在ch.qos.logback.classic.jmx.JMXConfigurator和reloadByURL关键词
搭建一个HTTP Server保存XML配置文件，再启动恶意的JNDI Server，请求指定的URL即可触发JNDI注入漏洞达到RCE
如果目标可出网且存在/jolokia或/actuator/jolokia接口
启动恶意的JNDI Server后调用createJNDIRealm创建JNDIRealm，然后写入JNDI相关的配置文件，重启后触发JNDI注入漏洞达到RCE
漏洞利用条件是可以访问/env设置属性，可以访问/restart重启应用
设置spring.datasource.hikari.connection-test-query属性为创建自定义函数的SQL语句，再数据库连接之前会执行该SQL语句
通过重启应用，建立新的数据库连接，触发包含命令执行的自定义函数，达到RCE
目标可出网且存在spring.h2.console.enabled=true属性时可以利用
首先通过/h2-console中记录下JSESSIONID值，然后启动恶意的JNDI Server，构造对应域名和JSESSIONID的特殊POST请求触发JNDI注入漏洞达到RCE
该漏洞的利用条件同样是可出网，可以POST访问/env接口设置属性，且可以访问/refresh刷新配置，不同的是需要存在mysql-connector-java依赖
通过/env得到mysql版本等信息，测试是否存在常见的Gadget依赖，访问spring.datasource.url设置指定的MySQL JDBC URL地址。刷新配置后当网站进行数据库操作时，会使用恶意的MySQL JDBC URL建立连接
恶意的MySQL Server会返回序列化Payload数据，利用本地的Gadget反序列化造成RCE
该漏洞的利用条件同样是可出网，可以POST访问/env接口设置属性，且可以访问/restart重启
搭建一个HTTP Server保存XML配置文件，再启动恶意的JNDI Server
通过/env接口设置logging.config属性为恶意的XML配置文件，重启触发JNDI注入漏洞达到RCE
该漏洞的利用条件同样是可出网，可以POST访问/env接口设置属性，且可以访问/restart重启
启动恶意的JNDI Server并通过/env接口设置logging.config属性为恶意的Groovy文件在重启后生效
在logback-classic组件的ch.qos.logback.classic.util.ContextInitializer中会判断url是否以groovy结尾，如果是则最终会执行文件内容中的groovy代码达到RCE
类似SpringBoot Restart logging.config Groovy RCE
组件中的org.springframework.boot.BeanDefinitionLoader判断url是否以groovy结尾，如果是则最终会执行文件内容中的groovy代码，造成RCE漏洞
该漏洞的利用条件同样是可出网，可以POST访问/env接口设置属性，且可以访问/restart重启
开一个HTTP Server保存恶意SQL语句，这是一个执行命令的函数，设置属性spring.datasource.data为该地址，重启后设置生效
组件中的org.springframework.boot.autoconfigure.jdbc.DataSourceInitializer使用runScripts方法执行请求URL内容中的SQL代码，造成RCE漏洞
本质还是SPEL表达式，本来这是一个需要修改配置文件导致的鸡肋RCE漏洞
但因为Gateway提供了Actuator相关的API可以动态地注册Filter，而在注册的过程中可以设置SPEL表达式
实战利用程度可能不高，目标未必开着Actuator接口，就算开放也不一定可以正常访问注册Filter的接口
P牛在漏洞爆出的凌晨就发布了相关的环境和POC
参考P牛的回显代码：在相应头里面添加一个新的头，利用工具类把执行回显写入
{
"name": "AddResponseHeader",
"args": {
"value": "#{new java.lang.String(T(org.springframework.util.StreamUtils).copyToByteArray(T(java.lang.Runtime).getRuntime().exec(new String[]{\"whoami\"}).getInputStream()))}",
"name": "cmd123"
}
}参考很多SPEL漏洞的修复手段，默认情况使用StandardContext可以执行Runtime.getRuntime().exec()这样的危险方法
修复是重写一个GatewayContext用来执行SPEL，这个context的底层是SimpleEvaluationContext只能执行有限的操作
这也是Spring Cloud种的一个组件，不过并不常用
利用方式是某个请求头支持SpEL的格式并且会执行
POST / HTTP/1.1
...
spring.cloud.function.routing-expression: SPEL修复方案比较简单，使用SimpleEvaluationContext即可
参考先知社区4ra1n师傅的文章：https://xz.aliyun.com/t/11114
危害不大，但影响较广，所有能够执行SpEL的框架，都可以通过初始化巨大的数组造成拒绝服务漏洞
修复方案是限制SpEL种数组初始化的长度（一般业务也不可能在SpEL种初始化很大的数组）