

Another ShellShock exploit in the wild - crazydoggers
https://gist.github.com/mbulat/a49d0933c48687bcf5d7

======
motoboi
This is a Perl script that connects to a IRC channel and waits for commands.

Commands can be:

portscan (scans a host for open ports)

tcpflood (try to keep 1000 TCP connections open to a host for a specified
period of time);

udpflood (send UDP packets to all ports on a host with an payload of a
specified number of 'A' characters for a specified period of time);

httpflood( send HTTP requests to a host for specified period of time [with
HTTP Keep-Alive header]);

shell (execute arbitrary commands on the host);

google (use google to find other hosts to infect [targets modules.php]);

version (returns bot version)

All commands send status back via IRC.

There are several brazilian portuguese strings and comments, although is not
clear if the author is brazilian.

Interesting stuff.

------
general_failure
Can someone explain why apache cgi use bash? You can of course setup an
environment without bash and execute your scripts. It's just an argument to
exec*() after all.

~~~
danielweber
All the modern webserver<->framework interfaces don't call bash directly, but
they may end up calling it indirectly in one of a dozen different ways.

~~~
tlrobinson
And environment variables are typically inherited by subprocesses, so if the
CGI script executes anything (that executes anything, recursively) that uses
bash (including system() if /bin/sh is bash, e.x. on OS X) this bug becomes
exploitable?

------
mhurron
Ok, let me see if I have this straight, since I'm not seeing an end of the
world situation here.

This requires a webserver to be running CGI (mod_cgi or whatever) and the get
request has to go to a valid page, correct? So in this case `GET /cgi-
bin/hello ... yada yada yada` /cgi-bin/hello has to be a valid location.

So, explain to me how this is any worse than any remote execution
vulnerability in something like PHP?

~~~
dz0ny
FYI some routers, STBs run httpd with cgi-bin. It's lot worse than some PHP
vulnerability, because PHP is not used on those devices but bash is.

~~~
mhurron
You know, this whole thing would be a lot clearer to everyone if the following
would be clearly communicated:

Are you running sshd with ForceCommand? - Get Patching (when a patch is out)

Are you running a webserver that uses 'old style' CGI (are you really sure
you're not?) - Get Patching (when a patch is out)

Are you absolutely sure neither of the above is true? Then patch bash in your
next patch cycle.

The super-hype vulnerabilities are getting is just muddying the waters when
trying to get actual information.

~~~
nitrogen
Are you certain that no process on your system ever sets an environment
variable to a user-controlled value? Get patching.

Hypothetical: some GPG library is just a wrapper around /usr/bin/gpg. Maybe
that library uses an environment variable to set a password that doesn't show
up in _ps_. Maybe that library used system() instead of execve(). That
password is now an attack vector.

See also /usr/bin/mail called by mail() functions in scripting languages,
/bin/hostname, /bin/uname, etc. If _any_ user-controlled variable is set in
the environment, those calls become potential attack vectors

~~~
mhurron
And how many of those are remotely callable? It is a local exploit without
something that makes bash directly callable remotely.

That's why mod_cgi or sshd (in one configuration) make this bad, they execute
whatever command passed by design. To do that with most everything else, you
would need a remote exploit in that program, making the bash exploit somewhat
moot in that case. Or you're not sanitizing your inputs in which case you have
another problem anyway.

Bash, on it's own, is not remotely callable.

~~~
sophacles
I haven't experimented yet, but I wouldn't be surprise if something seemingly
innocuous like nzbget is vulnerable. It shells out to various extra processing
scripts, setting a bunch of variables from the downloaded nzb file.

How about all those torrent clients? Do they safely shell out when doing
transcoding stuff? I don't know - do you?

How about the absurd rube goldberg contraption that is modern email
processing?

How about all of those scripts that crawl various web pages? Do they shell out
anything, or set environment variables? Not just the ones you wrote, but any
of the ones that are potentially being used within your organization? (it just
takes one owned box in the network to gain a foothold)

------
daviddede
That's just the start. Once people start hitting cpanel servers:

[http://blog.sucuri.net/2014/09/bash-vulnerability-shell-
shoc...](http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shock-
thousands-of-cpanel-sites-are-high-risk.html)

