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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[+] [-] kijin|11 years ago|reply
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|11 years ago|reply
[+] [-] astrodust|11 years ago|reply
Not only is the idea completely nuts, but all Google produces for C99shell is how it's used in backdoor tools.
Surprises: Zero.
[+] [-] scintill76|11 years ago|reply
[+] [-] aaron695|11 years ago|reply
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.
[+] [-] lucastx|11 years ago|reply
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.
[+] [-] rplnt|11 years ago|reply
There are always reasons, sometimes valid reasons, to do insane things.
[+] [-] Udo|11 years ago|reply
[+] [-] adamors|11 years ago|reply
[+] [-] kijin|11 years ago|reply
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.
[+] [-] ars|11 years ago|reply
Obviously you can do the same thing by just passing arrays but sometimes a simple variable is easier and less cumbersome.
[+] [-] yeahbutbut|11 years ago|reply
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,...}.
[+] [-] thefreeman|11 years ago|reply
[+] [-] zapt02|11 years ago|reply
[+] [-] p4bl0|11 years ago|reply
The security problem lies in the fact that the authentication code is conditionally called depending on user input.
is not less safe than would have been.[+] [-] mtdewcmu|11 years ago|reply
[+] [-] Spoom|11 years ago|reply
[+] [-] dikei|11 years ago|reply
[+] [-] gnyman|11 years ago|reply
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|11 years ago|reply
http://www.securityfocus.com/news/203 http://en.wikipedia.org/wiki/Max_Butler#FBI_investigation.2C...
[+] [-] tomkwok|11 years ago|reply
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
[+] [-] dutchbrit|11 years ago|reply
Example: https://github.com/search?l=PHP&p=1&q=extract%28%24_GET%29%3...
Yuck...
[+] [-] barbs|11 years ago|reply
http://webcache.googleusercontent.com/search?q=cache:http://...
[+] [-] norswap|11 years ago|reply
[+] [-] leigh_t|11 years ago|reply
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|11 years ago|reply
[+] [-] cstrat|11 years ago|reply
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|11 years ago|reply
[+] [-] brokentone|11 years ago|reply
[+] [-] drivingmenuts|11 years ago|reply
How is this even news?
[+] [-] pogue|11 years ago|reply
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|11 years ago|reply
[+] [-] jacquesm|11 years ago|reply
https://www.google.com/search?client=ubuntu&channel=fs&q=all...
[+] [-] mmaunder|11 years ago|reply
[+] [-] nnnnni|11 years ago|reply
[+] [-] mkarr|11 years ago|reply
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|11 years ago|reply
[+] [-] whalesalad|11 years ago|reply
[+] [-] Jach|11 years ago|reply
[+] [-] fanssex|11 years ago|reply
[+] [-] nodesocket|11 years ago|reply
[+] [-] meowface|11 years ago|reply
[+] [-] mahouse|11 years ago|reply
[+] [-] fl0wenol|11 years ago|reply