Open Source Backdoor – Copyrighted Under GNU GPL(blog.sucuri.net)
blog.sucuri.net
Open Source Backdoor – Copyrighted Under GNU GPL
http://blog.sucuri.net/2013/08/open-source-backdoor-copyrighted-under-gnu-gpl.html
34 comments
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?
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?
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.
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.
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.
This was found on a deployed instance, rather than in the main Joomla source repository or download? The article doesn't make this clear.
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 found it hard to believe that such stupid backdoors exist, and even worse, get used successfully.
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
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.
I'm wondering where this backdoored version of Joomla came from.
>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 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.
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.
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.
https://github.com/joomla/joomla-cms
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
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?
Yet another reason eval is evil and should be in 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/ There are some potential hiccups with off-the-shelf software, but some minor inconvenience is a better alternative than having your system compromised.
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.
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...
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).
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).
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
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).
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.
Regardless, PHP in general was never designed for security of any sort.
Note that there's no suhosin for PHP5.4, and therefore it no longer appears in the Wheezy repositories.
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.
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.
Is this a real trojan found in the wild, or something they came up with to show how sneaky trojans could be?
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.
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.
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_...
Here is an example: https://github.com/wireghoul/htshells/blob/master/shell/mod_...
Nice .htaccess thing
Perhaps I can't read, but it seems the article is really lacking with a source for where this was found.
It was found in the wild.
Why did they even make this a PHP file? Why not just HTML or plain text?
Oh wait. Okay, I guess the attackers created the file as well.
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
Well that's just dumb.
considering there are still hundreds of thousands of Joomla sites running 1.5 or lower this is very scary.
the $gnu lol
>>> 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).