Open Source Backdoor – Copyrighted Under GNU GPL
blog.sucuri.net
blog.sucuri.net
>>> This prototype is stating that a function called Copyright3_6_56() will be declared later on somewhere else in the code.
PHP has no function prototypes that "state that a function will be declared later". This thing just doesn't exist in PHP, unlike C. Copyright3_6_56() would be just a function call (with missing ;, so likely would cause a syntax error unless ; is found later).
The only clever thing here is putting the code after the GPL text that usually nobody reads.
Does not Joomla community code reviews the contribution to their code base?
edit: I should expand a bit: $_REQUEST is a nono, it should be $_GET or $_POST depending on the request. The actual badness of request is that it also contains everything in $_COOKIE as well.
I found it hard to believe that such stupid backdoors exist, and even worse, get used successfully.
I'm wondering where this backdoored version of Joomla came from.
It probably was inserted using another vulnerability, and put there to hide it from site owners who were only looking for files that weren't there before.
It won't pass any real scrutiny, but it does help it to slip under the radar if someone isn't paying close attention.
And yeah, if you ever see "eval" in any code anywhere, the hair on the back of your neck should stand up.
This attack is very similar to the one that keeps me up at night knowing a logfile (or worse, an entire directory because of a terrible tutorial) is chmod'ed to 777. ACLs in *nix work, use them.
Better yet, if you're on a nix box, you should be using http://www.hardened-php.net/suhosin/ There are some potential hiccups with off-the-shelf software, but some minor inconvenience is a better alternative than having your system compromised.
I'd still advise people writing new applications to go with PHP 5.4 first if only because development is made simpler, therefore it's less likely to include accidental vulnerabilities while trying to (re)implement new features available by default in 5.4.
http://www.reddit.com/r/netsec/comments/1k1875/open_source_b...
I'm not sure if Suhosin also prevents implicit evals of that nature; it very well may. And if it doesn't, this code could effectively be neutralized if only harmless functions could be called (though it'd be hard to guarantee such a thing).
I had no idea that PHP had such a completely insecure inclusion vulnerability. I'm not sure if Suhosin protects against these, but the feature list does mention limits on request variables : http://www.hardened-php.net/suhosin/a_feature_list.html
As always, yes, it's very difficult to guarantee only harmless functions are called. One of the simplest ways would be to prevent execution of code in the web root directory. Usually, we put the code files outside www and disable file uploads (separate instance for that which will exclusively handle PUT requests).
Regardless, PHP in general was never designed for security of any sort.
I saw one attacker drop the same backdoor php file in a dozen different locations, in hopes that the site owner would just remove the one in particular that was showing up in their logs and none of the others.
Here is an example: https://github.com/wireghoul/htshells/blob/master/shell/mod_...
http://docs.huihoo.com/api/joomla/1.5/ric_COPYRIGHT.php.html