Everything You NEED To Know About Shellshock Bug In BASH

Outsmart Malicious Hackers

Shellshock (CVE-2014-6271) the bug in BASH is causing havoc on the Internet this week, as far as I’m concerned it’s a bit overstated – seriously how many people are still using cgi scripts? None I hope. I do suspect though a lot of shared hosts might get owned by this as most commercial control panel software installs a /cgi-bin/ and sometimes a script by default.

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, aka “ShellShock.” NOTE: the original fix for this issue was incorrect; CVE-2014-7169 has been assigned to cover the vulnerability that is still present after the incorrect fix.

Shellshock Bug In BASH

We’ve been so focused on buffer overflows and memory stack bugs during the past decade, we’re currently getting owned by bugs from the 90s – which once again shows the need for proper code auditing on Open Source projects (and donations/budget allocations for such activities).

The other risk profile I see exposed here is devices like routers/proxy boxes and so on that use some type of trimmed down regular Linux with BASH. I’ve seen some comments from the embedded community that this shouldn’t be an issue for them as they tend to use BusyBox which is not vulnerable.

To test for the vulnerability on your *nix systems just issue the following command as any user (doesn’t have to be root):

If you see this:

It’s vulnerable, if it’s fixed or not vulnerable you should see this:

As far as the risk, I definitely don’t think it’s a 10/10 risk vulnerability, although there already 2 worms in the wild exploiting this bug to build botnets. I don’t think any reasonably well secured server will fall foul to this though, even without BASH updated it shouldn’t be an issue.

But if you do find a vulnerable system with a cgi script, it’s trival to exploit and get a reverse shell with code such as this:

I pretty much exclusitely use nginx so I don’t have the issues many will have, if you use Apache and have mod_cgi enabled – you may well be in trouble. Look out for servers with FTP/Telnet/Apache with something like Masscan and sort them out as your primary/production systems are pretty safe without any updates/changes.

Some views/updates from others:

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.

The Register

It can be exploited by attackers looking to override or bypass environment restrictions to execute shell commands, i.e. unauthorized, malicious code.

The flaw is deemed critical for many reasons. For one, the number of affected devices is huge: think about all the web servers (including Apache ones) and embedded devices (routers, etc.) running on Linux, Mac computers… The number could very well be in the hundreds of millions.

Secondly, the US-CERT and NIST gave it the maximum score (10.0) for both impact and exploitability. Exploitation of the flaw can lead to unauthorized disclosure of information, unauthorized system access and modification, and disruption of service, and the exploitation process is extremely short and simple: it takes just a few lines of code.

Helpnet Security

According to several security firms, attackers are already probing systems for the weakness, and that at least two computer worms are actively exploiting the flaw to install malware. Jamie Blasco, labs director at AlienVault, has been running a honeypot on the vulnerability since yesterday to emulate a vulnerable system.

“With the honeypot, we found several machines trying to exploit the Bash vulnerability,” Blasco said. “The majority of them are only probing to check if systems are vulnerable. On the other hand, we found two worms that are actively exploiting the vulnerability and installing a piece of malware on the system. This malware turns the systems into bots that connect to a C&C server where the attackers can send commands, and we have seen the main purpose of the bots is to perform distributed denial of service attacks.”

Krebs on Security

Today’s bash bug is as big a deal as Heartbleed. That’s for many reasons.

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. This is similar to the OpenSSL bug: OpenSSL is included in a bajillion software packages, so we were never able to fully quantify exactly how much software is vulnerable.

The second reason is that while the known systems (like your web-server) are patched, unknown systems remain unpatched. We see that with the Heartbleed bug: six months later, hundreds of thousands of systems remain vulnerable. These systems are rarely things like webservers, but are more often things like Internet-enabled cameras.

Robert Graham

If you are running Mac OS X it’s not so trivial to fix, even if you run Homebrew, updating that will only update Homebrew BASH and not system BASH which still leaves you vulnerable if you have any public web services. If you don’t run any public web services from your Mac (like most people) you don’t have much to worry about. Some reading:

