[CVE-2020-5405] spring-cloud-config-server path through Vulnerability Analysis

0x00 Product Introduction

Spring Cloud Config is Spirng Cloud components for distributed configuration management, divided Config-Serverand Config-Clienttwo roles. Wherein Config-Server may be configured to acquire a variety of sources disposed, as seen from git, svn, native like.
 
0x01 vulnerability Profile
In the configuration repository for the next local native case, an attacker can get arbitrary files with the suffix on the server config-server
 
0x02 flaw affects version
2.2.x prior to 2.2.2
2.1.x prior to 2.1.7
 
0x03 vulnerability rating
High-risk (Official Rating)
 
0x04 Vulnerability Analysis
Basic environment to build, https://github.com/spring-cloud/spring-cloud-config/releases/tag/v2.1.1.RELEASE , pulling extract the zip package, introduced into idea
Check out the official commit, vulnerability analysis position

 

Where the first red box, https://github.com/spring-cloud/spring-cloud-config/commit/651f458919c40ef9a5e93e7d76bf98575910fad0

Deleted resolveName and reolveLabel code, the code (_) is replaced with /, most likely cause of the vulnerability

 

 

In the test code below some additions and changes, which findOne function on the inside of the payload once CVE-2019-3799 test code, test codes have been additions and changes must be done to change this loophole once, the focus of notes used here It is native local repository configuration

 

According to the above analysis, try to configure sping-cloud-config-server repository local repository during authentication

Configuring configserver.yml, modify the file: /// path after the local repository path, which reads https://github.com/spring-cloud-samples/config-repo/

 

 The variation of resolveName resolveLabel and try to break the @RequestMapping ( "/ {name} / {profile} / {label} / **")

 

 In tracking function to GenericResourceRepository findOne

 

 

Changes github commit contrast, the new location of a judge

 

Guess this.service.getLocations in a problem, continue to follow up

 

 Continue to follow up getLocations, the program jumps org.springframework.cloud.config.server.environment.NativeEnvironmentRepository getLocations method

 

The label is true with the location directly at addLableLocations property stitching, to determine whether a directory exists, there is then added to the output array, and finally pass into the Locations object is returned, it is clear that this is the problem

 

In connection with the previous resolveLable retrieve the label in process (_) is replaced by /, which can be configured to find out the payload of

 

 

 

 The key point made it clear that, after subsequent testing, payload structure is as follows:

payload

 1 doubt: according to the test directory, the directory should be a two-jump to the root of why there by a three-jump?

See FileUrlResource in first with createRelcativeURL been processed

 

 

 Continue to follow up, to deal with the URL found

 

Follow internal, found parseURL strips the first /../, so the actual time to jump catalog of more than passing

 

 Doubt 2: Why not obtain the file without a suffix?

See retrieve function in the operation to get the file back content, "StringUtils.getFilenameExtension (resource.getFilename ()) toLowerCase ();.", Try to get a suffix, because there is no suffix returns null, null object do toLowerCase abnormal operation, and then to do because there is no exception caught, causing the program to exit

 

 When subsequent official patch vulnerabilities as well say this to bug fixes, https://github.com/spring-cloud/spring-cloud-config/commit/740153b5aa74d960116f28be9c755e3b7debd2a2

Guess you like

Origin www.cnblogs.com/r00tuser/p/12458518.html