Protecting Mambo sites from hackers

[cozimek]

Hi everyone,

Mambo 4.5.1a / PHP 4.3.9 (now 4.3.10)

Unfortunately, as an early Christmas present, I noticed that one of our sites was "hacked". It seems as if the hacker (_) was able to find our site, and gain access to our configuration.php file (which was chmod 777 to allow for easy changes to the main site config). Before people start to leap at the PHP 4.3.9 upgrade need, that's been done...and yes, this was hacked before the upgrade. Regardless, the rest of this article is a good read. =)

One of the reasons we made the move from Post-Nuke to Mambo was to protect our sites from these hackers. Now I'm a little more concerned, especially with more and more clients using Mambo.

So, I ask the community for assistance in protecting all our sites.

There seems to be two ways to protect our sites:

1) "hiding" your Mambo site, so that the script kiddies that are running searches for Mambo sites don't see your Mambo install.
2) lock-down you Mambo site, so that even if someone knows you're running Mambo, they're not going to get anywhere.

So, let's see. With #1, the goal is to make it difficult to find your site as a "Mambo" site. Can anyone explain what search tools and what parameters hackers use to find Mambo sites? Here's what I think we can do:

a) comment out the Generator meta-tag for Mambo
b) comment out the copyright tag in the footer or elsewhere
c) ...please add other advice!

So, that's really not exhaustive. We should be able to, within the confines of the GPL, be able to hide our sites from being found as simple Mambo installs to thwart being put in some hacker's Google search. But really, I think the best thing to determine here is how the hackers can do a search and find our sites as Mambo sites.

Now, for #2, how can we lock-down our sites to protect them. I'm assuming that since our hacker was able to deface our configuration.php page, that means they were able to see our database password, right?

This seems like a really, really bad thing. =)

To thwart these attacks, could the following be helpful:

a) make sure NO files are chmod 777
b) make sure all files are at least chmod 400 or greater (shouldn't that lock down enough?)

I guess my biggest confusion is, the following:

1) can someone actually view the source of a PHP file that is chmod 777, or can they simply write over it? By the way, how does one write over a chmod777 file without FTP'ing to the site?

2) what's the strictest protection we can put on all our Mambo files? Would chmod 400 be alright? That seems like it would thwart anyone trying to hit our site, right?

Ok, that's a start. I think with all the recent defacements, we really need to hit this hard. Whatever it takes to protect our client's sites, our reputation, and the Mambo community, we should do.

Best,
Ryan

[_Zedd_]

a) make sure NO files are chmod 777
b) make sure all files are at least chmod 400 or greater (shouldn't that lock down enough?)

I guess my biggest confusion is, the following:

1) can someone actually view the source of a PHP file that is chmod 777, or can they simply write over it? By the way, how does one write over a chmod777 file without FTP'ing to the site?

2) what's the strictest protection we can put on all our Mambo files? Would chmod 400 be alright? That seems like it would thwart anyone trying to hit our site, right?

Mambo installes new files, components and folders by default as 777. This is hardcoded into the core files. The best way to defend is to make a daily backup of the config file, templates and SQL via a cron job.

400 will do for files but directories need to be executable. In other words -r-------- for files and dr-x------ for directories

I'm not sure about 777 through ftp however there are some toppics on this forum about hackes of other sites with phpBB and hacks of sites wihout phpBB but on the same server. This suggests hacks using the 'other' access right (3rd 7), an insider job.

[cozimek]

Hey everyone,

Thanks Zed for the comments. My only concern is that you say the best way to protect ourselves is by running backup crons. I know that some of my suggestions have got to be a start in the right direction. Can others give their suggestions as to how we can all protect our sites? Even if it's "simple fixes", like chmodding certain files to 400, I'm interested in hearing from the core dev team their ideas.

For high profile sites (which is where Mambo is heading), simply cleaning up after defacements is not enough. =)

Best,
Ryan

[tjay]

Has anyone had a 1.0.9 or 4.5.1 site defaced?
I am not aware of any that were a result of Mambo. The recent defacing had to do with phpbb sites not updated running on improperly configured servers.
The other issue was that some servers were updated to php 4.3.10 and the hosts did not upgrade Zend as instructed.

[cozimek]

Here's another question for you all. After doing some research and talking to sysadmins, they were shocked to see that we were setting anything to xx7 in our mambo install (like the configuration.php file or directories). For example, i've seen in the documentation and from others saying that you should have your configuration.php file set to 777 and your directories that need to be "writable" set to at least 707.

