first commit

git/CVE-2017-8386/README.md

@@ -0,0 +1,129 @@
+# GIT-SHELL Sandbox Bypass Leads to RCE (CVE-2017-8386)
+
+[中文版本(Chinese version)](README.zh-cn.md)
+
+Git shell is a login shell for SSH accounts to provide restricted Git access. git-shell in git before 2.4.12, 2.5.x before 2.5.6, 2.6.x before 2.6.7, 2.7.x before 2.7.5, 2.8.x before 2.8.5, 2.9.x before 2.9.4, 2.10.x before 2.10.3, 2.11.x before 2.11.2, and 2.12.x before 2.12.3 might allow remote authenticated users to bypass the git-shell sandbox and execute arbitrary commands, after leveraging a less command-line-based command execution vulnerability.
+
+References:
+
+ - https://insinuator.net/2017/05/git-shell-bypass-by-abusing-less-cve-2017-8386/
+ - https://www.leavesongs.com/PENETRATION/git-shell-cve-2017-8386.html
+
+## Environment Setup
+
+Run the following command to start a SSH server that has a git-shell login shell:
+
+```
+docker compose up -d
+```
+
+To avoid port conflicts with the Docker host's SSH port, Vulhub sets the container's SSH port to 3322. In this directory, Vulhub has generated an `id_rsa` file, which is the SSH private key that you need to specify when connecting.
+
+Before connecting, you need to set the private key permissions to 0600: `chmod 0600 id_rsa`, otherwise the connection may fail.
+
+When normally connecting to its SSH service `ssh -p 3322 -i id_rsa git@127.0.0.1`, you will be intercepted by git-shell, returning the error `fatal: unrecognized command ''`, and the connection will be closed.
+
+## Vulnerability Reproduction
+
+Use the --help trick to connect to the target and enter the help page:
+
+```
+ssh -p 3322 -i id_rsa -t git@127.0.0.1 "git-upload-archive '--help'"
+```
+
+Press `shift`+e to read arbitrary files:
+
+![](img/03.png)
+
+Return to the help page, enter `!id` to execute commands:
+
+![](img/04.png)
+
+(Why is it the www-data user? Because the git user and www-data user both have ID 33, so they are actually the same user)
+
+## Principle
+
+### Git Pull Process Based on SSH Protocol
+
+git-shell is an important component of git services. As we know, git services support three protocols for project transmission: SSH, git, and HTTPS, among which SSH is the most secure and convenient.
+
+If we open any project on Github and find the address listed in `Clone with SSH`: git@github.com:phith0n/vulhub.git, this URL actually tells git that the SSH username is git, the address is github.com (default port is 22), and the project is located in the `phith0n/vulhub.git` directory; then git connects to github.com via SSH protocol and pulls the project from the corresponding directory.
+
+Therefore, git clone and other operations based on SSH protocol are essentially processes of connecting to the git server via SSH protocol and pulling from the specified directory.
+
+So, since this is an SSH interactive process, can I directly execute `ssh git@github.com` to log in to the github server? Obviously not, you can try:
+
+![](img/01.png)
+
+Saying "not possible" is actually not entirely accurate. I did connect to its SSH service and pass authentication, but it gave me a prompt message "Hi phith0n! You've successfully authenticated, but GitHub does not provide shell access." and then closed my connection.
+
+Therefore, normally, the git pull process based on SSH is secure for the git server.
+
+For information on how to set up a git server, you can refer to [this article](http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/00137583770360579bc4b458f044ce7afed3df579123eca000)
+
+### How to Prevent Git Users from Executing System Shell
+
+So, how do git service providers like GitHub implement the above "secure" communication process?
+
+There are two ways to allow users to authenticate via SSH but not give them a shell:
+
+1. Set the shell to git-shell when creating the system user git
+2. Set command in the authorized_keys file before each ssh-key to override or hijack the original command
+
+The first method is more straightforward - when creating the user, instead of giving them a normal bash or sh shell, give them a git-shell. git-shell is a sandbox environment where only commands included in the sandbox can be executed.
+
+The second method is not only used on git servers but also in many Linux distributions. For example, AWS by default does not allow root login, implemented by setting `command="echo 'Please login as the user \"ec2-user\" rather than the user \"root\".';echo;sleep 10"` in /root/.ssh/authorized_keys. This effectively overrides the original shell execution with an echo command.
+
+Of course, git-shell can also be used within the second method. For example, when adding a git user, give them a normal `/bin/bash` but set `command="git-shell -c \"$SSH_ORIGINAL_COMMAND\""` in authorized_keys, which still effectively uses git-shell.
+
+### git-shell Sandbox Bypass Vulnerability (CVE-2017-8386)
+
+git-shell is a shell that can restrict user command execution. If we create a new directory called `git-shell-commands` in the git user's home directory and put the commands you allow users to execute in this directory, we've created a sandbox. In git-shell, only commands in the `/home/git/git-shell-commands` directory can be executed.
+
+If the system doesn't have a `git-shell-commands` directory, then git-shell by default only allows the execution of these three commands:
+
+- `git-receive-pack <argument>`
+- `git-upload-pack <argument>`
+- `git-upload-archive <argument>`
+
+This is the whitelist.
+
+However, the author of CVE-2017-8386 discovered that executing `git-upload-archive --help` (or `git-receive-pack --help`) will enter an interactive man page, which calls the less command, resulting in a help document that can be scrolled up and down.
+
+This seems harmless, but the less command has a feature that supports some interactive methods. For example, in the less page, pressing `shift`+e opens the Examine function, through which arbitrary files can be read; entering `!id` can execute the id command.
+
+You can try this on any Linux computer - execute `less /etc/passwd` to get to the less page, then in English input mode, type `!id`, and you can execute the id command:
+
+![](img/02.png)
+
+So, using this feature, we can bypass the git-shell sandbox to read arbitrary files or execute arbitrary commands!
+
+We can first try executing `git-receive-pack --help` directly in Linux, then enter `!id`, and we'll see similar effects to the above image.
+
+[evi1cg's blog](https://evi1cg.me/archives/CVE-2017-8386.html) has animated GIFs that make this more intuitive.
+
+### Exploitation via SSH
+
+So, how do we exploit this vulnerability remotely?
+
+We tried earlier that directly using `ssh git@gitserver` only gets us git-shell (or returns a reminder message), so we'll use the sandbox bypass vulnerability mentioned in the previous section to execute commands:
+
+```
+ssh -p 3322 -i id_rsa -t git@127.0.0.1 "git-upload-archive '--help'"
+```
+
+Enter the help page, then press shift+e or enter `!id`.
+
+### Some Limitations
+
+As mentioned earlier, there are two ways to configure git users to prevent SSH shell access: one is to set their shell to `/usr/bin/git-shell` when creating the user, and the other is to override the command in authorized_keys.
+
+If the target server uses the first method, even if we successfully execute `git-upload-archive '--help'` and enter the help page, we still can't execute commands. This is because `!id` is still executed under git-shell, and since git-shell doesn't have the id command, it still won't succeed.
+
+However, reading files is always possible because file reading is not done through commands, so it's not affected by the git-shell sandbox.
+
+If the target server configures git-shell using the second method, like in this test environment where I set the git user's shell to bash in the `/etc/passwd` file but override the command in authorized_keys to execute git-shell.
+
+In this case, if we enter the help page and input `!id`, we can successfully execute the id command because it's executed under bash rather than git-shell, so there are no sandbox restrictions.
+
+In summary, this vulnerability can at least achieve arbitrary file reading, and potentially arbitrary command execution.

git/CVE-2017-8386/README.zh-cn.md

@@ -0,0 +1,127 @@
+# GIT-SHELL 沙盒绕过导致命令执行漏洞（CVE-2017-8386）
+
+Git shell是一个用于SSH账户的登录shell，提供受限的Git访问。在git 2.4.12、2.5.6、2.6.7、2.7.5、2.8.5、2.9.4、2.10.3、2.11.2、2.12.3版本之前，可能允许远程认证用户绕过git-shell沙盒执行任意命令。
+
+参考链接：
+
+ - https://insinuator.net/2017/05/git-shell-bypass-by-abusing-less-cve-2017-8386/
+ - https://www.leavesongs.com/PENETRATION/git-shell-cve-2017-8386.html
+
+## 环境搭建
+
+编译及运行测试环境：
+
+```
+docker compose up -d
+```
+
+为了不和docker母机的ssh端口冲突，我将容器的ssh端口设置成3322。本目录下我生成了一个`id_rsa`，这是ssh的私钥，连接的时候请指定之。
+
+在连接以前，需要先设置私钥的权限为0600：`chmod 0600 id_rsa`，否则连接可能失败。
+
+正常连接其ssh服务`ssh -p 3322 -i id_rsa git@127.0.0.1`，会被git-shell给拦截，返回错误`fatal: unrecognized command ''`，并且连接被关闭。
+
+## 漏洞复现
+
+使用--help技巧，连接目标并进入帮助页面：
+
+```
+ssh -p 3322 -i id_rsa -t git@127.0.0.1 "git-upload-archive '--help'"
+```
+
+按`shift`+e，读取任意文件：
+
+![](img/03.png)
+
+回到帮助页面，输入`!id`执行命令：
+
+![](img/04.png)
+
+(为什么是www-data用户？因为git用户和www-data用户编号都是33，所以其实他们是一个用户)
+
+## 原理
+
+### 基于ssh协议的git拉取流程
+
+git-shell是git服务中重要的组成部分，众所周知，git服务支持ssh、git、https三种协议来传递项目，其中ssh是最安全，也最方便的一种方式。
+
+我们随便打开Github上一个项目，找到`Clone with SSH`里列出的地址：git@github.com:phith0n/vulhub.git，其实这个url就是告诉git，ssh用户名是git，地址是github.com（默认端口是22），该项目位于`phith0n/vulhub.git`这个目录下；然后git就通过ssh协议连接上github.com，并将对应目录下的项目拉取下来。
+
+所以，基于ssh协议的git clone等操作，本质上就是通过ssh协议连接上git服务器，并将指定目录拉取下来的过程。
+
+那么，既然这个过程是个ssh交互的过程，那么我直接执行`ssh git@github.com`是不是就可以登录github服务器了呢？显然是不行的，你可以试试：
+
+![](img/01.png)
+
+说"不行"其实也有偏差，实际上我确实是连接上了其ssh服务，并验证身份通过了，但他给了我一段提示信息"Hi phith0n! You've successfully authenticated, but GitHub does not provide shell access."，就把我的连接关了。
+
+所以，正常来说，基于ssh的git拉取过程对于git服务器是安全的。
+
+关于如何搭建一个git服务器，可以参考[这篇文章](http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/00137583770360579bc4b458f044ce7afed3df579123eca000)
+
+### 如何禁止git用户执行系统shell
+
+那么，github这类git服务商是怎么实现上述"安全"通信的流程的呢？
+
+让用户可以通过ssh认证身份，但又不给用户shell，这个过程有两种方法实现：
+
+1. 创建系统用户git的时候将其shell设置成git-shell
+2. 在authorized_keys文件每个ssh-key的前面设置command，覆盖或劫持重写原本的命令
+
+第一种方法比较直观，就是创建用户的时候不给其正常的bash或sh的shell，而是给它一个git-shell。git-shell是一个沙盒环境，在git-shell下，只允许执行沙盒内包含的命令。
+
+第二种方法不仅在git服务器上使用，很多Linux发行版也会用到。比如aws，默认安装后是不允许root登录的，实现方法就是在/root/.ssh/authorized_keys中设置`command="echo 'Please login as the user \"ec2-user\" rather than the user \"root\".';echo;sleep 10"`。这句话相当于覆盖了原本执行的shell，变成了echo一段文字。
+
+当然，第二种方法内也可以用git-shell，比如在添加git用户的时候赋予其正常的`/bin/bash`，但在authorized_keys中设置`command="git-shell -c \"$SSH_ORIGINAL_COMMAND\""`，实际上还是使用了git-shell。
+
+### git-shell 沙盒绕过漏洞（CVE-2017-8386）
+
+git-shell是一个可以限制用户执行命令的shell，如果我们在git用户家目录下创建一个新目录，叫`git-shell-commands`，然后将你允许用户执行的命令放在这个目录下，这就创建好了一个沙盒。在git-shell中，只能执行`/home/git/git-shell-commands`目录下的命令。
+
+如果系统是没有`git-shell-commands`目录，那么git-shell默认只允许执行如下三个命令：
+
+- `git-receive-pack <argument>`
+- `git-upload-pack <argument>`
+- `git-upload-archive <argument>`
+
+这就是白名单。
+
+但CVE-2017-8386的作者发现，执行`git-upload-archive --help`（或`git-receive-pack --help`），将会进入一个交互式的man页面，man又调用了less命令，最后是一个可以上下翻页的帮助文档。
+
+本来这也没什么，但是，less命令有一个特性，就是其支持一些交互式的方法。比如在less页面中，按`shift`+e可以打开Examine功能，通过这个功能可以读取任意文件；输入`!id`就可以执行id这个命令。
+
+可以随便找台linux计算机试一下，执行`less /etc/passwd`来到less的页面，然后在英文输入法下输入`!id`，就可以执行id命令：
+
+![](img/02.png)
+
+所以，利用这个特性，我们就可以绕过git-shell的沙盒读取任意文件，或执行任意命令了！
+
+我们可以先试试，在Linux下直接执行`git-receive-pack --help`，再输入`!id`，看到的效果和上图是类似的。
+
+[evi1cg大佬的博客](https://evi1cg.me/archives/CVE-2017-8386.html)中有动图，看的更直观。
+
+### 通过ssh进行利用
+
+那么，如何远程利用这个漏洞？
+
+我们前面试了，直接`ssh git@gitserver`只能拿到git-shell（或返回一段提醒文字），我们就利用上一节里提到的沙盒绕过漏洞执行命令：
+
+```
+ssh -p 3322 -i id_rsa -t git@127.0.0.1 "git-upload-archive '--help'"
+```
+
+进入帮助页面，然后按shift+e或`!id`即可。
+
+### 一些限制
+
+我前文说了，一般配置git用户，不让ssh拥有shell，有两种方法：一是创建用户的时候设置其shell为`/usr/bin/git-shell`，二是在authorized_keys中覆盖command。
+
+如果目标服务器使用了第一种方法，我们即使成功执行了`git-upload-archive '--help'`进入帮助页面，也不能执行命令。因为`!id`还是在git-shell下执行，git-shell中没有id命令，所以依旧执行不成功。
+
+但读取文件是一定可以的，因为读取文件不是通过命令读取的，所以不受git-shell沙盒的影响。
+
+如果目标服务器是用第二种方法配置的git-shell，比如我这里这个测试环境，我是在`/etc/passwd`文件设置git用户的shell是bash，而在authorized_keys中覆盖command，执行git-shell。
+
+这种情况下，如果我进入了帮助页面，输入`!id`是可以成功执行id命令的，因为此时id是在bash下执行的，而不是在git-shell下执行的，所以没有沙盒限制。
+
+总的来说，这个漏洞至少能做到任意文件读取，有可能可以执行任意命令。

git/CVE-2017-8386/docker-compose.yml

@@ -0,0 +1,5 @@
+services:
+ git:
+   image: vulhub/git:2.12.2-with-openssh
+   ports:
+    - "3322:22"

git/CVE-2017-8386/id_rsa

@@ -0,0 +1,27 @@
+-----BEGIN RSA PRIVATE KEY-----
+MIIEogIBAAKCAQEAsf0lBQtId6OH7p9otwIPzpiR3mUqfOc2MLilmj83CsvH1L/0
+eXK7DwU8OoW1abqE7iEFYY3cxg897HldBXAN3nqkCk4sq/HgPho4a2hnR3WuMgbV
+LI2AxT89DoT/tYdumq9yJs49BYjMtKo7pBhdID+Y+xHXabmemARZZ7raUfn6sebT
+3Sn5WURQ+fdCCRhRzt96M45J8UuqSGgboosUOB/qF/8SzGRjL8qgHk1gy2rPSReK
+S5VGdX0FMn8gDZrOjshQp8yAG4kA3pBQ0RDPLRDPHyxWF6zt07ftNXV8S4YQErnz
+dH4yPnsAngv0ibgasQQxtTOxYAefwSBzd8+mmwIDAQABAoIBAHUAbHpxXVTQGgZB
+oetTnqJ3ZsQkCpcKwnOqnanUzlD5fkYbXREM22xXS61IweVbqBCFgm0LfUpxMIqn
+iP+PFn7ebcEcfH8XRApu4BGzEtlFwZm/Jhjgd/qxxGgsA5AIFCv5EvfxcOmXcMF+
+ejA3l9ggFmdM5ibozxktGrx2dxeVO8VQPpFRoZIXqk6G0RNrAjCYG0NSqLfSkf2n
+J8m3JYhvUxfDy1TI2btTXVPz1B28M+3YQD4JraVioYkOGIfflWjlfjctW6HAGdhU
+Kf0DMHvcRd+tLsUOOapoY22saw2XZb+aebc07jUilW3posgRJC7M/IDHkjXNKyDP
+laOhgskCgYEA5kQDo+1WIbNU7FQ0AF6dOrj65GruRujXQzTbB6Pi64wWM9bAxcc3
+C+rR033vX7/nrBRFTWTeve1DO/1t1Ozen86OciOma7QgRERfA7v8Ck31BevJJr/t
+y5a0QfpQkrBP1iUrI2Ew3XJtcLSQr9JPo0O95UFZtcVlLkXX/SLjO2cCgYEAxeF4
+jzZU51r1tRrj+6uV6PtLHsfe7z+OTmQIXDrk8O4KM7bIWgfI4iJErzpfav4j4/ZT
+NwK8w0JrgXAo8LjT00jDQqVVQz2PI2O7PNpXKk/oGHKNvzdX41Xb1rFOwPwWHLKj
+gIEHVaDsz5Gi3R7H20+szq9tskqvResyLQtMLq0CgYBdgHjJ8/HptVxiqr6C9+h4
+k+ytHA6tlJb0n13heFcIttW9LxMQPJjJqgySCK1PACoe4gxSJQedr96BWaNjttuf
+oMyO5JMLYRVJI0pBxe/Ob2Fzig8gQQdaiFOiBvb42cdReb5Om4SwJ2rxPSEThB76
+eON/WE4JVaKEa7ANBkGnOQKBgGovc+Jl5WnBBdkJdQ24Jdm//6+k0ZzRHiwywcm8
+UN543kCh9SFazBGNEg515H4lolzR8hWzAlhFbCspZM7IX+MhSKaa0gYjIox7GB6v
+i9bIymNUFXxm1mLH0BCFVR16KON9eP+cPbNVh75bCGpf+h9VwgWnXdYu/Z8nduV1
+CoyBAoGAZfnpQCwL77cITg+J1N09nE3KQV+H8qfy4yTHxb/TOCCeCf676w3aQT80
+IrlLa+fQL54shqlqAonSV85PCN2XdnpaOcHR8TcK0Uln8jqhlUaA13fW93Yzy5Cw
+Om6aW16UqUrFL5TVgFHQvc4WSphPZyboClavgNshfTfS4i00iqE=
+-----END RSA PRIVATE KEY-----

git/CVE-2017-8386/id_rsa.pub

@@ -0,0 +1 @@
+ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCx/SUFC0h3o4fun2i3Ag/OmJHeZSp85zYwuKWaPzcKy8fUv/R5crsPBTw6hbVpuoTuIQVhjdzGDz3seV0FcA3eeqQKTiyr8eA+GjhraGdHda4yBtUsjYDFPz0OhP+1h26ar3Imzj0FiMy0qjukGF0gP5j7EddpuZ6YBFlnutpR+fqx5tPdKflZRFD590IJGFHO33ozjknxS6pIaBuiixQ4H+oX/xLMZGMvyqAeTWDLas9JF4pLlUZ1fQUyfyANms6OyFCnzIAbiQDekFDREM8tEM8fLFYXrO3Tt+01dXxLhhASufN0fjI+ewCeC/SJuBqxBDG1M7FgB5/BIHN3z6ab test@vulhub