
Every C99.php shell is backdoored - chewxy
http://thehackerblog.com/every-c99-php-shell-is-backdoored-aka-free-shells/
======
kijin
The whole thing _is_ a backdoor. Backdoor in a backdoor? Surprise! Of course
it's backdoors all the way down ;)

But of course, script kiddies aren't particularly good at securing the servers
they pwned, are they? [1]

A couple of months ago, I wrote QADE [2] for fun, a "quick and dirty" PHP-
based text editor and webshell for editing files and running commands
remotely. I deliberately failed to implement any authentication-related
feature, because I didn't want to give an illusion of security. A secure
webshell is an oxymoron.

[1] [https://blog.avast.com/2014/06/09/are-hackers-passwords-
stro...](https://blog.avast.com/2014/06/09/are-hackers-passwords-stronger-
than-regular-passwords/)

[2] [https://github.com/kijin/qade](https://github.com/kijin/qade)

~~~
leni536
What about putting it behind https and use basic http auth? If it's only for
you you can always have a self signed certificate.

~~~
kijin
That's exactly what I do with my own installation of QADE on my dev box. The
README on GitHub recommends others to do the same, since it's pretty much the
only way to make QADE secure.

------
astrodust
Why would anyone who's not completely insane install anything like C99 in the
first place?

Not only is the idea completely nuts, but all Google produces for C99shell is
how it's used in backdoor tools.

Surprises: Zero.

~~~
scintill76
Apparently it's mostly used by script kiddies who compromise someone else's
server and install it.

~~~
danielweber
Well, I hope someone tells them their backdoor has been compromised.

------
Udo
In all my years of writing PHP code I have yet to find a legitimate use case
for extract() - PHP should have gotten rid of it generations ago.

~~~
ars
You can use it to pass a bunch of variables between functions, without having
to constantly get them from an array.

    
    
        function qux() {
          return compact('foo', 'bar', 'baz');
        }
    

And in the other function:

    
    
        extract(qux());
    

You can have one "preparer" function that works on the data and sets up the
variables, then several others that work on it, and all call the same
preparer. Or the reverse.

Obviously you can do the same thing by just passing arrays but sometimes a
simple variable is easier and less cumbersome.

~~~
kabdib
... and to think that my contempt for PHP couldn't be increased.

Wow. This is the anti-Scheme. It's like they took everything good in language
design and decided to do the exact opposite. "Let's make a function that has
the side effect of introducing variables into scope. That's a great idea."

Oh, Bog....

~~~
ars
> This is the anti-Scheme.

Since when is Scheme the arbiter of what is good or bad?

PHP lets you do this, or not do this, your choice. Like C, PHP doesn't tell
you what to do, it's up to you.

That's why people actually use it.

~~~
fleitz
Exactly, what's wrong with a double clawed hammer?

Use it or not, if you don't like it you can smash stuff with the triblade
screw driver. Or the 7 point socket wrench.

PHP provides a wealth of very useful tools that you can choose to use or not.
I don't know why people think my 7 point socket wrench is dumb, it works quite
well to round the edges of 6 sided bolts and saves a lot of money on buying
those special bolts that can't be removed once tightened.

~~~
ars
If this is the quality of the argument then I have nothing to concern myself
with.

Your post might be [slightly] humorous, but as an argument against PHP
language constructs it fails miserably.

~~~
steego
It really doesn't. Especially when you see people pulling out the double claw
hammers at your company.

Features that have limited real benefits with lots of risk get abused all the
time. They are the retarded tools of the world creating technical debt for
everybody else and they should be retired.

Extract is one of the stupidist language feature conceived precisely because
it puts something so ripe for abuse into the hands of idiots. It even has a
simple name that practically encourages its abuse.

~~~
fleitz
Yup, then you see people building sine wave roads for the square wheels they
build last week.

Or making critical parts of infrastructure work by a cron job that calls wget.

For some reason PHP needs extract, because a dictionary just won't do.

    
    
      foo["var_x"]
    
      // for some reason needs to be:
    
      $var_x

~~~
officialjunk
I think you mean catenaries, not sine waves.

------
gnyman
I have only every seen the c99.php shell used by script kiddies which utilizes
some well known php vulnerability and uploads this as the control point.

It would be cool if somebody wrote an automated script which would seek out
these c99 and try to identify those which are used on hacked sites. It could
then use this to get access and remove this script and fix the original
exploit.

Using exploits to help people is of course a can or worms but I like the idea
of good hackers helping everyone.

~~~
cmgreen
Please don't do this. Max Butler did that to DNS in 1998 with patching bind
(plus a backdoor). He went to prison 18 months. Then coming back out, he ended
up doing carding and back to prison.

[http://www.securityfocus.com/news/203](http://www.securityfocus.com/news/203)
[http://en.wikipedia.org/wiki/Max_Butler#FBI_investigation.2C...](http://en.wikipedia.org/wiki/Max_Butler#FBI_investigation.2C_guilty_plea.2C_and_sentencing)

~~~
danielweber
Fixing a broken BIND and then installing a backdoor is a much different kettle
of fish than just writing a worm that fixes the bug and then walks away.

That said, I would agree completely that it's very legally dangerous. If it's
not yours, don't mess with it!

As an academic matter, I think such a worm _could_ end up being socially
useful, _if_ there are enough compromised machines _and_ the people running
them are sufficiently incompetent _and_ those machines are being used against
other people _and_ you can be sure that your fix doesn't break something else
_and_ the machines just won't get re-compromised again next week. That's too
many conditional clauses for me, but maybe someone else feels like taking one
for the team.

Legally: again, don't do it. It's not yours.

------
dutchbrit
I'm actually disgusted to see how many people use extract in bad ways! As some
others here have mentioned, I've never found a legitamate reason to use
extract - and the php documentation clearly mentioned not to use it on input
data.

Example:
[https://github.com/search?l=PHP&p=1&q=extract%28%24_GET%29%3...](https://github.com/search?l=PHP&p=1&q=extract%28%24_GET%29%3B&ref=advsearch&type=Code)

Yuck...

------
barbs
Cached version:

[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://thehackerblog.com/every-c99-php-
shell-is-backdoored-aka-free-shells/)

------
norswap
Got confused for a minute. Why the hell call your shell after a C language
standard? Also, the term "shell" is terribly overloaded nowadays.

------
leigh_t
> due to a vulnerability in the extract() command

No.

This is due to insane usage of the extract() function. Not a vulnerability
with the function itself.

You can pass user-supplied input directly to plenty of other functions which
have equally idiotic outcomes, it doesn't mean that they have vulnerabilities,
it means the author is a liability.

~~~
mandatory
Right, didn't mean that in the original post - obviously this is how the
function is designed to work. Fixed up the wording to clarify.

------
cstrat
After reading these comments I am intrigued. Whenever I have used PHP I pretty
much always run extract three times:

    
    
        extract($_GET, EXTR_PREFIX_ALL|EXTR_REFS, 'gVar');
        extract($_POST, EXTR_PREFIX_ALL|EXTR_REFS, 'pVar');
        extract($_COOKIE, EXTR_PREFIX_ALL|EXTR_REFS, 'cVar');
    

It makes working with get/post/cookies much easier. All variables are
extracted with a prefix... so:

[http://www.yyy.com/script.php?hello=world](http://www.yyy.com/script.php?hello=world)
Results with: $gVar_hello being the variables holding 'world'.

Is this poor form?

I previously used: `import_request_variables` - but thats been sidelined.

~~~
TimWolla
Why is using $gVar_hello easier than $_GET['hello']? Also $_GET and friends
have the benefit of being super global.

~~~
cstrat
It is easier to use in strings, `$blah = "hi $gVar_hello"` rather than $blah =
"hi {$_GET['hello']}";`.

Not that it is a massive deal... I guess I just got in the habit when I was
younger. Like I said, I always used import_request_variables (with various
prefixes).

\----

But back to my question - is it bad to use like I have?

~~~
ohwp
First: this could result in:

    
    
      echo $blah; // hi <script>alert('foo');</script>
    

But maybe it's just because you posted an example...

Second: it will double the memory used.

Third: you can't use the variables global anymore

~~~
cstrat
Like you said, I wouldn't use it without first cleaning the input. I guess I
use it more out of habit and preferring a straight variable to an array...
just feels neater.

Good point on the memory, but I wouldn't think thats a big issue. I haven't
tested right now, but I dont remember ever having issues using the $_GET
variable after exporting? Not sure if thats what you meant.

~~~
innocenat
If I am not mistaken, PHP is copy-on-write, so if extract just copy value then
memory usage wouldn't be doubling.

------
drivingmenuts
A tool that's pretty much only useful for hacking is backdoored? Heaven
forbid!

How is this even news?

------
pogue
I think the trouble is now, if this was just released, is that you can easily
google for c99.php and find vulnerable servers with this file hosted on it,
from pre-existing backdoors/phishing hosts, or what have you, and this allows
anyone and everyone to use it, not just the original person who placed the
backdoor. Which, I suppose, kind of enhances the problem exponentially.

As far as I'm concerned though, Google and Firefox's malware checker engines
should blacklist any domain that has the c99.php file located on it and block
their webbrowsers from connecting to it in the first place.

Of course - correct me if I'm wrong here.

~~~
drunkcatsdgaf
actually, google is pretty far ahead of this. trying searching
allinurl:c99.php, most of the returns are actually about the script.

------
jacquesm
this is pretty bad:

[https://www.google.com/search?client=ubuntu&channel=fs&q=all...](https://www.google.com/search?client=ubuntu&channel=fs&q=allinurl%3Ac99.php&ie=utf-8&oe=utf-8)

------
mmaunder
The only reason you have C99 on your server is because you've already been
hacked. Its' one of the oldest shells used for backdooring a hacked site - you
rarely see it anymore because there are much better shells now.

------
nnnnni
So... what's the best way to tell if C99 is "installed" on your server(s)?

    
    
        grep -Ri c99 /path/to/htdocs 
    

would be my guess

~~~
mkarr
There are thousands of variations of C99 used by various 'hackers'. Many of
which are obfuscated (base64, gzip, other more obscure encodings). Generally,
searching for a combination of 'base64_decode', 'gzdecode', and 'eval' will
find a great deal of them. Others may require more manual inspection. Just
searching for 'eval' alone tends to find a lot.

There are a few tools floating about that try to use a more signature-based
approach to searching, and clamav has some signatures for the shells, but they
can be hit-and-miss, as the obfuscation often changes.

------
laurent123456
Is the C99.php shell any popular? This is such a classic exploit of
`extract()` that it seems like very amateurish job. If they even use this
function at all I imagine the rest of the script is not that secure either.

------
whalesalad
I just deployed a lot of these for fun on Heroku. Really interesting stuff.
[http://php-c99.herokuapp.com/](http://php-c99.herokuapp.com/)

------
Jach
I thought everyone knew this already ~10 years ago...

------
fanssex
Is this a joke?

------
nodesocket
Founder of [https://commando.io](https://commando.io). It is utterly
frightening that anybody would consider using c99. If you're interested in a
parallel SSH web-based interface, check us out. Commando.io does not provide
an interactive shell, but instead operates through pre-defined scripts we
called recipes (written in shell, bash, perl, python, ruby, go, or node.js).
Recipes are fully versioned, and we keep a full audit trail of all executions
run on your infrastructure.

~~~
mahouse
Are you recommending us to use your software on servers that we compromise?

~~~
nodesocket
Absolutely not, recommending Commando.io for anybody looking for a web-based
SSH interface for servers they rightfully manage.

~~~
gamed
;)