From the people I've talked to, they say we're crazy to be making our directories and files writeable by "anyone". This seems like a bit of a security hole here, but I'd like to hear the take on this and other security issues by the dev team (and others).

Thanks,
Ryan

[_Zedd_]

Originally Posted by cozimek

From the people I've talked to, they say we're crazy to be making our directories and files writeable by "anyone". This seems like a bit of a security hole here, but I'd like to hear the take on this and other security issues by the dev team (and others).

My ISP blocks all files with x77 access internet. It took me a while to figure out this "bug" in Mambo. Don't get me wrong, i'm thankfull to my ISP for doing this.

[walb]

Think also of usage of good passwords! Some are very obvious and easy to crack.
I came across:
id:admin psw: admin
id:admin psw: secret
id:domain psw: domain
etc.

Better have a strong password, like:
a mixture of characters (uperrcase/lowercase), numbers, use of special characters and allways 6 or more long. Avoid making words.
And change them every 2 or 3 month.
(A wish of mine would be, to block an IP adress after 3 attempts for 10 minutes. That will stop password generator scripts.)

[holdenburg]

I agree about password complexity. I am like the original poster and always looking for any gotcha's we overlook using CMS. I am starting to transition a site to Mambo and want to stay informed about any possible issues pertaining to getting any site hacked or compromised. I think we all would like to continue this thread and explore any options that were not touched upon or expand upon the suggetions given here.

TJay, it's great that we don't have any real evidence of a Mambo site not getting hacked unless it was running unsecure BB'software. What about the issue that your sharing some server with a particular hosting company that did not patch their server? Should we change our subscription and run our own server? What questions should we be asking our hosting company?

Also, given that some hosting companies are assisting Mambo users by not allowing xx7 file rights, who are they? And, what else can be done regading the header and footers while still maintaining the Mambo License?

Anyone?

Happy Holidays...!

[cozimek]

Thanks everyone for your input thusfar. I'm happy to see that there are people here who, like me, have to put our CMS through a very tough security spin cycle to make sure it's properly protected.

I think what would be appropriate now would be for posters to give us their own ways in which they are securing their Mambo installs. Through this, we can put together a great security schema for everyone to consider using to harden their install.

If we can succeed in really locking down Mambo (maybe it is already, but...), then I think we'll be able to enjoy more success as a CMS community.

Here's my first few security shots:

(1) NEVER let any file rest with permissions set at xx7. (ok, well, maybe sometimes to change the configuration of the site, but not other than that! =) )

(2) Consistently change your passwords, including:
(a) Mambo administrator login
(b) Server root/user/shared user login
(c) Database login

....and there we start! Let's see how big of a list we can put together to really harden all our sites. Then, we could consider adding this to the manual that developers receive when they dl a new install.

Best,
Ryan

[_Zedd_]

Originally Posted by walb

Better have a strong password, like:
a mixture of characters (uperrcase/lowercase), numbers, use of special characters and allways 6 or more long. Avoid making words.
And change them every 2 or 3 month.
(A wish of mine would be, to block an IP adress after 3 attempts for 10 minutes. That will stop password generator scripts.)

Simple 3 layer approach for backend access:

Layer 1: htaccess

Always use .htaccess with locked passwords

Layer 2: IP selection

Because of a lack of https, I allow backend access by administrator or super administrator only via a limited list of IP numbers. Use REMOTE_ADDR or REMOTE_HOST for this purpose and hack the administrator index.php.

If I want to change it I need to use the master codes and SSH direct on the ISP server.

Layer 3: Use complex passwords.

Question: how do we enforce this? In Windows AD it is simple through GPO but how to do it in PHP/MySQL :

Tip: dont's use phpMyAdmin or any other SQL webinterface when the site is finished. Wonder what will happen with phpBB
exploits in phpMyAdmin?
Tip: ask for friendly site hacks by the ISP or friends to check for security holes. Most ISP are helpfull to increase the security of their hosted sites. A hacker is not always your enemy!


Happy 2005!

regards

Hans

[ford]

Hi everybody!

I am soon to launch my site but reading this thread has of course got me seriously worried!

I must admit I'm also getting a little bit confused about which files to CHMOD to what.

How about a white book or something? Or could somebody please carve it in stone for a nobrainer like me? Also a small code sample of the IP restriction method for the administrator part would be nice!

