Every C99.php shell is backdoored

http://thehackerblog.com/every-c99-php-shell-is-backdoored-aka-free-shells/

by chewxy • 12 years ago

130 91 12 years ago

gnyman• 12 years ago

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.

tomkwok• 12 years ago

> "a can or worms"

There's a typo ...

and I'm afraid "bad hackers" react even more quickly,

so I'm hoping "good hackers" can hurry ...

but watch out! Don't mess things up and cause a disaster :O

cmgreen• 12 years ago

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://en.wikipedia.org/wiki/Max_Butler#FBI_investigation.2C...

danielweber2• 12 years ago

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.

astrodust2• 12 years ago

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• 12 years ago

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

mbrzuzy• 12 years ago

This is exactly what it's used for.

danielweber2• 12 years ago

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

macNchz• 12 years ago

Indeed, in years of writing PHP I only know of C99 because I found endless copies of it squirreled away, obfuscated, appended to other files, base64 encoded, and/or masquerading as jpg files after one of our servers was compromised.

Arnor• 12 years ago

It's also useful when your PITA sys admin won't give you SSH but also hasn't taken any precautions against exec.

Of course, the better solution is to leave ASAP...

rplnt• 12 years ago

Why would anyone who's not completely insane use anything like php in the first place?

There are always reasons, sometimes valid reasons, to do insane things.

lucastx2• 12 years ago

I've used it in the past so I could run commands on a server, when the administrator only gave me FTP access.

Uploading PHP files with system() calls works too, but C99 is much easier to use.

But yes, I only came to know it when I was a stupid defacer teen. Shame on me.

astrodust2• 12 years ago

If the only tool you have is FTP then either you're an attacker with a single set of compromised credentials, or a legitimate user forced to act like one.

aaron695• 12 years ago

What should people use?

C99shell is easy to use and common.

Why is it nuts?? You're using it for quick and easy defacements and compromises.

This is a numbers game often from people with low skill levels. I see no issues here at all. If your defacements were getting quickly taken back by another crew it might be an issue, but I've seen no evidence of this happening.

Just because there's a security issue it's not the end of the world. Risk management still comes into it.

Easy to use = more defacements. Might have a hole, well is there evidence we are losing enough defacements to justify the retraining of the crew and added costs?

And more importantly, be agile. Defacements getting retaken over at unacceptable levels, just move to a different product.

barbs• 12 years ago

Cached version:

http://webcache.googleusercontent.com/search?q=cache:http://...

drivingmenuts• 12 years ago

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

How is this even news?

Udo• 12 years ago

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.

kijin3• 12 years ago

It's not terribly bad if you use it inside a function or method. Creating global variables is what causes all the issues, but then again, if you're handling global variables, you're asking for trouble anyway.

What's really bad about extract() is that the default behavior is to overwrite existing variables. This is just a recipe for disaster, no less than the infamous register_globals.

I once wrote a framework where the controller would pass variables to the view as $view->currentUser and the template would access it as $currentUser instead of the more verbose $this->currentUser. This was implemented with extract(), but I went to great lengths to make sure that the scope was clean.

PHP probably ain't gonna get rid of extract() any time soon, but at least they should change the default to EXTR_SKIP.

adamors• 12 years ago

Frameworks tend to use it, to create variables in a view that were sent from a controller. For similar usecases it also makes sense (you want a bunch of variables created from an associative array).

zapt02• 12 years ago

Wordpress shortcodes, to extract variables from an array into local scope. Works great and even lets you set default values easily.

p4bl02• 12 years ago

I agree with you, but here the problem is not the extract() call as everyone here seems to imply.

The security problem lies in the fact that the authentication code is conditionally called depending on user input.

    if ($login) { … }

is not less safe than

    if ($_POST['c99shcook']['login']) { … }

would have been.

4mnt• 12 years ago

I'm pretty sure $login can be set to true/false somewhere on top of the file as 'configuration'. Only it gets overwritten by the call to extract().

It was not meant to be user input

ars5• 12 years ago

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.

kabdib2• 12 years ago

... 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....

zimbatm• 12 years ago

The problem is when unexpected variables are overwritten. It would be better to have a mandatory list of allowed variables that can be extracted.

    $login = '1234';
    extract(array('login'=>true, 'messsage'=>'hacker'), 'message');
    var_dump($login_, $message);
    // => $login='1234', $message='hacker'

(pardon my rusty PHP)

meritt• 12 years ago

Or you could do this:

    function qux() { return [$foo, $bar, $baz]; }

    list($foo, $bar, $baz) = qux();

