0x00 产品简介
Config-Server
和Config-Client
两个角色。其中Config-Server可以配置多种源获取配置,如从git,svn,native等。其中第一个红框,https://github.com/spring-cloud/spring-cloud-config/commit/651f458919c40ef9a5e93e7d76bf98575910fad0
在下方测试代码进行了一定的增改,其中findOne函数里面的payload为上一次CVE-2019-3799的测试代码,对测试代码进行了增改想必是为了这一次漏洞做变更,重点留意到这里使用的是native本地仓库配置
根据上述分析,尝试配置sping-cloud-config-server的仓库为本地仓库,在进行验证
根据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