Cheers

Ford

[ogdenous]

I agree, can someone make a list of what files and foldersshould be chmod to what?

Thanks.

[_Zedd_]

Originally Posted by ogdenous

I agree, can someone make a list of what files and foldersshould be chmod to what?

For better understanding of chmod, look here.

This is how I have done it:
700 Directories
600 Files

you could chmod 400 also the core php files except the template.

400 Configuration files

you need to chmod the configuration files before changing them.

regards. Hans

[swordhert]

yah the security is very important, so it would be good thet there would be the documentation on how to configurate mambo after sutup

cous i dont wana see my site hacked by scriptkidies one morning

so IMHO it would be nice if dev teem voice their opinion on security and configuration

[KernelKrash]

I'd like to add my $.02 and observations if I could...

This is aimed more for the newbies (like myself) and if someone spots an error, please feel free to correct me! I'd appreciate it.

Hosting Company:
1.) Are they running suphp (or depreciated phpsuexec)?
(ref: http://www.suphp.org/Home.html)

While suphp can be a bit of a pain sometimes, with the increasingly hostile web environment I've changed my mind about it. It lets me use 755 for directories and 644 for files, rather than 777 or 707.

2.) .htaccess and protecting backend by allowing only certain IP addr's in.
(ref: http://httpd.apache.org/docs/mod/mod_access.html)

I did have to contact my hosting provider to enable this, but they were more than willing to.

With mod_access enabled in apache and .htaccess, you can (some obvious)
a.) Add an additional password protection the the Admin backend.
b.) Restict what IP addr's can even attempt access the Admin backend.

Examples from the ref link:
A full IP address
...Example: Allow from 10.1.2.3
...An IP address of a host allowed access
A partial IP address
...Example: Allow from 10.1
...The first 1 to 3 bytes of an IP address, for subnet restriction.
A network/netmask pair
...Example: Allow from 10.1.0.0/255.255.0.0
...A network a.b.c.d, and a netmask w.x.y.z. For more fine-grained subnet restriction. (Apache 1.3 and later)
A network/nnn CIDR specification
...Example: Allow from 10.1.0.0/16
...Similar to the previous case, except the netmask consists of nnn high-order 1 bits. (Apache 1.3 and later)

example:
Deny from all
Allow from 128.83

(Hint: google for: .htaccess + restrict IP address)

Hope someone finds this info useful.

[cozimek]

Great tips everyone! Let's keep this thread going!

My thoughts regarding documentation...I'm not sure the dev team has time to deal with this. I would ask the documentation team if they have someone working on this, and if not, could someone point me in the direction of the head of the documentation team so we could have someone here start writing this up and adding it to the official documentation?

Best,
Ryan

[anc]

Originally Posted by cozimek

1) can someone actually view the source of a PHP file that is chmod 777, or can they simply write over it? By the way, how does one write over a chmod777 file without FTP'ing to the site?

It seems that no-one answered the question yet. Like cozimek I'm very interested in the answers.

Normally a php file is compiled by the webserver if it is requested by a client, so it would not be readable. But actually having the password unencrypted in the file somewhat bothers me as not being very sound. Specially if it has read access to the public world as default. To me it seems it would be relatively easy for a hacker to exploit this weak spot, but I'm not an expert.

I followed the advise of Hans to put this file on CHMOD 400 to minimize the risk (will try .htaccess later, have problems with this), but I'm still not comfortable with all the sql settings sitting there unencrypted... Mambo development should improve security by encrypting the data in configuration.php, so it's not readable anymore.

Anc

[nuanda74]

Originally Posted by cozimek

My thoughts regarding documentation...I'm not sure the dev team has time to deal with this. I would ask the documentation team if they have someone working on this, ...

I've found a great guide for securing mambo about two months ago. It's not so recent but it's really interesting and easy to read:
http://mamboforge.net/projects/mossecurity/
It's about .htaccess usage.

Bye!
Nuanda

[ford]

Yeah, come on people, keep those tips coming in!

Has anyone found a way to do a secure login on the admin side? I'd be sorry to have some one snap up my password :-(

TIA

Ford

[anc]

Originally Posted by nuanda74

I've found a great guide for securing mambo about two months ago. ... http://mamboforge.net/projects/mossecurity/
...

Thanks for the tip! Hope I can get Lycos to active mod_rewrite ...

Anc