greyfade• 12 years ago

This smells like an antipattern. I can't imagine a reason for wanting to do this that isn't a result of some very poor architectural choices.

dikei• 12 years ago

Exactly, I'm all for getting rid of black magics such as extract() and compact().

Spoom• 12 years ago

Agreed. The sane alternative is to extract specific, expected inputs to scope once they have been filtered and escaped. Any API I've written has this sort of validation built-in.

yeahbutbut4• 12 years ago

I've found exactly two:

Ghetto templating (using a PHP file as a template). Extract an object from the database into local vars to echo in the "template".

Parsing fixed width files, zip the columns with their names, then extract in the processing function.

In both cases you know exactly which vars are being replaced. The real WTF is extract on $_{REQUEST,GET,POST,SERVER,...}.

ojilles• 12 years ago

I wouldn't use the word "exactly" (high chance?): f.ex. where did the fixed width files come from? If it's from some (external) other system you're already have an attack vector.

thefreeman2• 12 years ago

I think it is a useful construct for specifically the scenario it is mis-used in here. Overriding default values, or a kwargs polyfill

    function foo($option1=1, $option2=2, $option3=3, $option4=4) {
        //do stuff with params
    }

this is unwieldy and difficult to reason about when you see it used, especially if you are trying to use some of the initial default values. ie.

    foo(null, null, null, 10)

vs.

    function foo($options) {
        $option1 = 1;
        $option2 = 2;
        $option3 = 3;
        $option4 = 4;

        extract($options);

        //do stuff with params
    }

With this, you can just do

    foo(array('option4'=>10));

obviously its a preference thing, but I think it is a somewhat harmless use case. If there are any params which you do not want to be overriden you move them beneath the call to extract.

ceejayoz• 12 years ago

We typically handle that by having a $defaults array, then array_merge($defaults, $options) in the function.

mtdewcmu2• 12 years ago

Drupal uses it to implement templates. I always got the feeling that it's one of those language features where you want to take a deep breath before using it; sort of like when you type `rm -rf *` and haven't pressed enter yet.

derefr• 12 years ago

It makes perfect sense when PHP is actually being used as a backend-isolated, controlled-environment templating language.

Imagine this setup:

1. you have Nginx at $DOMAIN, with your well-oiled API service (with no HTML rendering logic to be found within it) mounted to /, and a PHP FCGI instance sitting on /views.

2. Nginx is configured such that /views is only accessible from localhost.

3. Your webapp on / mostly sees requests with "Accept: application/json" or some such. It responds to these directly.

4. If your webapp sees "Accept: text/html", it does the same stuff it would to render a text/json response... but then takes that response body, and sends it in an HTTP subrequest back to Nginx, to, say, /views/accounts.php.

5. PHP does this:

  extract(json_decode($_POST['response']));

...and then does whatever it does, simply and elegantly, to render your template.

6. Your webapp catches the response from Nginx, and sends it back without modification to the client.

kijin3• 12 years ago

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...

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

leni536• 12 years ago

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.

kijin3• 12 years ago

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.

pogue• 12 years ago

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• 12 years ago

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

mmaunder• 12 years ago

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.

dutchbrit• 12 years ago

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...

Yuck...

norswap• 12 years ago

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

nodesocket2• 12 years ago

Founder of 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• 12 years ago

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

nodesocket2• 12 years ago

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

meowface• 12 years ago

People are messing with you because C99 is used almost exclusively by script kiddies as a web shell into servers they compromise. Almost no one has ever used it as an actual administration shell for their own servers.

fl0wenol• 12 years ago

Or we could, you know, use SSH (and sudo if we were so inclined). I don't think anyone uses a PHP shell willingly unless they're trying to do something they shouldn't.

cstrat5• 12 years ago

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 Results with: $gVar_hello being the variables holding 'world'.

Is this poor form?

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

TimWolla• 12 years ago

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

cstrat5• 12 years ago

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?

brokentone• 12 years ago

Yes this is poor form. Prefixing, you don't have to deal with serious security issues, but this is just a step you really don't have to take--if this is part of your normal "bootstrap" you're likely doing it wrong.

jacquesm• 12 years ago

this is pretty bad:

https://www.google.com/search?client=ubuntu&channel=fs&q=all...

fanssex• 12 years ago

Is this a joke?

nnnnni• 12 years ago

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• 12 years ago

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.

leigh_t• 12 years ago

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• 12 years ago

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.

Jach• 12 years ago

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

whalesalad• 12 years ago

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

laurent123456• 12 years ago

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.

Every C99.php shell is backdoored

Related Stories