【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