【CVE-2020-5405】spring-cloud-config-server路径穿越漏洞分析

0x00 产品简介

Spring Cloud Config是Spirng Cloud下用于分布式配置管理的组件，分为Config-Server和Config-Client两个角色。其中Config-Server能够配置多种源获取配置，如从git，svn，native等。

 

0x01 漏洞简介

在配置仓库为本地native的状况下，攻击者能够获取config-server服务器上的任意带后缀文件

 

0x02 漏洞影响版本

2.2.x prior to 2.2.2

2.1.x prior to 2.1.7

 

0x03 漏洞等级

高危（官方评级）

 

0x04 漏洞分析

基础环境搭建， https://github.com/spring-cloud/spring-cloud-config/releases/tag/v2.1.1.RELEASE，拉取zip包解压，导入至idea

查看官方commit，分析漏洞位置

 

其中第一个红框，https://github.com/spring-cloud/spring-cloud-config/commit/651f458919c40ef9a5e93e7d76bf98575910fad0

删除了resolveName和reolveLabel的代码，代码将(_)替换为/，颇有多是形成这次漏洞的缘由

 

 

在下方测试代码进行了必定的增改，其中findOne函数里面的payload为上一次CVE-2019-3799的测试代码，对测试代码进行了增改想必是为了这一次漏洞作变动，重点留意到这里使用的是native本地仓库配置

 

根据上述分析，尝试配置sping-cloud-config-server的仓库为本地仓库，在进行验证

配置configserver.yml，修改file:///后路径为本地仓库路径，其内容为https://github.com/spring-cloud-samples/config-repo/

 

 根据resolveLabel和resolveName的变更，尝试下断点至@RequestMapping("/{name}/{profile}/{label}/**")

 

 在跟踪至GenericResourceRepository findOne函数时

 

 

对比github commit的变更,新增了一个对location的判断

 

猜想this.service.getLocations中出现了问题，继续跟进

 

 继续跟进getLocations，程序跳至org.springframework.cloud.config.server.environment.NativeEnvironmentRepository getLocations方法

 

在addLableLocations属性为true时将label与location直接进行拼接，判断目录是否存在，存在则添加到output数组中，最后传进Locations对象中返回，很明显这里就是问题所在

 

结合前面在retrieve方法中resolveLable将label中的(_)替换为/，基本能够摸清payload的构造

 

 

 

 关键点说清楚了，经后续调试，构造payload以下：

payload

 疑点1：按照测试的目录，应该是跳两层目录至根目录为何这里用了三层跳？

看到FileUrlResource中先是用createRelcativeURL进行了处理

 

 

 继续跟进，发现使用URL来处理的

 

跟进内部，发现是parseURL会去除第一个/../，因此实际跳目录的时候要多传入

 

 疑点2：为何会获取不到没有后缀的文件？

看到retrieve函数中在获取到文件内容后面的操做，“StringUtils.getFilenameExtension(resource.getFilename()).toLowerCase();”，尝试获取后缀，因为没有后缀返回null，空对象作toLowerCase操做出现异常，然后又因为没有作异常捕获，致使程序直接退出

 

 后续官方在修补漏洞的时候也顺带把这个bug给修补了，https://github.com/spring-cloud/spring-cloud-config/commit/740153b5aa74d960116f28be9c755e3b7debd2a2