Re: Critical Security Measure

The file is owned by whatever user wrote it, probably your Apache user. You can get rid of it with a php script and an "unlink" command. Since that script will run as the same user, it should have no problem removing the file. You could also try deleting it from the File Manager, I believe that will allow you to remove files, and runs as the Apache user.

Hello,

Is the best thing to do here to make sure the site is 0.9.2.2 ? Is that going to stop this or are there other things that I need to be doing? I’m not too sure as there’s lots going on in this post.

Unfortunately one of our charity sites was hacked with I presume was this register_globals were not set to ON as far as I am aware.

Cheers,
Sian

Make sure you’re running 0.9.2.2 and request your host turn off register_globals. Not doing so will mean the site WILL get hacked again since they’ve clearly found it already.

You can check it in the Administration -> View system info, the third item in the Server block is a phpinfo() call that will let you see your entire PHP environment settings. After you click on View, scroll down a little to the section Configuration php core, and there is an alphabetical list of php settings. Check both the Local value and the Master value for the register_globals setting.

Thank you for the reply and tip, it looks like the isp do have them switched on. I’ll ask them to switch it off and in the mean time add the recommended patch, as below if anyone needs it -

Please immediately add the following to the top of any public install you may have running of any version of MODx, inside the opening PHP tag. This potential vulnerability only affects installations where the php.ini has register_globals set to ON. (Which is a no-no and security issue in and of itself!)

In /manager/media/browser/mcpuk/connectors/php/Commands/Thumbnail.php:

Code:
if(!isset($_SESSION[’mgrValidated’])) {
die("<b>INCLUDE_ORDERING_ERROR</b>

Please use the MODx Content Manager instead of accessing this file directly.");
}

Thanks
Sian

ADMIN NOTE: that does not fix the root of the problem at all, but offers a way to deflect the issue. Please upgrade to 0.9.2.2 or 0.9.5 RC2.

Upgrade to 0922 ... it’s a more thorough solution. That was a temporary patch.

FORTUNATELY the sites that ModX was installed on were testing sites because I had two sites defaced in 24 hours. Where’s the documentation that could have prevented this . . . nested in the forums!!!!

Here’s an excerpt from my hosting company which had the sense to monitor the email injection permitted by ModX and stop it after only a few minutes:

This script is being used by a third party to send out unsolicited email, commonly referred to as spam. Because of this we’ve had to disable this script by setting its permissions to ’200’.

It is likely that this script is being exploited by using custom injected headers. For more information about how ’header injection’ works and how it can be prevented, please visit http://securephp.damonkohler.com/index.php/Email_Injection

Please delete or secure this script as soon as possible. DO NOT under any circumstances continue to use this script without first securing it as doing so will result in your account being temporarily suspended.

The SCRIPT vulnerabilty referred to here was in ModX . . . yes even after the install was deleted.

When is ModX going to stop calling itself a "CMS" or even a "development platform" and get real!!!! You folks are obviously leading others down the path of death and destruction with your BS.


Oh yeah, and why NOT keep this topic on the run by moving it from one topic to another. That keeps the DOCUMENTATION shell game so much more interesting!

eagleshout,

I’m sorry that your sites were compromised. I’ll personally take full responsibility for including the code from an outside source without a full audit ... we didn’t author the code but by proxy of including it with our distribution we implied vetting it. Unfortunately, most of the core team does not run any servers with register_globals set to ON or hopefully we would have caught this earlier. I understand your frustration, and can assure you that it was addressed as soon as it was discovered, announced in the Important Announcements forums where only forum admins can post, fixed days before it surfaced as a Secunia Advisory, and further even back-ported other security changes from our next release into a new stable distribution 0.9.2.2.

How should we have handled it to your satisfaction? Security is of critical importance to this project and clearly we are equally as concerned as you are about notification?

If you’re referring to a separate issue, please share that with me via PM, and it will likewise be addressed.

Quote from: eagleshout at Nov 08, 2006, 08:51 PM

The SCRIPT vulnerabilty referred to here was in ModX . . . yes even after the install was deleted.

Here’s how this happens: your FTP user from which you installed MODx is different than the Apache user, under which PHP executes. Since the compromise occurred as a result of execution through Apache by a PHP script, the files were owned by the Apache user. As such, your FTP user which you likely used to connect to the server from your FTP program could not delete them, and hence they remained. You have to ssh in and sudo to root privileges (or be a member of an admin group) in order to delete them, or request assistance from your host in that regard. This has nothing to do with MODx per se, but a lot to do with basic Unix permission and security.

Sadly, some of the largest shared server providers enable register globals by default including Media Temple and 1&1.

XSS, form injection, mysql injection, unfortunately, this is the world we are now living in. Even a straight html/cgi form is open to exploits.

Not that hacking sites or servers is new, but there has certainly been a lot of attention over the last few months to XSS and various injection techniques. The reality is, all scripts and servers run the risk of being attacked, opensource and commercial scripts alike. I’ve had to update 4 scripts over the last couple months... that’s 4 out of 6 that I’m currently using... what scares me most is that the other two probably have vulnerabilities too, but either no one is saying anything or the right people haven’t discovered them yet... and hopefully the wrong people haven’t either.

Any script can be guaranteed exploit free... at least until the next exploit is found. Unfortunately, I’m guessing most exploits aren’t found until after they’ve been found and put to use but someone other than the developers. I have to admit that it is probably the greatest thing that makes me nervous about moving from static based sites to dynamic... but that is a move that is inevitable.

Should these exploits have been found earlier? Maybe... I’m not really qualified to say, and it is too easy to pass judgement. Do I think that the MODx team is going to be even more on top of code developed by the team as well as code contributed to the project? Absolutely... the ramifications otherwise can be the difference between the next great solution and just another has-been script that fell along the wayside.

Patches were created. The team listened to suggestions that a way to communicate security issues be implemented, and multiple ways were set up in a matter of hours. Personally, I commend the team for that and would have to say I thought the response time for a solution and implementing a means to handle future issues was unbeliavable.