Doublecheck your permissions!

Ahem...

It’s a mighty unpleasant thing when a client site’s config.inc.php file gets hacked. Unfortunately I know from personal experience. Just yesterday, I got an email from a client who had received word from an angered web user about his site trying to force a download of spyware.

Long story short- when I made the config file editable for installation- I forgot to change it back to read only for deployment. Anyway, as a result, a line of code was insterted in the config file that tried to download zango spyware. Not only that, but it broke the manager all together. Then it dawned on me that if they got the config file, they could have gotten the database user/password. If they got the database info, they could get user info... and so on.

Anyway, just a friendly reminder... (and perhaps a feature request to havea warning on the manager home page like the install directory being present). Don’t be a dofus like me!

Quote from: jaredc at Nov 29, 2005, 02:17 PM

Anyway, just a friendly reminder... (and perhaps a feature request to havea warning on the manager home page like the install directory being present). Don’t be a dofus like me!

That’s a good idea. Could you log that as a feature request? Maybe with a cool little "Click here to set as read-only" link.

On a similar note I really think we need to be on the lookout for someone to join the team who can be responsible for security. Nothing makes for better ammo against a project than even a minor security hole.

That is the big advantage to running the CGI module of PHP along with suPHP or one of its relatives. Since the script is running as the owner of the script, not as the web server, you never need to have any part of your site world-writable.

This is very strange.

How can someone use the internet to write to a file that’s set the 777? Is this a security issue in PHP, Apache or Linux?

We need to know how this can be done so we can correct the problem.

Many thanks

Ideally the file should be set to something like 400 with apache as the owner. Otherwise anyone with any access at all to your server could get your MySQL username and password.

It’s also a very good idea to give each site it’s own MySQL account with access to that site’s database only.

Different platforms run with different owners. For example, plesk runs as the psacln owner, not apache. But the same things apply.

As far as I know, if the hackers doesn’t have any access to put a file on the server, and later run it from the browser, then this shouldn’t be a problem. By having 777 permission, it means that the web user who access some script through browser able to write/execute/read the files with that permission. SO I assume that if the hackers unable to put a file/script on the server to be run on the browser, than this shouldn’t be a problem. In that case, if somebody able to change the file, because of permission 777, it means that somebody already had an access in putting a file/script to the server, which is not a problem that was caused by MODx files witht that permission. IN the first place, we need to avoid this kind of access, right?

Please correct me if I’m wrong.

Regards,
Wendy Novianto

Quote from: xwisdom at Nov 29, 2005, 10:30 PM

This is very strange.

How can someone use the internet to write to a file that’s set the 777? Is this a security issue in PHP, Apache or Linux?

We need to know how this can be done so we can correct the problem.

There is nothing we can do about it. It is an issue of the server itself, not MODx. If a file is set to 777, then anyone who can get access to that part of the system can do anything to the file, read it, write to it, delete it, whatever. If the server is very secure, it’s not likely that anyone will be able to access your part of it (without your FTP username/password). But consider, there may be two hundred or more people sharing the same server with you. If one of them is able to hack into the server to get access to more than his part, or if some outside cracker is able to break into the server, then every file you have that is "world" readable and writable is his too. If it’s only world-readable, he can still read it but not write to it. But that still lets him read it; in the case of config.inc.php that means he’s got your database info, which often enough is the same as your FTP info; this depends on your hosting company’s configuration.

The bottom line is you’re only as secure as your hosting company’s servers, and as long as you have to allow other users besides yourself read and/or write to your files you’re especially vulnerable.

Quote from: sottwell at Nov 30, 2005, 12:28 AM

...It is an issue of the server itself, not MODx.

Agreed. I put this out there not as a knock on MODx, but as a reminder to developers not to be dumb like me To that end, I think the BEST software not only has tight code and is secure, but also helps protect the user from...

...himself

Of course you could bloat your code with all sorts of idiot-proofing. (Maybe I need that.. hmm...) But where impact is high, and coding is low, it seems to make some sense.

And I’m with xwisdom... how did they do that!?!??!

I forgot to doublecheck one of my old modx websites, and voila! Hacked by some turkish dude, haha.
It didn’t take long until I realized my mistake as i scrolled the logfiles, I forgot to chmod config.inc.php back to read-only. Damnit.
To my suprise our little hacker have been merciful, as he did not erase anything.

If the hackers doesn’t have any access to put a file on the server, and later run it from the browser, then this shouldn’t be a problem

"Well, I think I have to use that nifty little Resource Browser then" thought the hacker...



I tried to repair a somewhat modified config.inc.php-file *lol* without any luck. I probaly have re-install whole modx... damn..