Securing my modx site

It would indeed be useful to know what virus you had. I may have been some sort of worm that spead on your server, infected files with 777 permissions, and then crossed over to your clients’ computers. Or it may have been a virus that your clients had on their local PCs that spread through the manager to their website. Without more info it’s impossible to know. Was this a Windows server?

Quote from: niemi at Mar 29, 2007, 09:29 AM

So, sottwell what can you make of that piece of information?

That one is not one I am familiar with. But then I’m no server expert, just thought it might be easy to tell from that.

So, how do I get on securing my site?

As a start, can ANYONE tell something about how to apply that patch? (Think this might be the fifth time I ask in this thread )

Quote from: niemi at Mar 30, 2007, 04:54 PM

So, how do I get on securing my site?

As a start, can ANYONE tell something about how to apply that patch? (Think this might be the fifth time I ask in this thread )

If you are asking for applying suPHP and PHPSuexec, you need to ask your host for it, if they provide it, well and good other wise search for another host.

I’m not asking for that. That’s already good. This is what I’m asking for:

MODx also currently has hardcoded permissions set 666 or 777 to files that are uploaded through the file managers. To make the suite for suPHP and PHPSuexec, you need to do the following edits (patch file against rev 1630 can be downloaded [here]):

From the article I linked to previously.

Quote from: niemi at Mar 30, 2007, 05:42 PM

I’m not asking for that. That’s already good. This is what I’m asking for:

MODx also currently has hardcoded permissions set 666 or 777 to files that are uploaded through the file managers. To make the suite for suPHP and PHPSuexec, you need to do the following edits (patch file against rev 1630 can be downloaded [here]):

From the article I linked to previously.

Based on this info that you gave earlier:
Quote from: niemi at Mar 25, 2007, 02:55 PM

Server API = Apache 2.0 Handler

I don’t think that you have suExec enabled.

My understanding of how suExec works is that it runs PHP as a CGI executable. This info appears to indicate that your PHP is running as an Apache service. Which is fine and good (and is how most people run it), but it is not suExec.

So you do indeed need to talk to your host in order to clear this up if you really want to run suExec.

Then if you are running a recent version of MODx (0.9.5+), you can now set these permissions in the File Manager configuration screen. The patch that you linked to is ancient history, so no you don’t need to do that. We are now somewhere around rev 2300, and I believe that patch was for rev 1630...

To follow up from my last message...

I am afraid I don’t have much to tell as my client’s corporate tech support person (whom he claims to be the best in the city) has convinced him of the evils of hidden malicious code in opensource. An example of this attitude’s prevailing effect is that any attempt from me to investigate the problem is returned by my client’s answer of ’who is responsible?’ and ’who will pay?’. So maybe you can appreciate my lack of answers.

Had I been in my office at the time I would have downloaded the corrupted cache, virus scanned it, and then taken a look at it’s modification. Come to think of it, I wish I had thought to ’view page source’; but I didn’t and the evidence is now gone.

What I can tell you is that the site is extremely small. It was literally just a contact page set as the index with links to two downloadable pdf’s stored in assets/files. The pdf’s have not been altered.

All directories were set per 0.9.5 instructions (i.e. cache 0777).

The website is hosted by IXWebHosting and is running PHP Version 4.4.6 & mysql 4.1.20 on Apache Release 10331100.

I’ve set ’php_flag register_globals Off’ in the .htaccess file (in home directory) as the IXWebhosting is globally set to On. On a side note, I just found that the home .htaccess file was missing. It is (and was) present in /manager. I am surprised by this as I had configured the home .htaccess file during the site’s install in order to clear the ModX ’Global Registers Set to On’ warning.

Other:
I asked my client if he could have brought the virus with him on a usb drive and he said no (take that for what it is worth). He does have virus protection on both infected computers (home and work)... though I can’t find out what the software is. Neither my computer (through IE or Firefox) nor IXWebhosting system was infected when we viewed the site and manager (nor did I get any virus/trojan warnings).

My conclusions:
1. I can not confirm if a virus was transmitted through my site or if it was coincidence.
2. The site’s cache and .htaccess were modified. It would appear to have been malicious due to the calls to bigmam.com.
3. I am lacking a lot of information.

I am sorry not to have provided more info. Are the any ideas on how to better secure the cache without the services of PHPSuexec or suPHP?
-Rich

Quote from: refriend at Apr 01, 2007, 10:23 AM

To follow up from my last message...