How to patch Bash on OSX in wake of “shellshock”?
How to patch your vulnerable OS X to latest bash issue (for advanced users)

If you running Ubuntu on your production systems (like me) the update/patch is trivial:

If you only want to upgrade BASH and not mess with your packages then just do:

The reboot might not strictly be necessary, but honestly I prefer to be safe than sorry.

So what’s the downlow? Are a lot of huge websites going to get owned and is half the Internet going to go dark? No. Are a lot of old devices/servers/unloved pieces of equipment/shared hosting servers going to get owned and turned into members of Botnets? Yes most likely.

Is this going to effect the average consumer? No not really, does it effect the average company? Probably yes it will, but not at the core of your production systems which should be fairly immune to this vulnerability.

But it’s fairly easy to patch, so why not – if you can do it without disrupting your business too much – just patch.

We’ll have to wait a couple of weeks to see where this really goes, and see if it’s really as disruptive as Heartbleed was.

Posted in: Exploits/Vulnerabilities, Linux Hacking

, , , , , , , ,

Recent in Exploits/Vulnerabilities:
- DJI Firmware Hacking Removes Drone Flight Restrictions
- GnuPG Crypto Library libgcrypt Cracked Via Side-Channel
- NotPetya Ransomeware Wreaking Havoc

Related Posts:

Most Read in Exploits/Vulnerabilities:
- Learn to use Metasploit – Tutorials, Docs & Videos - 238,543 views
- AJAX: Is your application secure enough? - 120,734 views
- eEye Launches 0-Day Exploit Tracker - 86,321 views

5 Responses to Everything You NEED To Know About Shellshock Bug In BASH

  1. Joe September 26, 2014 at 9:42 pm #

    PHP can be installed in two different ways: (1) as an Apache module; and (2) with CGI (which involves bash). You are correct to point out that CGI installations can be trouble.

    Some systems like Joomla, which are written in PHP, are even telling their users that CGI is more secure.

    So I think this *is* a big deal.


    However, as you ALSO correctly point out, the command interpreter can be invoked even when CGI is not used:

  2. Pat Wood September 27, 2014 at 5:22 am #

    Actually, PHP can be installed three ways: apache module, CGI, and Fast CGI. When installed as Fast CGI, which is more common than CGI in production environments (you don’t spawn a process for every PHP invocation from the server), parameters aren’t passed as env variables; they’re passed over a port.

    • Darknet September 28, 2014 at 11:42 pm #

      Well if you want to get technical, there’s also PHP-FPM and both FPM and FCGI can run over a port or a unix socket.

  3. Dave cox September 27, 2014 at 8:23 am #

    I am an avid reader of your blog. Usually I just read and keep the opinions to myself but this time I think your view is just to narrow to keep my mouth shut. Webservers are the tip of the iceberg.

    OpenVPN can be exploited given the right conditions, Banks building their own ATM software often use Linux and bash. Closed Circuit systems like the ones on the freeways and above streets use bash. All of these systems now have a fairly simple attack vector. I would its really the opposite. Heartbleed softened the media up. This is not getting the coverage it should.


    • Pat Wood September 30, 2014 at 5:02 am #

      I’m in between on this. Lots of embedded devices running linux right now don’t have bash installed, but use busybox for shell. This includes nost consumer-grade routers, cables boxes, and the like. On the other hand, some commercial routers do have bash installed and are vulnerable to this attack vector, and I believe that future devices are getting more sophisticated and will include bash (our two network printing applicances, one x86 and one ARM, both include bash).

      One bit of “good” news (if you can consider any of this news good) is that Ubuntu and Debian both ship with dash symlinked to /bin/sh, not bash, so a lot of systems that have a vulnerable bash don’t actually use it for CGI, DHCP scripts, CUPS filters, and so on.

      Don’t know about the OpenVPN exploit, but the OpenSSH one requires proper login credentials before it can be triggered. It’s mostly a problem with setups where some login is restricted to a subset of commands via the ForceCommand directive — the exploit can be used to bypass this restriction and run anything by setting the LANG env variable (if the user’s shell is bash).