Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

#SHELLSHOCK (another heartbleed, sorta, but not really :P )

Looking for a bit more than customer support, and want to learn more about what cryptostorm is , what we've been announcing lately, and how the cryptostorm network makes the magic? This is a great place to start, so make yourself at home!
User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

#SHELLSHOCK (another heartbleed, sorta, but not really :P )

Postby cryptostorm_team » Thu Sep 25, 2014 7:12 am

First off, we're patched on all servers.

Second, here's the deets via http://www.theregister.co.uk/2014/09/24 ... hell_vuln/


SHELL SHOCK: Bash bug blows holes in Unix, Linux, OS X systems


CGI scripts to DHCP clients affected – patch Heartbleed-grade injection vuln NOW
By John Leyden, 24 Sep 2014


A newly discovered vulnerability in the Bash command interpreter poses a critical security risk to Unix and Linux systems – and, thanks to their ubiquity, the internet in general.

It lands countless websites, servers, PCs, OS X Macs, various home routers, and more, in danger of hijacking by hackers.

The vulnerability is present in Bash through version 4.3, and was discovered by Stephane Chazelas. It puts Apache web servers, in particular, at risk of compromise via CGI scripts that use or invoke Bash in any way – including any child processes spawned by the scripts. OpenSSH and some DHCP clients are also affected on machines that use Bash.

Ubuntu and other Debian-derived systems using Dash may not be at risk – Dash isn't vulnerable, but Bash may still be present. Essentially, check the shell interpreter you're using, and any Bash packages you have installed, and patch if necessary.

"Holy cow. There are a lot of .mil and .gov sites that are going to get owned," security expert Kenn White said on Wednesday in reaction to the disclosed flaw.

The bug lies in Bash's handling of environment variables: when assigning a function to a variable, trailing code in the function definition will be executed, leaving the door wide open for code-injection attacks. The vulnerability is exploitable remotely if code can be smuggled into environment variables sent over the network – and it's surprisingly easy to do so.

According to the NIST vulnerability database, which rates the flaw 10 out of 10 in terms of severity:
GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.

Authentication: Not required to exploit

Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service


An advisory from Akamai explains the problem in more depth, as does this OSS-Sec mailing list post.

Proof-of-concept code for exploiting Bash-using CGI scripts to run code with the same privileges as the web server is already floating around the web. A simple Wget fetch can trigger the bug on a vulnerable system.

wget -U "() { test;};/usr/bin/touch /tmp/VULNERABLE" myserver/cgi-bin/test


You can check if you're vulnerable by running the following line in your default shell, which on many systems will be Bash. If you see the words "busted", then you're at risk. If not, then either your Bash is fixed or your shell is using another interpreter.

env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"


Jim Reavis, chief exec of the Cloud Security Alliance, claims the hole is comparable in seriousness to the infamous password-leaking Heartbleed bug in the OpenSSL library that was uncovered earlier this year.

"A large number of programs on Linux and other UNIX systems use Bash to setup environmental variables which are then used while executing other programs," Reavis explained in a blog post.

"Examples of this include web servers running CGI scripts and even email clients and web clients that pass files to external programs for display such as a video file or a sound file.

"In short this vulnerability allows attackers to cause arbitrary command execution, remotely, for example by setting headers in a web request, or by setting weird MIME types."

Robert Graham of Errata Security, who suggested the name Shell Shock for the Bash flaw, also said the programming cock-up is as severe as Heartbleed. But he noted: "There's little need to rush and fix this bug. Your primary servers are probably not vulnerable to this bug.

"However, everything else probably is. Scan your network for things like Telnet, FTP, and old versions of Apache (masscan is extremely useful for this). Anything that responds is probably an old device needing a bash patch. And, since most of them can't be patched, you are likely screwed.

"A lot of wireless routers shell out to ping and traceroute – these are all likely vulnerable."

The vulnerability (CVE-2014-6271) affects Apple's OS X – and is useful for privilege escalation – as well as major flavors of Linux. Fortunately, patches are already available, and distros are ahead of the game in responding to the flap. BSD distros that do not use Bash are safe, obviously. Apple users will need to get their hands dirty until Cupertino issues a fix.

Red Hat security engineer Huzaifa Sidhpurwala has a rundown of the at-risk software, here. ®
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

parityboy
Site Admin
Posts: 1233
Joined: Wed Feb 05, 2014 3:47 am

Re: #SHELLSHOCK (another heartbleed, sorta, but not really :

Postby parityboy » Fri Sep 26, 2014 1:24 am

@OP

Thank you for posting this. :D My servers are heavily firewalled and don't run web servers, so I have a bit of leeway. :)

User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

Re: #SHELLSHOCK (another heartbleed, sorta, but not really :

