>>> 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 fact that $_REQUEST was used is a huge red flag as well.
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.
Similarly basic PHP backdoors are floating around right now. If you look over your WordPress install for a file named "7c334.php" or "7c34.php" you might find one. Or you could google for it.
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.
Well - I'd go a bit further. Use of $gnu combined with the function name and location is also fairly clever in that a casual glance will just appear to be some gnu/gpl-related code in the copyright file -- not at all out of place.
It won't pass any real scrutiny, but it does help it to slip under the radar if someone isn't paying close attention.
I see so many security problems like this that would be caught so easily if there was just a process with super basic statistical analysis capabilities watching the logs. A POST to the Copyright.php file? I'm guessing that would never be found in your logs before the bad file was deployed. Something that watches the log and determines if the entry is very different from the usual contents of the log (pick up the book 'Programming Collective Intelligence', there are a dozen different techniques you could use for this, and even the simplest should work very well) and alerts you.
And yeah, if you ever see "eval" in any code anywhere, the hair on the back of your neck should stand up.
The fact that Copyright.php is a PHP executable sets off red flags to me before I would even open up the file. Thankfully it doesn't seem like Joomla ships with any files stupidly coerced into being executable. Copyright.php was added to this installation.
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'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).
To be fair, it's probably not a security vulnerability in most cases, because it's rare that serious code does the equivalent of `$func = $_GET['func']; $func($_GET['userinput']);`, but it certainly makes for nice backdooring.
Regardless, PHP in general was never designed for security of any sort.
Yes, this is a concern. I believe the latest version with the patch is 5.3.21 which is included with OpenBSD. But some of the features in Suhosin were merged into mainline PHP. It would be interesting to see a side-by-side of 5.4 and Suhoshin patched features.
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.
Sneaky? That's not sneaky at all. The presence of eval is a great big flashing sign saying "Backdoor here!". Why on earth does the copyright file have code in it? Sneaky is the infamous sys_wait4() backdoor in the Linux source, or using open($filename) in perl, or letting someone pass in a debugging filename that you treat as a relative path without realpath().
I've seen remote execution backdoors like this in a compromised Joomla site before (at least w/r/t the code snippet that actually does the execution), so I would not be in the least surprised if someone was clever enough to use the copyright file as a place to sneak it in.
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.
>>> 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).