Shulou(Shulou.com)05/31 Report--

Nexus Repository Manager 2.x command injection vulnerability CVE-2019-5475 example analysis, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

Preface

In early September 2019, we responded to the Nexus Repository Manager 2.x command injection vulnerability (CVE-2019-5475), and its general cause and recurrence steps were published on hackerone. After the emergency, we analyzed the patch for the vulnerability and found that the repair was incomplete and could still be bypassed. This article records two bypassing of the vulnerability. Although two fixes have been released earlier, the official second update announcement is too slow for https://support.sonatype.com/hc/en-us/articles/360033490774, so it is only released now.

Update the timeline several times:

CVE-2019-5475 (2019-08-09)

First bypass, CVE-2019-15588 (2019-10-28)

Second bypass, no CVE assigned, updated announcement impact version (2020-3-25)

Note: the original vulnerability analysis, the first bypass analysis and the second bypass analysis are mainly written by Badcode, while the second bypass analysis + and the latest version analysis are mainly added by Longofo.

Original vulnerability analysis and utilization conditions

Administrator privileges required (default authentication: admin/admin123)

Loophole analysis

The code analyzed below is based on version 2.14.9-01.

The loophole appears in the Yum Repository plug-in when configuring Yum's createrepo or mergerepo

The code level jumps to the activationCondition method of YumCapability.

The value set in the above Path of "createrepo" is obtained through getConfig (). GetCreaterepoPath (), and after getting the value, call the this.validate () method

The incoming path is user-controllable, and then the path is concatenated-- version is then passed to the commandLineExecutor.exec () method, which looks like a way to execute a command, and that's the case. Follow up the exec method of the CommandLineExecutor class

Parse the command before executing the command, CommandLine.parse (), separated by spaces, to get the executable file and parameters.

Finally, Runtime.getRuntime (). Exec () is called to execute the command.

For example, the command passed in by the user is cmd.exe / c whoami, and finally the getRuntime () .exec () method is Runtime.getRuntime () .exec ({"cmd.exe", "/ c", "whoami"}).

So the principle of the vulnerability is also very simple, that is, when the createrepo or mergerepo path is set, the path can be specified by the user, concatenate the version string halfway, and finally getRuntime.exec () executes the command.

Loophole recurrence

Enter payload in the Path of "createrepo".

You can see the result of execution in the Status column.

First bypass analysis, first patch analysis.

The official patch has been changed in several places, and the key point is here.

As a general practice, you filter commands before executing them. A new getCleanCommand () method has been added to filter commands.

AllowedExecutables is a HashSet with only two values, createrepo and mergerepo. First determine whether the command passed by the user is in the allowedExecutables. If so, directly concatenate the params, that is, the version is returned directly. Then determine the path of the command passed in by the user, and return null directly if it starts with the working directory of nexus (applicationDirectories.getWorkDirectory (). GetAbsolutePath ()). Continue to determine that if the file name is not in allowedExecutables, it returns null, which means that the command needs to end with / createrepo or / mergerepo. After all pass the judgment, the absolute path of the file is stitched-- version returns.

First patch bypass

To be honest, when I saw this patch at first glance, I thought there was a good chance that it could be bypassed.

The incoming command meets two conditions, not starting with the working directory of nexus, and ending with / createrepo or / mergerepo.

When you see the getCleanCommand () method in the patch, new File (command) is the key, and new File () creates a new File instance by converting a given pathname string to an abstract pathname. It is worth noting that the path string can use spaces, that is,

String f = "/ etc/passwd / shadow"; File file = new File (f)

This is legal, and the value fetched by calling file.getName () is shadow. Combined with this feature, you can bypass the judgment in the patch.

String cmd = "/ bin/bash-c whoami / createrepo"; File file = new File (cmd); System.out.println (file.getName ()); System.out.println (file.getAbsolutePath ())

Running result

As you can see, the value of file.getName () is exactly createrepo, satisfying the judgment.

Bypass the test environment for the first time

Version 2.14.14-01

Linux

Test procedure

Enter payload in the Path of "createrepo".

View the results of the execution in the Status column

As you can see, the patch was successfully bypassed.

It is more troublesome in the Windows environment, because there is no way to execute the command in the form of cmd.exe / c whoami, because cmd.exe / c whoami becomes cmd.exe\ c whoami after new File (), which cannot be executed later. You can execute exe directly, and note that it will be concatenated later-- version, so many commands cannot be executed, but there are ways to use the ability to execute arbitrary exe to do subsequent attacks.

The second bypass analysis, the second patch analysis

After I submitted the above bypass, the authorities fixed the bypass. Take a look at the official patch.

A file.exists () is added to the getCleanCommand () method to determine whether the file exists. The previous form of / bin/bash-c whoami / createrepo certainly won't work, because the file doesn't exist. So now there is another judgment, which makes it more difficult. Is there no way around it? No, it can still be bypassed.

The second patch bypasses

Now the incoming command meets three conditions.

Does not start with the working directory of nexus

