spring

Spring Whitelabel SPEL RCE

Spring处理参数值出错时会将参数中${}中的内容当作SPEL解析实现，造成RCE漏洞

Spring Data REST SPEL RCE

当使用JSON PATCH对数据修改时，传入的PATH参数会解析SPEL

Spring Web Flow SPEL RCE

在Model的数据绑定上存在漏洞，但漏洞出发条件比较苛刻

由于没有明确指定相关Model的具体属性，导致从表单可以提交恶意的表达式SPEL被执行

Spring Messaging SPEL RCE

其中的STOMP模块发送订阅命令时，支持选择器标头，该选择器充当基于内容路由的筛选器

这个筛选器selector属性的值会解析SPEL导致RCE

Spring Data Commons SPEL RCE

请求参数中如何包含SPEL会被解析，参考下方Payload

username[#this.getClass().forName("java.lang.Runtime").getRuntime().exec("calc.exe")]

SpringCloud SnameYAML RCE

该漏洞的利用条件是可出网，可以POST访问/env接口设置属性，且可以访问/refresh刷新配置

在VPS上开启HTTP Server并放入基于ScriptEngineManager和URLClassLoader的yml，制作特殊的JAR并指定

通过/env设置spring.cloud.bootstrap.location属性再刷新配置即可利用SnakeYAML的反序列化漏洞实现RCE

SpringCloud Eureka RCE

该漏洞的利用条件同样是可出网，可以POST访问/env接口设置属性，且可以访问/refresh刷新配置

首先搭建恶意的XStream Server其中包含了Payload

通过/env设置eureka.client.serviceUrl.defaultZone属性再刷新配置即可访问远程XStream Payload触发反序列化达到RCE

SpringBoot Jolokia Logback JNDI RCE

如果目标可出网且存在/jolokia或/actuator/jolokia接口

通过/jolokia/list查看是否存在ch.qos.logback.classic.jmx.JMXConfigurator和reloadByURL关键词

搭建一个HTTP Server保存XML配置文件，再启动恶意的JNDI Server，请求指定的URL即可触发JNDI注入漏洞达到RCE

SpringBoot Jolokia Realm JNDI RCE

如果目标可出网且存在/jolokia或/actuator/jolokia接口

启动恶意的JNDI Server后调用createJNDIRealm创建JNDIRealm，然后写入JNDI相关的配置文件，重启后触发JNDI注入漏洞达到RCE

SpringBoot Restart H2 Database Query RCE

漏洞利用条件是可以访问/env设置属性，可以访问/restart重启应用

设置spring.datasource.hikari.connection-test-query属性为创建自定义函数的SQL语句，再数据库连接之前会执行该SQL语句

通过重启应用，建立新的数据库连接，触发包含命令执行的自定义函数，达到RCE

SpringBoot H2 Database Console JNDI RCE

目标可出网且存在spring.h2.console.enabled=true属性时可以利用

首先通过/h2-console中记录下JSESSIONID值，然后启动恶意的JNDI Server，构造对应域名和JSESSIONID的特殊POST请求触发JNDI注入漏洞达到RCE

SpringBoot Mysql JDBC RCE

该漏洞的利用条件同样是可出网，可以POST访问/env接口设置属性，且可以访问/refresh刷新配置，不同的是需要存在mysql-connector-java依赖

通过/env得到mysql版本等信息，测试是否存在常见的Gadget依赖，访问spring.datasource.url设置指定的MySQL JDBC URL地址。刷新配置后当网站进行数据库操作时，会使用恶意的MySQL JDBC URL建立连接

恶意的MySQL Server会返回序列化Payload数据，利用本地的Gadget反序列化造成RCE

SpringBoot Restart logging.config Logback JNDI RCE

该漏洞的利用条件同样是可出网，可以POST访问/env接口设置属性，且可以访问/restart重启

搭建一个HTTP Server保存XML配置文件，再启动恶意的JNDI Server

通过/env接口设置logging.config属性为恶意的XML配置文件，重启触发JNDI注入漏洞达到RCE

SpringBoot Restart logging.config Groovy RCE

该漏洞的利用条件同样是可出网，可以POST访问/env接口设置属性，且可以访问/restart重启

启动恶意的JNDI Server并通过/env接口设置logging.config属性为恶意的Groovy文件在重启后生效

在logback-classic组件的ch.qos.logback.classic.util.ContextInitializer中会判断url是否以groovy结尾，如果是则最终会执行文件内容中的groovy代码达到RCE

SpringBoot Restart spring.main.sources Groovy RCE

类似SpringBoot Restart logging.config Groovy RCE

组件中的org.springframework.boot.BeanDefinitionLoader判断url是否以groovy结尾，如果是则最终会执行文件内容中的groovy代码，造成RCE漏洞

SpringBoot Restart spring.datasource.data H2 Database RCE

该漏洞的利用条件同样是可出网，可以POST访问/env接口设置属性，且可以访问/restart重启

开一个HTTP Server保存恶意SQL语句，这是一个执行命令的函数，设置属性spring.datasource.data为该地址，重启后设置生效

组件中的org.springframework.boot.autoconfigure.jdbc.DataSourceInitializer使用runScripts方法执行请求URL内容中的SQL代码，造成RCE漏洞

最新的Spring Cloud Gateway SPEL的RCE漏洞

本质还是SPEL表达式，本来这是一个需要修改配置文件导致的鸡肋RCE漏洞

但因为Gateway提供了Actuator相关的API可以动态地注册Filter，而在注册的过程中可以设置SPEL表达式

实战利用程度可能不高，目标未必开着Actuator接口，就算开放也不一定可以正常访问注册Filter的接口

最新的Spring Cloud Gateway SPEL的RCE漏洞可以回显吗

{
    "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"
    }
}

最新的Spring Cloud Gateway SPEL的RCE修复

参考很多SPEL漏洞的修复手段，默认情况使用StandardContext可以执行Runtime.getRuntime().exec()这样的危险方法

修复是重写一个GatewayContext用来执行SPEL，这个context的效果是只能执行有限的操作