

Open Source Backdoor – Copyrighted Under GNU GPL - cubictwo
http://blog.sucuri.net/2013/08/open-source-backdoor-copyrighted-under-gnu-gpl.html

======
smsm42
This article has quite a serious error:

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

~~~
ipax
Yes, you're correct.. Too much C in my mind :) We are going to correct the
post. Have a good one!

~~~
fein
You're also missing "<?php" as the opening php tag. Seems the "?" was removed.

------
TheYComb
The presence of an "eval" makes it pretty obvious that there was something
going on.

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?

~~~
ipax
As I mentioned in the article the code was inserted into a good core file from
Joomla as part of a malicious attack. Thanks for the comment.

~~~
dave1010uk
This was found on a deployed instance, rather than in the main Joomla source
repository or download? The article doesn't make this clear.

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

~~~
eksith
I think this is what you're talking about :

[https://groups.google.com/forum/#!topic/apache2/dmM19cYS0oA](https://groups.google.com/forum/#!topic/apache2/dmM19cYS0oA)

------
jeffasinger
The only actually clever thing is that they put it in a file named
copyright.php.

I'm wondering where this backdoored version of Joomla came from.

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

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

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

[https://github.com/joomla/joomla-cms](https://github.com/joomla/joomla-cms)

------
metafour
Why is the copyright notice in a scripting file instead of something almost
guaranteed to be statically served? Or was that part of the attack?

------
eksith
Yet another reason _eval_ is evil and should be in disable_functions :
[http://php.net/manual/en/ini.core.php#ini.disable-
functions](http://php.net/manual/en/ini.core.php#ini.disable-functions)

Better yet, if you're on a nix box, you should be using [http://www.hardened-
php.net/suhosin/](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.

~~~
meowface
Believe it or not, this code would be just as bad even if the `eval` call was
removed entirely. See:

[http://www.reddit.com/r/netsec/comments/1k1875/open_source_b...](http://www.reddit.com/r/netsec/comments/1k1875/open_source_backdoor_copyrighted_under_gnu_gpl/cbkjgzj)

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

~~~
eksith
Wow! That's just... nuts!

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](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).

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

------
samspenc
Is this a real trojan found in the wild, or something they came up with to
show how sneaky trojans could be?

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

~~~
mrhazel
The most interesting shells I've seen have been done via the htaccess file.

Here is an example:
[https://github.com/wireghoul/htshells/blob/master/shell/mod_...](https://github.com/wireghoul/htshells/blob/master/shell/mod_php.shell.htaccess)

~~~
matiasb
Nice .htaccess thing

------
zhemao
Why did they even make this a PHP file? Why not just HTML or plain text?

~~~
zhemao
Oh wait. Okay, I guess the attackers created the file as well.

~~~
chrisfarms
Hmmm... dunno but looks like they really might have had copyright info in a
"restricted" executable file.... for literally no reason:

[http://docs.huihoo.com/api/joomla/1.5/ric_COPYRIGHT.php.html](http://docs.huihoo.com/api/joomla/1.5/ric_COPYRIGHT.php.html)

~~~
zhemao
Well that's just dumb.

------
ivanbrussik
considering there are still hundreds of thousands of Joomla sites running 1.5
or lower this is very scary.

------
matiasb
the $gnu lol