I am afraid I don’t have much to tell as my client’s corporate tech support person (whom he claims to be the best in the city) has convinced him of the evils of hidden malicious code in opensource. An example of this attitude’s prevailing effect is that any attempt from me to investigate the problem is returned by my client’s answer of ’who is responsible?’ and ’who will pay?’. So maybe you can appreciate my lack of answers.

ROFLMAO; I needed a great laugh to start the day and make me spit coffee all over myself. I love how we "hide" code in source that is completely available to the public; i.e. open source. DOH!

Quote from: refriend at Apr 01, 2007, 10:23 AM

All directories were set per 0.9.5 instructions (i.e. cache 0777).

Ummm, where are these instructions and who should be shot for telling you to set all MODx dirs to 0777??? Permissions completely depend on the environment you are running in. I for instance run some sites with dirs to 0700 and files to 0600, others with 755 and 644, and even others with 775 and 664. It depends on file and group ownership, what user is executing the PHP process, etc. But I can tell you that using 0777 and 0666 across the board on a MODx site is not correct and should never be done...that would make those dirs and files writable by any user on that machine. If it’s a shared Linux host, you can see the obvious problem with that.

Quote from: refriend at Apr 01, 2007, 10:23 AM

The website is hosted by IXWebHosting and is running PHP Version 4.4.6 & mysql 4.1.20 on Apache Release 10331100.

I’ve set ’php_flag register_globals Off’ in the .htaccess file (in home directory) as the IXWebhosting is globally set to On. On a side note, I just found that the home .htaccess file was missing. It is (and was) present in /manager. I am surprised by this as I had configured the home .htaccess file during the site’s install in order to clear the ModX ’Global Registers Set to On’ warning.

Other:
I asked my client if he could have brought the virus with him on a usb drive and he said no (take that for what it is worth). He does have virus protection on both infected computers (home and work)... though I can’t find out what the software is. Neither my computer (through IE or Firefox) nor IXWebhosting system was infected when we viewed the site and manager (nor did I get any virus/trojan warnings).

My conclusions:
1. I can not confirm if a virus was transmitted through my site or if it was coincidence.
2. The site’s cache and .htaccess were modified. It would appear to have been malicious due to the calls to bigmam.com.
3. I am lacking a lot of information.

I am sorry not to have provided more info. Are the any ideas on how to better secure the cache without the services of PHPSuexec or suPHP?
-Rich

Yeah, definitely don’t set permissions on all directories to 777; find out what the minimum permissions you need are and use those (likely 775 dirs and 664 files), and get a host and server admin with a clue. If they can’t tell you what happened, and run the server with register_globals=On still, that’s a good warning sign indicating you should likely run away.

ROFLMAO; I needed a great laugh to start the day and make me spit coffee all over myself. I love how we "hide" code in source that is completely available to the public; i.e. open source. DOH!

I know. Where do you even start talking to a client when they lead with that kind of statement?

I did not set all folders to 0777, just, assets/cache/, assets/export/, and assets/images/ per README-en found in the modx-0.9.5 download.

4) Change the following directory permissions to 777 (read/write/execute):
assets/cache/
assets/export/
assets/images/



5) Change the following files to 666 (read/write):
assets/cache/siteCache.idx.php
assets/cache/sitePublishing.idx.php



6) Point your browser to the URL that corresponds to your upload location:
http://your-server.com/path-to-MODx-files-if-present/install/



7) If you see the red message regarding MODx not being installed, click the red "Install Now" text. Once you start the installer, follow the onscreen instructions to complete the install process. If you skipped any part of steps 2-5, you’ll be prompted to fix them during install.

NOTE: You may need to create a database prior to running the installer. In fact, it’s probably a good idea to do so. Make sure to have your DB name, DB username and DB password ready when installing MODx.



8) When the installer has completed running, for security you should take the following measures:

Delete your installation folder.
Change your permissions on your config.inc.php file back to 644 (step 3).

You can also optionally delete the README.xx.txt files located in the root of your MODx install location (which includes this fiel you’re reading).

I’d set new permissions but without suPHP ModX can’t read/write to cache without xx7 or xx6 permissions.

And this would be true whether you were using MODx or any other open source CMS, or a closed source, commercial, encrypted CMS. The scripts still need to be able to write to those folders, and there is the danger that a badly configured server will allow unauthorized access. Or perhaps an FTP password can be compromised. An amazing number of "hacks" are nothing of the sort, but simple carelessness or clever social engineering.