
ShellShock exploited in the wild: kernel exploit with CnC component - SchizoDuckie
https://gist.github.com/anonymous/929d622f3b36b00c0be1
======
crypt1d
Interesting.

I ran the "nginx" binary thru strace in a vagrant vm and got some connection
attempts to a clouldflare IP

connect(3, {sa_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("108.162.197.26")}, 16) = 0

but didn't see anything interesting being sent there... My tcpdump output
showed it connects to a http server at 89.238.150.154:5 and exchanges some
data there

sent >>> BUILD X86

recv >>> !* HTTP

recv >>>
190.93.240.15,190.93.241.15,141.101.112.16,190.93.243.15,190.93.242.15
pastebin.com /4HQ2w4AZ 80 2

recv >>> PING

sent >>> PONG

then it just goes to do ping/pong with the same server. At one point the
process forks a separate process of itself and dies...

The pastebin link leads to an uploadcash.org file named
hermoine_granger_jpg.jpg which I can assume is a payload of somekind...

~~~
samcrawford
Interesting that they're presumably hiding behind Cloudflare, does it send a
HTTP Host header?

FWIW, it doesn't appear to be a new bit of malware - the same strings match
this pastebin from March -
[http://pastebin.com/xa87Gh7q](http://pastebin.com/xa87Gh7q)

~~~
crypt1d
Yes the syntax looks familiar, I got few more responses that match the
commands from that pastebin. Seems like a general C&C setup where they just
add new exploits as they get published.

Anyhow, doesn't seem like it sends anything to Cloudflare. I think it just
checks if the IP is alive (perhaps this is how it tests connectivity to the
internet). It also checks my routing table and extracts the MAC address.

P.S as of now, the CC server at 89.238.150.154:5 is not accessible.

------
sagischwarz
Could someone explain to me if what I think this gist shows is correct?

A get request is sent to the server with additional commands added to the
content, which creates the file ./tmp/besh whose content comes from the ngix
file from [http://162.253.66.76/nginx](http://162.253.66.76/nginx). The
executable flag is set and then the file gets executed.

The next three commands show information about the downloaded nginx file
(check sums, file command info). For what reason? Is the file really an nginx
server or is it just named like this to show that nginx is exploitable? I know
that this is basically about the bash exploit, right?

Thanks

~~~
pritambaral
The file is only named nginx. The file has been downloaded from an untrested
server, 162.253.66.76, so it could be anything really.

The title/description of the gist claims it is a kernel exploit with CnC
(Command and Control) capabilities. So yeah, the file is only named nginx; it
doesn't have anything to do with the popular web server software of the same
name. Probably named that way to avoid suspicion

~~~
CyberShadow
> Probably named that way to avoid suspicion

Correct, it is usually done to conceal the process in process listings (top /
ps aux).

~~~
sagischwarz
Thank you for the clarification!

------
freakonom
You know what would be super clever?

Discovering a case where wget shells out to bash while setting some env vars
based on received headers. And then anonymously posting a supposed shellshock
payload just begging to be downloaded with wget.

~~~
antocv
> wget shells out to bash

Why oh why would this ever happen?

This hole bug is way overblown. Not every small program on the planet "shells
out to bash", and if they do, thats one seriously messed up program.

~~~
hadoukenio
I don't think it's overblown.

If you run a web server that generates its own CAPTCHA using something like
ImageMagick, or call system() to gzip something, you could possibly be
vulnerable.

Never underestimate vulnerabilities and the way people can use them, or even
combine them, to exploit systems.

~~~
antocv
> or call system() to gzip something

Are you serious, who the hell does that!?

Any half-assed language has a zip implementation, use that. Any non-boring
language has image-magick binding to that library.

This bug affects complete idiots.

~~~
seanp2k2
>This bug affects complete idiots

Consider how many people touch an enterprise system, or even a system at a
smaller shop. Consider how many people touch shared hosting servers or even
dedicated boxes.

Do /you/ trust all of them, along with all the authors of all the software
exposed to the web (or touched by something exposed to the web) on that
system?

~~~
devicenull
On shared hosting systems, you have to design the system with the assumption
that someone is always compromised. So, additional accounts getting
compromised should just be business as usual.

Seriously, if you're on shared hosting, it's almost certain that at least one
person on the server is compromised/malicious

------
pritambaral
Which kernel exploit are they using? One of the old ones or is it a zero day?

This information is, frankly, more interesting than the fact that ShellShock
is being exploited in the wild. Really, it was only a matter of time.

~~~
verroq
>is it a zero day?

The most obvious answer is no.

~~~
swartkrans
If ShellShock is currently un-patched, it is in fact a 0 day right? Just a
very public one. Should we like not be connected to the internet until this is
fixed? Are personal routers vulnerable?

~~~
SolarNet
A 0 day means we don't know of it's existence, if it's been previous mentioned
and people have failed to patch it then it isn't a 0-day anymore. The term
comes from the "zero days to fix". Since we've had time to fix this problem,
and failed to, it is no longer a 0-day. Hypothetically, third parties might
have been safe from this if they fixed it independently.

------
Maro
What does CnC mean here? (Google doesn't tell me.)

~~~
patio11
Command and control. One frequent thing that black hats do is have all the
boxes they root subscribe to e.g. an IRC channel, so that they can receive
further commands. The ratware ("software written with nefarious purposes in
mind") often comes pre-configured with options for blasting spam, hosting
content on HTTP (for SEO or exploitative purposes), doing DOSes, and executing
arbitrary commands against the local system.

One can, of course, envision numerous ways to get data in and out without it
being an IRC channel, but that is easy to implement, works across a wide
variety of target environments, and plays well with the existing ratware
ecosystem.

------
lazyant
I had this stupid idea long ago of using "security by obscurity" and rename
some commands that are typically used manually and are favorite ones of
exploits like this, for ex: curl, wget, gcc -> rename to le_curl, le_wget,
le_gcc etc, just for my use. Maybe it wasn't such a stupid idea.

~~~
jewel
On a hardened system you remove all unnecessary binaries completely. See, for
example, PCI DSS section 2.2.5.

[https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pd...](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf)

~~~
lazyant
yes, but those commands (wget, curl, gcc and a few others) are unnecessary
usually but sometimes needed once in a while, ideally you could uninstall them
and then install on demand.

------
daviddede
cPanel servers vulnerable as well:

[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)

------
passfree
In case you want to test for ShellSheck
[https://suite.websecurify.com/market/shellshock](https://suite.websecurify.com/market/shellshock)

~~~
drtse4
Or just run from terminal:

    
    
             env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
    

This should be displayed:

    
    
          bash: warning: x: ignoring function definition attempt
          bash: error importing function definition for `x'
          this is a test

~~~
passfree
This test is for public sites. The vulnerability effects web apps too in a big
way.

------
peterwwillis
Want more exploit POC? Search 'CVE-2014-6271' on pastebin, gist.github and
twitter. There's a bunch of remote shells since yesterday.

------
Svip
I am a bit confused. Why would a webserver start bash?

~~~
nikital
One example: If a server script calls system(), it actually pops up a shell to
execute the command.

~~~
antocv
Which has not been standard security practice for last 20 years - Do Not Use
System or Execve or any other stuff from your php/web-scripts. Not. Ever.

This bug only affects people who dont care about security.

~~~
hadoukenio
Serious question - how do you run utility programs to do things without
system()?

~~~
antocv
Execve, but even that is stretching it, if I write something in Python and
someone would tell me "hey use system() or subprocess" I tell them, no thanks,
I would rather not do it - then go look for python-way of doing it, if its an
image library or whatever it is that needs to be done.

Now you say, but you really really have to run this "utility" with
subprocessing or whatever. Well, then its outside of python program and
instead of relying on subprocessing Id consider exposing that utility as an
interface and writing a small protocl through which the python and utility can
exchange data. You most probably have to parse output of utility anyway,
better do it right straight away. And if you dont have to parse output of
utility - then you send a signal/request/messaging-bus to a listerner which
will do what you want - but now with cleaned environment.

~~~
UnoriginalGuy
That "solution" won't protect you from this.

All you're doing is hiding the call to system/execve behind deeper layers of
abstraction.

Plus if people actually went ahead and reproduced all of the GNU/busybox
toolchain inside of Python then everyone would be queuing up to criticise
them, particularly if they introduced more security issues (e.g. reproducing
rsync fully within a Python library).

Realistically using execve instead of system is a step forward. It is more
efficient for non-scripts and you aren't potentially picking up poisoned
environmental variables. But if you NEED to run utilities then all you can
really do is pre-parse all the parameters carefully and hope for the best.

Suggesting never using either execve or system is just highly unrealistic.
There is just too much useful code available via it and aren't nearly enough
libraries to reproduce all of that code within whatever language you're
working.

~~~
antocv
> All you're doing is hiding the call to system/execve behind deeper layers of
> abstraction.

Thats the point, layers where environment variables do not pass - since they
in that abstraction do not make sense.

> Plus if people actually went ahead and reproduced all of the GNU/busybox
> toolchain inside of Python

Basically all of gnu coreutils/busybox, is already inside python, its called
import os.

For your rsync example, python-librsync exists. C library, with python
binding/interface. No need to run a bash to use the algorithm. If you still
want to exec it, then use pythons binding to exceve system call or similar,
not to system.

I didnt suggest never to use execve and/or system, I said do not ever use
system, sometimes highly questionably use execve.

------
aortega
The scale of pwning going on is unbelievable.

------
antocv
Where is the kernel exploit in this? Whats so kernel about some script which
probably just replaces nginx with a malwared one?

