“Bash” (CVE-2014-6271) vulnerability – Q&A

What is the “bash” vulnerability?

The “bash” vulnerability, actually described as CVE-2014-6271, is an extremely powerful vulnerability due to its high impact and the ease with which it can be exploited. An attacker can simply execute system level commands, with the same privileges as the affected services.

In most of the examples on the Internet right now, attackers are remotely attacking web servers hosting CGI scripts that have been written in bash.

At the time of writing, the vulnerability has already been used for malicious intentions – infecting vulnerable web servers with malware, and also in hacker attacks. Our researchers are constantly gathering new samples and indications of infections based on this vulnerability; and more information about this malware will be published soon.

The key thing to understand is that the vulnerability is not bound to a specific service, for example Apache or nginx. Rather, the vulnerability lies in the bash shell interpreter and allows an attacker to append system level commands to the bash environment variables.

How does it work?

I will use the same examples that we have seen in the advisories and proof-of-concept code that have been published,to explain how it works. When you have a CGI script on a web server, this script automatically reads certain environment variables, for example your IP address, your browser version, and information about the local system.

But just imagine that you could not only pass this normal system information to the CGI script, but could also tell the script to execute system level commands. This would mean that – without having any credentials to the webserver – as soon as you access the CGI script it would read your environment variables; and if these environment variables contain the exploit string, the script would also execute the command that you have specified.

What makes it unique?

This vulnerability is unique, because it’s extremely easy to exploit and the impact is incredible severe – not least because of the amount of vulnerable targets. This does not just affect web servers, it affects any software which uses the bash interpreter and reads data which you can control.

Researchers are also trying to figure out if other interpreters, such as PHP, JSP, Python or Perl, are also affected.  Ddepending on how code is written, sometimes an interpreter actually uses bash to execute certain functions; and if this is the case, it might be that other interpreters could also be used to exploit the CVE-2014-6271 vulnerability.

The impact is incredibly high because there are a lot of embedded devices that use CGI scripts – for example routers, home appliances and wireless access points.  They are also vulnerable and, in many cases, difficult to patch.

How widespread is it?

This is very difficult to say, but we know from our intelligence systems that people started to develop exploits and worms directly after the vulnerability information was published – both whitehat and blackhat researchers are scanning the Internet for vulnerable servers.

It is too early to know how widespread this is, but I know from my own research that there are a great many web servers running CGI scripts, and I am pretty sure that we will also see a lot of other types of exploits being developed that target local files and network daemons. There have been discussions regarding both OpenSSH and dhcp-clients being vulnerable to this attack as well.

How do I check if my system/web site has been affected?

The easiest way to check if your system is vulnerable is to open a bash-shell on your system and execute the following command:

If the shell returns the string “vulnerable”, you should update your system.

Also there are tools for the technical audience out there that can be used to verify if your server is affected by this vulnerability.

Advice on how to fix this problem

The first thing that you need to do is to update your bash version.  Different Linux distributions are offering patches for this vulnerability; and although not all patches have been proven to be really effective yet, patching is the first thing to do.

If you are using any IDS/IPS I would also recommend that you add/load a signature for this.  Alot of public rules have been published.

Also review your webserver configuration.  If there are any CGI scripts that you are not using, consider disabling them

Is there threat to online banking?

This vulnerability is being actively exploited to target servers hosted on the Internet. Even some workstations running Linux and OSX are vulnerable, but an attacker would still need to find an attack vector that will work remotely against your desktop.

The vulnerability is not targeting individuals, but servers hosted on the Internet.  This means that if, for example, your favorite e-commerce or banking website were vulnerable, the attackers could, in theory, compromise that server and gain access to your personal information, including maybe banking information.

At the time of writing its very difficult to say exactly what platforms might be vulnerable and might have been targeted, but I would recommend that you do not actively use your credit card or share a lot of sensitive information for the next couple of days, until security researchers have been able to find out more information about this situation.

Can I detect if someone has exploited this against me?

We would recommend reviewing your HTTP logs and check if there is anything suspicious. An example of a malicious pattern:

There are also some patches for bash that log every command that is being passed to the bash interpreter. This is a good way to see if someone has exploited your machine. It won’t prevent someone from exploiting this vulnerability, but it will log the attackers actions on the system.

How serious is the threat?

This bug is very dangerous indeed, but not EVERY system is vulnerable. Special conditions must be met, for example, for a web server to be exploited. One of the biggest problems now is that when patches are published, researchers look for other ways to exploit bash, explore different conditions that allow it to be exploited, etc. So a patch that helps to prevent remote code execution can’t do anything against, for example, a file overwrite. So there will probably be a series of patches and in the meantime systems are still vulnerable.

Is it new Heartbleed?

Well, it’s much easier for a cybercriminal to exploit than Heartbleed. Also, in the case of Heartbleed, a cybercriminal could only steal data from memory, hoping to find something interesting.  By contrast, the bash vulnerability makes full system control much more possible. So it would seem to be more dangerous.

Can it be used in future APTs?

It could be used for future malware development, of course. Malware could be used to automatically test infrastructure for such a bug, to infect the system or attack it in some other way.