Postby cryptostorm_team » Fri Sep 26, 2014 5:37 am

There seems a bit of hyperbole about this "worse than heartbleed" exploit - to be clear, it's a really bad one - but we have some fairly experienced people on staff who point out that the chances that people will widely do really stupid stuff with CGI/Bash, etc. are not super-likely. It's sort of just not a "found everywhere" thing. We wouldn't call it rare, as by spending a few minutes with Google we found truly vulnerable servers, but just not "every linux box" as the press is implying.

We do wonder about all those older home routers, NAS's, etc. There will be a new, ugly front opening on people's home networks as they turn into litecoin miners, etc. because frankly updating those is a pain the ass. People who read this may be tech enough to patch, but the general public? Your mom? Nope. Those'll be forever stuck in time, pre-shellshock.
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

vpnDarknet
Posts: 128
Joined: Thu Feb 27, 2014 2:42 pm
Contact:

Re: #SHELLSHOCK (another heartbleed, sorta, but not really :

Postby vpnDarknet » Fri Sep 26, 2014 2:29 pm

I'd be stoked if my Mum was using a machine vulnerable to this exploit ;)
Buy your tokens via vpnDark.net and cryptostorm cannot and does not know anything about users - no link between a token & purchase details
Unofficial Wiki cryptostorm access guide
Ways to talk to me

User avatar

parityboy
Site Admin
Posts: 1233
Joined: Wed Feb 05, 2014 3:47 am

Re: #SHELLSHOCK (another heartbleed, sorta, but not really :

Postby parityboy » Fri Sep 26, 2014 11:48 pm

@OP

I agree with you on the home router thing, because those units don't have a lot of resources, so they sort of have to run native code to get the performance, hence the use of CGI. However, which server administrator even permits CGI on a server these days? I think even eBay have moved away from CGI; their systems used to be infested with it in the early days with that NSAPI.dll thing.

User avatar

df
Site Admin
Posts: 370
Joined: Thu Jan 01, 1970 5:00 am

Re: #SHELLSHOCK (another heartbleed, sorta, but not really :

Postby df » Tue Sep 30, 2014 11:49 pm

CGI is still fairly popular these days, even on major sites. What most of them do (including some of my websites) is use rewrites to hide the .cgi (or .pl) extension from the URL. They often do the same for .php/.asp/.aspx/etc. I don't have a problem with letting people know I'm using CGI, it's just that to me having somesite.com/submit looks more professional than somesite.com/cgi-bin/submit.cgi

What this vulnerability mainly exploits is CGI scripts written in bash, which is pretty rare these days. It's true that scripts in other languages can be vulnerable if the user is allowed to modify the environment variables, and those variables are then forwarded to an external program that's executed through system() or any of the other Perl/PHP/Python functions used to call external programs (provided the default shell is bash, which is common).

But as I've said before, no sane programmer should be doing that, especially without validating the input. An example of input validation would be if the CGI is expecting input that's only numbers, then the CGI script should have code that spits out an error if anything but numbers is in that data (or force all non-numbers to be removed from that data). The golden rule of CGI and really any script/program that receives user supplied data is to validate all data that comes from the user. That doesn't just mean the submittable data in HTML forms, but also the cookies, the user-agent, the referrer, all the other headers, etc. If it comes from the user, always assume it's filled with all kinds of special characters and null-bytes that are trying to execute commands or perform XSS.

Someone else mentioned that OpenVPN is also vulnerable to "Shell Shock", which is true under certain configurations. If the server-side config uses "auth-user-pass-verify" to call an external script to verify the supplied username/password (via a mysql backend for example), then it could be exploited if that external script was written in bash (and of course, the server hasn't been patched yet).

Just to clarify, we are patched, and not with that first patch that half-worked. We installed the one Redhat released that fixes this vulnerability and the 6 or so other related vulnerabilities. Also, even though we're patched, a mod_security rule was added that'll set off our IDS if you try the "Shell Shock" exploit against any of the websites on this server.

On a side note, some worms are already scanning for default cPanel CGIs, but I've manually checked all the public-facing/unprotected ones and didn't see any that looked vulnerable. The majority of those CGIs are precompiled ELF binaries that aren't executing any external programs, and the few that do are doing input validation to make sure those ENV variables don't contain any invalid characters. The other ones are written in Perl and don't appear to be executing anything external. However, I did not check the CGIs that cPanel uses once a user is authenticated. My guess is there probably are a few of those vulnerable to this.

Your best bet is to patch your servers, even if there's no context in which this vulnerability can be exploited. Seems easier than forgetting about an attack vector and getting rooted and having to deal with that headache. :D


Return to “cryptostorm in-depth: announcements, how it works, what it is”

Who is online

Users browsing this forum: No registered users and 9 guests

Login