九维团队-绿队（改进）| 王者打不上去了？一起来看个spring-boot devtools反序列化吧

当配置是以下这种情况时即表示项目启用了远程devtools，这时候会存在安全风险。

pom：

<dependency>            <groupId>org.springframework.boot</groupId>            <artifactId>spring-boot-devtools</artifactId><!--            <scope>runtime</scope>-->            <optional>true</optional>        </dependency>

*左右滑动查看更多

application.yml：

devtools:    restart:      enabled: true  #设置开启热部署      additional-paths: src/main/java #重启目录      exclude: WEB-INF/**    remote:      secret: mysecret

*左右滑动查看更多

下面我们就来简要分析一下为什么会产生风险，以及产生什么样的风险。

因为SpringBoot所有的自动配置都是由xxxAutoConfiguration来进行的，已知：

orgspringframeworkbootspring-boot-devtools2.6.4spring-boot-devtools-2.6.4.jar!orgspringframeworkbootdevtoolsautoconfigureRemoteDevToolsAutoConfiguration.class

*左右滑动查看更多

是devtools的自动配置类。

上半部分是有关spring.devtools.remote.secret配置的实现。

查看流程，首先是将SecretHeaderName、Secret的值传入到HttpHeaderAccessManager类进行处理。

跟进HttpHeaderAccessManager类：

在该类中会获取请求头中的一个参数headerName做比对，如果headerName的值与expectedSecret不一致就会报403。

回到RemoteDevToolsAutoConfiguration，跟进对应的DevToolsProperties类查看SecretHeaderName、Secret：

orgspringframeworkbootspring-boot-devtools2.6.4spring-boot-devtools-2.6.4.jar!orgspringframeworkbootdevtoolsautoconfigureDevToolsProperties.class

*左右滑动查看更多

跟进RemoteDevToolsProperties，在getSecretHeaderName方法中返回的是X-AUTH-TOKEN，即http的头部有一个X-AUTH-TOKEN头。

而getSecret则是从配置文件中获取：

回到remoteDevToolsAccessManager方法，那么HttpHeaderAccessManager对象返回的就是对X-AUTH-TOKEN: Secret校验结果。

往下看下半部分。

这部分属于RemoteRestartConfiguration静态类，该类是devtools开关配置实现类：

查看remoteRestartHandlerMapper方法流程。

首先查看该方法里的properties.getRemote()，跟进对应的DevToolsProperties类：

orgspringframeworkbootspring-boot-devtools2.6.4spring-boot-devtools-2.6.4.jar!orgspringframeworkbootdevtoolsautoconfigureDevToolsProperties.class

*左右滑动查看更多

getRemote方法返回的是RemoteDevToolsProperties对象：

跟进RemoteDevToolsProperties对象。

该类返回各种对应的属性值：

其中getContextPath方法返回的是remoteRestartHandlerMapper方法中的url。

拼接得出远程访问的url为/.~~spring-boot!~/restart。

然后往下走进入到HttpRestartServerHandler：

跟进HttpRestartServer类：

在该类的handle方法中，获取请求封装为objectInputStream对象，随后使用ObjectInputStream的readObject方法对request进行反序列化，因为request是可控的，所以导致漏洞产生。

实际想要利用这个漏洞，条件其实有点苛刻（所以只能算风险项），要满足以下几个条件：

首先看第一点：

结合对headerName的比对想象一下，即使我们不知道密码，但是可以通过状态来爆破密码，即：

所以，可以利用403跟500来爆破密码，密码问题就不用太担心了。

其次看“生产环境需要启用devtools Remote”。

条件苛刻的原因就在这里，开头讲到的配置其实是大多数情况下针对测试环境的配置，其中因为：

<plugin>                <groupId>org.springframework.boot</groupId>                <artifactId>spring-boot-maven-plugin</artifactId>                <configuration><!--                    <fork>true</fork>-->                    <excludeDevtools>true</excludeDevtools>                </configuration>            </plugin>

*左右滑动查看更多

在打包成jar后，devtools就不会启用，也就是说如果要利用成功，spring-boot-maven-plugin的属性就要是false，这样才能打包带上devtools。

我们可以测试一下：

引用依赖：

  <dependency>            <groupId>org.springframework.boot</groupId>            <artifactId>spring-boot-devtools</artifactId><!--            <scope>runtime</scope>-->            <optional>true</optional>        </dependency>

*左右滑动查看更多

Idea自己导入的版本为2.6.4。

正常配置启用远程热部署，即开头的配置（如果是idea直接运行，Boolean无论是什么都会启用Remote DevTools），如果远程热部署启用成功，项目启动后会有提示：

下面在默认配置下打包成jar试试：

可以看到devtools没了，将spring-boot-maven-plugin的属性改成false再打包试一下：

将属性改成false后打包的生产环境会包含Remote DevTools。

最后，尝试把序列化后的恶意数据发送触发：

1、在使用Springboot-devtools工具时，建议按照官方的文档说明谨慎启用远程模块。如不需要在生产环境启用远程模块，在打包项目时检查 <excludeDevtools>标签的属性是否设置成true：

<plugin>                <groupId>org.springframework.boot</groupId>                <artifactId>spring-boot-maven-plugin</artifactId>                <configuration>                    <excludeDevtools>true</excludeDevtools>                </configuration>            </plugin>

*左右滑动查看更多

2、如果要启用远程模块，建议在配置文件中将secret改为随机大小写字母+数字+特殊字符组合的密码。

具体操作参考及推荐阅读可参见：

https://medium.com/@sherif_ninja/springboot-devtools-insecure-deserialization-analysis-exploit-2c4ac77c285ahttps://docs.spring.io/spring-boot/docs/current/reference/html/using.html#using.devtools.remote-applicationshttps://docs.spring.io/spring-boot/docs/current/reference/html/using.html#using.devtools

*左右滑动查看更多