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

Today, I will talk to you about the example analysis of git config RCE CVE-2019-11229. Many people may not know much about it. In order to make you understand better, the editor has summarized the following for you. I hope you can get something according to this article.

On April 15, 2019, gitea exposed a vulnerability, which coincided with the curiosity of the vulnerability and began to study it. The description of the vulnerability is as follows:

Models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to remote code execution.

Under the joint research with my friend @ hammer, I successfully controlled the content of git config, but when I encountered difficulties in the process from git config to RCE, I shelved it for the time being. after a few months, I was inspired by @ Lz1y and @ x1nGuang and successfully recreated this loophole. Let's take a closer look at this problem.

Analyze patches

First of all, according to the information of cve, determine the fix on vulnerability 1.7.6 and 1.8.0-rc3.

According to the vulnerability file, the main commit,commit that locks updates for repo_mirror.go are # 6593 and # 6595.

According to patch, you can roughly lock in the key points of the problem.

/ models/repo_mirror.go

When the warehouse is a mirror warehouse, the settings page displays the configuration of mirror

If! repo.IsMirror {ctx.NotFound ("", nil) return}

Change the url option in the original modified configuration file to NewCommand in patch. It is easy to understand that changing the write file to execute the command must be due to the dilemma that the write file cannot be fixed, which means that url can change the line by passing in% 0d%0a, resulting in modification of other configurations in the config.

Control gitconfig

Following the previous logic, let's first create a new mirror repository.

Grab the package and modify the mirror_address to the corresponding attribute.

Mirror_address=https%3A%2F%2Ftest%3A%40github.com%2FLoRexxar%2Ftest_for_gitea.git ""% 0d%0a [core]% 0d% 0atestpurchase TMP% 0d% 0aa = "

You can pass in various configurations and control the contents of the config file.

Interestingly, if you update the synchronization settings, the server will also format the configuration.

Further utilization

The important thing is how to control the config file to use it next.

First of all, the git server only retains the contents of .git, which is not completely similar to the git repository used by our clients. So it is difficult to introduce external files. Otherwise, RCE can be achieved by setting the hook directory, and the key point of this idea is to find a controllable file write or file upload.

Second, another idea is to find a configuration that can execute commands and a remote configuration that can trigger the relevant configuration.

Https://git-scm.com/docs/git-config

Cooperate with githook path RCE by writing files

In git, there is something called Git Hook, which is used to execute the corresponding script when some operation is handled by the corresponding hook.

In the web interface, only the administrator of gitea can manage git hook, so for ordinary users, we can't modify the script directly by editing git hook.

However, we can modify the directory where hook is stored by controlling git config.

When we construct to send

Mirror_address=https%3A%2F%2Fgithub.com%2FLoRexxar%2Ftest_for_gitea.git ""% 0d%0a [core]% 0d% 0ahooksPathogenesis TMP% 0d% 0aa = "

The config file on the server becomes

So as long as we can write or create files anywhere on the server, we can set hookspath there and trigger git hook to execute the command.

After our careful study, we found that under the version 1.7.5 of the vulnerability, if you edit the file on the server side, then the file on the server side will be saved and generated in the running directory of gitea.

/ data/tmp/local-repo/ {repo_id}

This file will not be erased without restarting gitea, and the repo_id can be mined from other api.

Specific details of the utilization chain can be seen.

Https://www.jianshu.com/p/684fa071026a

It is worth noting that this approach requires knowing where the server is running, although we can think that the paths of go are similar, and some people will execute them in the current compilation directory. But it can be said that this approach is still unreliable.

RCE by controlling the git config configuration

With the help of @ x1nGuang boss, I re-examined some of the configurations related to git config.

GitProxy

GitProxy is a command that needs to be executed when operations such as fetch are needed for the git protocol. Is a configuration option for special scenarios. It is generally used in scenarios where a proxy application may be required when a git request is made.

Here we set up the server.

[core] gitproxy = calc.exe

Then note that the synchronized url must start with git

But the problem is that because gitProxy executes a proxy application in git design, no matter what you enter, it will be executed as an application, so there is no way to take parameters.

In this way, there is a great limitation in the actual utilization scenario. Here, you can try to upload a bin using the file upload function in an ordinary project, then grab the package to obtain the file path, and finally execute the backdoor through gitProxy.

But again, this idea is still limited by the directory where gitea runs, but version 1.8.0 can also use this way to RCE compared to previous uses.

SshCommand

Another configuration in git's documentation is sshCommand.

This is a system that allows git fetch/git push to connect to the remote end through ssh through a special configuration in git. This kind of use is also mentioned in @ Lz1y boss's blog.

Https://www.lz1y.cn/2019/07/20/CVE-2019-11229-Gitea-RCE/

We set sshCommand to the specified command

Mirror_address=https%3A%2F%2Ftest%3A%40github.com%2FLoRexxar%2Ftest_for_gitea.git ""% 0d%0a [core]% 0d% 0asshCommandparts calc.exe% 0d% 0aa = "

Then set the agreement to ssh save, and click synchronize.

Unlike gitProxy, it can follow the parameters

& mirror_address=https%3A%2F%2Ftest%3A%40github.com%2FLoRexxar%2Ftest_for_gitea.git ""% 0d%0a [core]% 0d% 0asshCommand = "touch 2333"% 0d% 0aa = "

After reading the above, do you have any further understanding of the example analysis of git config RCE CVE-2019-11229? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.