Re: Critical Security Measure

Quote from: Stefanie at Nov 05, 2006, 02:03 PM

On a shared webspace server I had the same problem. The hacker left a file: assets/hack.html
The server was also used as spam relay.

Here is an additional possibility to fight against these hacks by editing your .htaccess file:
__________________________________________________
RewriteEngine On

RewriteCond %{QUERY_STRING} (.*)=http(.*) [NC]
RewriteRule ^(.*) - [F]
__________________________________________________

I just tested that rule on the MODx site and it returned a 404 for the front page when used in conjunction with the existing mod-rewrite friendly URL rules.

Hi Jason,
I saw only one of my own. An other one was found by an attentive provider, that was the one used as spam relay.
Before I found Ryans solution, I changed the .htaccess files. Both servers seemed to be clear, but I’ve deleted everything, after a download to check it later on . Then I restored the backups with the changed Thumbnail.php.
On both servers where one file added: assets/hack.html
I’ve found the open door only by luck, because I looked into the appache log files only 3 hours after Ryan posted his solution. I’m looking very seldom into that log files.

Hello Ryan,

for me, the .htaccess works fine and without any problems.
Here it is complet:

# MODx supports friendly URLs via this .htaccess file. In order to use it, you must change the
# file name from ht.access to .htaccess. If you don’t want to use friendly URLs, you can comment
# the three Rewrite directives out with pound signs (like the beginning of this line).
#
# Make sure RewriteBase points to the directory where you installed MODx.
# E.g., "/" if your installation is in your root web documents directory (it comes this way by
# default) or "/MODx" if your installation is in a MODx subdirectory, per the comments below. You
# must serve web pages via Apache with mod_rewrite to be able to use this functionality.
#
# The last two blocks of rules at the bottom of this .htaccess file address anamolies with IE
# for Windows PCs and the way in which it caches images, which causes a distracting flicker in
# background images when links are hovered on the page.
#
# The output compression directives immediately below serve to speed up delivery of web pages,
# and may also be optionally commented out.

php_flag zlib.output_compression On
php_value zlib.output_compression_level 5

# Rewrite directives here for SEF (Search Engine Friendly) URLs

RewriteEngine On

RewriteCond %{QUERY_STRING} (.*)=http(.*) [NC]
RewriteRule ^(.*) - [F]


RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# If your MODx installation is in a subdirectory, change the following line to match the physical
# path to the "root" of the site as follows:
# RewriteRule ^(.*)$ /path/to/subdirectory/index.php?q=$1 [L,QSA]

RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

# This following two sections stops screen flicker in IE on rollovers (Bad IE Win, Bad!).
# Comment these sections out if you do not need them. They can result in having to force reload
# pages when developing sites and changing images frequently to see your changes.

#ExpiresActive On
#ExpiresByType image/gif A2592000
#ExpiresByType image/jpeg A2592000
#ExpiresByType image/png A2592000

#BrowserMatch "MSIE" brokenvary=1
#BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
#BrowserMatch "Opera" !brokenvary
#SetEnvIf brokenvary 1 force-no-vary

Please don’t count on that rewrite rule to stop the hacks. It’s a band-aid at best. It’s trivial to encode the URL so that the word "http" doesn’t appear in it and thus not trigger the rewrite rule.

what kind of php could make the access like thumbail.php or is for all php could be do ina assets/snippets/???.. for example, how to prevent
i read phptumb and couldent know how to make secure a script in the assets snippets for this kind of atack, because you couldent put mngvalidated because is for all users.
any pointing to this direction?

Hi,

Maybe an stupid idea but is it possible (read: logical) to password protect the whole manager directory with .htaccess/.htpasswd? Can users still visit the site when /manager is passwordprotected?

Very good catch Ryan. I’m looking at some other istances where things like this might be possible.

Will report later.

for my little understand about securyty if i have register globals ON and make a snippet or a class to this snippet whith a for example global $modx; this site become vulerable to the hackers
is this true?
is important dont use global variables into snippets or how to use?
thanks in advance

Hi,

As developer of my own CMS, I was a bit surprised to find out some asshole trying to hack my site with a exploit for a totaly different CMS. It sounds to me that they use search engines to search for "MODx". Since I have that word somewhere in a blog post. Also I would encourage to report everyone that tries to hack your site with this exploit!

Greetings,

WyriHaximus

Quote from: xyzvisual at Nov 06, 2006, 02:10 PM

for my little understand about securyty if i have register globals ON and make a snippet or a class to this snippet whith a for example global $modx; this site become vulerable to the hackers
is this true?
is important dont use global variables into snippets or how to use?
thanks in advance

It really depends. Having register_globals on alone doesn’t necessarily mean that your site is insecure right away. The problem lies in how a global variable is used. In the case of the Thumbnail.php file, a part of the script allows for a global variable to be used within a server-side include. Depending on how the server is configured and if register_globals is one, a person could inject this page with a different value for the $base_path variable. Not good!