9 ms·
Open Source Backdoor – Copyrighted Under GNU GPL
- jeffasinger 13y agoThe 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 13y ago>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.
- GrinningFool 13y agoWell - 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.
- TheYComb 13y agoThe 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?
- fein 13y agoThe 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.
- ipax 13y agoAs 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 13y agoThis was found on a deployed instance, rather than in the main Joomla source repository or download? The article doesn't make this clear.
- samspenc 13y agoIs this a real trojan found in the wild, or something they came up with to show how sneaky trojans could be?
- ben1040 13y agoI'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.
- ctb_mg 13y agoPerhaps I can't read, but it seems the article is really lacking with a source for where this was found.
- wbl 13y agoSneaky? 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().
- 13y ago
- otakucode 13y agoI 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 13y agoThe 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 13y agoWhy is the copyright notice in a scripting file instead of something almost guaranteed to be statically served? Or was that part of the attack?
- smsm42 13y agoThis 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).
- zhemao 13y agoWhy did they even make this a PHP file? Why not just HTML or plain text?
- zhemao 13y agoOh wait. Okay, I guess the attackers created the file as well.
- chrisfarms 13y agoHmmm... 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 13y agoWell that's just dumb.
- bediger4000 13y agoSimilarly 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 13y agoI think this is what you're talking about : https://groups.google.com/forum/#!topic/apache2/dmM19cYS0oA https://groups.google.com/forum/#!topic/apache2/dmM19cYS0oA
- ivanbrussik 13y agoconsidering there are still hundreds of thousands of Joomla sites running 1.5 or lower this is very scary.
- eksith 13y agoYet 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.
- mappu 13y agoNote that there's no suhosin for PHP5.4, and therefore it no longer appears in the Wheezy repositories.
- eksith 13y agoYes, 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.
- meowface 13y agoBelieve 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_backdoor_copyrighted_under_gnu_gpl/cbkjgzj 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).
- eksith 13y agoWow! 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).
- matiasb 13y agothe $gnu lol