Ends with / createrepo or / mergerepo

And the createrepo or mergerepo file exists.

Seeing file.exists () reminds me of file_exists () in php, which I have encountered before when I was working on php. There is a system feature, in Windows environment, directory jump is allowed to jump to a directory that does not exist, while under Linux it is not possible to jump to a directory that does not exist.

Test it

Linux

As you can see, file.exists () returns false

Windows

File.exists () returned true

Above we said new File (pathname), pathname is allowed with spaces. Using the features in the above WIndows environment, set cmd to C:\\ Windows\\ System32\\ calc.exe\\..\..\\ win.ini

After the parse () method, you finally get to getRuntime.exec ({"C:\\ Windows\\ System32\\ calc.exe", "\\..\\..\\ win.ini"}), so you can execute calc.

In the above test win.ini is a real file, back to the patch, you need to determine the existence of createrepo or mergerepo. First of all, functionally, the createrepo command is used to create a yum source (software repository), that is, to index a large number of rpm packages stored in a specific local location, describe the dependency information required by each package, and form metadata. That is, this createrepo is unlikely to exist under Windows. If this does not exist, there is no way to judge. Since there is no createrepo in the server, try to create one. The first thing I try is to find an upload point and try to upload a createrepo, but I can't find a point whose name will remain the same after upload. After uploading at Artifacts Upload, it becomes the name of Artifact-Version.Packaging. Artifact-Version.Packaging this does not satisfy the second judgment, so it ends with createrepo.

At the beginning, when I saw file.exists (), I walked into the mindset, thinking that it was to judge the existence of the file, but after reading the official document, I found that it was the existence of the file or directory. This is the second key point of this vulnerability. I can't create files, but I can create folders. When Artifacts Upload uploads Artifacts, it can be defined by GAV Parameters.

When Group is set to test123,Artifact and test123,Version is set to 1, when uploading Artifacts, the corresponding directory will be created on the server. The corresponding structure is as follows

If we set Group to createrepo, then the corresponding createrepo directory will be created.

Combine two features to test it.

String cmd = "C:\\ Windows\\ System32\ calc.exe\..\ nexus\\ sonatype-work\\ nexus\\ storage\\ thirdparty\\ createrepo"; File file = new File (cmd); System.out.println (file.exists ()); System.out.println (file.getName ()); System.out.println (file.getAbsolutePath ())

As you can see, file.exists () returns true,file.getName () and createrepo, which is consistent with the judgment.

Finally, inside getRuntime () is probably getRuntime.exec ({"C:\ Windows\ System32\ notepad.exe", "\..\ nexus\ sonatype-work\ nexus\ storage\ thirdparty\ createrepo", "--version"})

Notepad.exe can be executed successfully. (you can't see the process in the calc.exe demo, so change it to Notepad.exe)

Bypass the test environment for the second time

Version 2.14.15-01

Windows

Test procedure

Enter payload in the Path of "createrepo".

To view the process, notepad.exe started

As you can see, the patch was successfully bypassed.

Bypass analysis for the second time +

After bypassing the analysis for the second time, Master Badcode can see that the command can be successfully executed on the Windows system. But there is one big limitation:

Nexus needs to be installed on the system disk

Some commands with parameters cannot be used

In the Artifacts Upload upload place mentioned above, you can upload any file, and the names of the uploaded files are all concatenated by custom parameters, so you can guess. Then you can upload any exe file you have written.

Bypass the analysis + test environment for the second time

Version 2.14.15-01

Windows

Test procedure

Navigate to Views/Repositories- > Repositories- > 3rd party- > Configuration, and we can see the absolute path of the default local storage location (later uploaded content is also in this directory):

Navigate to Views/Repositories- > Repositories- > 3rd party- > Artifact Upload, and we can upload malicious exe files:

The exe file will be renamed to createrepo-1.exe (concatenated by custom parameters):

Also enter payload in Path of "createrepo" (note that the previous part begins with the nexus installation directory, which will be judged in the patch, so you can add..\ or make a fake layer aaa\ in the top layer here):

You can see that createrepo-1.exe has been executed:

Latest version analysis the latest version patch analysis

After the second patch was bypassed, the official fix was carried out again. The official patches are mainly as follows:

Remove the previous fix, add the YumCapabilityUpdateValidator class, and verify the absolute equality between the value obtained in validate and the value set in properties using equals. This value can only be modified through sonatype-work/nexus/conf/capabilities.xml:

Verification of the latest version

Modification is directly prohibited at the front end, by grabbing the package to modify the test:

When YumCapabilityUpdateValidator.validate breaks to:

You can see that this fix can no longer be bypassed unless the configuration file is overwritten where the file is overwritten, such as unzipping the overlay, but it is not found.

However, the place where any file can be uploaded in Artifacts Upload is still there, and it can still be used if the above situation occurs again in other places.

After reading the above, have you mastered the Nexus Repository Manager 2.x command injection vulnerability CVE-2019-5475 example analysis method? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.