How to protect yourself against Shellshock Bash vulnerability

Bash is one of the most used shells on Unix based systems. The newly discovered “shellshock” vulnerability affects millions of systems.

The weakness abuses an internal check when Bash gets a variable declaration. By defining this variable and putting more “stuff” (commands) in it, Bash will actually execute those commands as well. Unfortunately this results in several possible ways to exploit it by attackers.

Websites

One way this vulnerability scan be exploited, is by embedding it in HTTP requests. The extra payload might be the value for a cookie. Some CGI scripts, which reference to Bash as their shell, then will be tricked in executing commands when parsing the value of the cookie. Needless to say, but from there anything is possible, from revealing the contents of files, to implementing a backdoor.

If you are hosting websites or use common products (like cPanel), we strongly suggest to look at their forums for the real impact. There is a lot of hype going on on what is vulnerable, but the best source is still your vendor.

Early Christmas

Apparently this issue was undiscovered for a long time. Only recently the issue was revealed and become quickly a very hot subject. While it is common that issues are detected soon by attackers after a patch has been released, it is less common that the issue is already exploited this quickly. Looks like it is an early Christmas for attackers..

Protecting against Shellshock

To protect yourself against Shellshock, we advice taking the following 3 steps:

1. Update your software repository and install security updates
2. Check your log files of the last days for traces
3. Audit your system with Lynis

Lynis and Shellshock

Most security vendors cover this vulnerability as big news and provide additional detection methods in their products. While that is great, companies and individuals should apply security patches already on a regular basis. The addition to a product should be better used as an additional way to check you finished your patching properly.

Perform manual update

Debian/Ubuntu based systems:

apt install --only-upgrade bash

Red Hat based systems:

yum update bash

Automatic security updates

For example Debian based systems can use the “unattended-upgrades” package to install security related updates automatically. Most other Linux versions have a similar way to split normal and security updates. This enables system administrators to automatically install security patches.

Regular audits

Lynis has already built-in tests to detect vulnerable packages. By running Lynis on a regular basis, it becomes clear that automatic security updates are a good way to stay current.

Auditing is another detection capability to make sure that these controls are working correctly.

The community edition of Lynis has the related tests to check if it can find a “package audit tool”, which then is used to find possible vulnerable packages. If you have any, they will be displayed at the end (in the report section).

Am I vulnerable?

If you want to test if you are still vulnerable after patching your system, use this code below:

env X='() { (a)=<' bash -c "echo echo testing" 2>/dev/null; [[ "$(cat echo 2> /dev/null)" == "testing" ]] && echo "vulnerable" 2> /dev/null

This code will try to set a variable X. It abuses the weakness by creating a file (echo). The script then tries to show it (cat echo). If that succeeds, it will display “vulnerable” on your screen. In that case your system is not properly patched yet.

Notes:

• To avoid warnings on screen, our example redirects errors to /dev/null
• If you found your system to be vulnerable: Update your Bash package and remove the file “echo” from your current directory. Or else it will keep saying your system is vulnerable, even after patching.
• If you get just “echo testing” on screen, your system is protected.

Last week another simple snippet showed up to test:

var='() { echo still not fully patched; }' bash -c var

If it shows the text, there is still work to do..

More information

Related CVE’s:

• CVE-2014-6271 (up to bash43)
• CVE-2014-7169 (up to bash43-025)
• CVE-2014-7186 (up to bash43-026)
• CVE-2014-7187 (up to bash43-026)
• CVE-2014-6277 (up to bash43-026)
• CVE-2014-6278 (up to bash43-026)