Just a heads up to anyone out there.

I recently lost both my sites from a hack on my hosts server.
skeeterspub.com
skpdev.net

According to my host this was done through a file on several different websites that have the permissoin setting of 777. My arcade site was one of them.

How do we prevent 777 directories from being comprimised?

My host is looking into ways to try and prevent this from happening in the future.

Here is the last email I received from my host.
----------------------------------------
Setting up the site again will be like it was new... .. in fact we can put it on the newest server (you would have to change your domains DNS/nameservers), which is a dual core 3.0 with 2 gigs of ram.

5 - 11total users (Us and the NOC are still verifying the count), created the issue by means of folders with 777 permissions. Seems a new risk is out there that both hosts control panels are going to have to address soon! Basically in a nutshell 777 permissions give anyone access to the folder to upload..... etc .. anything they want. And.. certain files can sneak their way in the root of a server as this happened in this instance.

I'll paste a small snippet of info at the bottom of my reply... if you want on the new server let me know.. otherwise I will setup the account again on the 148 server so you can begin uploading. Let me know either way please.

As received from the NOC techs:
It seems the server is hacked. The file formats at /var/cpanel/users are suspicious. Also rkhunter results say that there are 4 md5 checksum errors. We must perform an OS reload, please let us know feasible time for OS reload.

--------------------------------------------------

I am saddened that skpdev will be down for a while. I will have to start from scratch. Also my arcade site skeeterspub.com.

Not even sure if I will be able to get all user info back.


To all my users on my sites. Sorry for any inconveinience and hope to have things squared away as soon as possible.

What? That is bad news scetter. Sorry that you'll have to go through the headace in re-setting up the site again.

One question thou. Didn't you back up your sites?

Once you re-builded it, I'm pretty sure that your users will re-registered again. I will.

I was doing backups But the last one I did I can't find and I suspect my Son deleted the file when he was on the comp last.

Little terd!

Ohhhhh! That's hurt. *OUCH* That is why I kept all my data on a different hard drive than the OS. And gave limited access to my daugther. She know not to delete stuffs off the computer anyway. Good luck man!

Maybe you can use Data Recovery program to get it back.

So what happen was: trought someone else script within some else webs space someone was able to get into the db deleting the whole database. Correct?

Or a script from someonelse web space was able to jump to each other web space deleting each user database?

I think the second case, but this could be a server security issue, also chown your cache you:apache and then chmod 755 to make your webspace safer since they dont even know that its a server related issue.

A script shuold not be able to run trought users home.
First your public_html must have restricted access, my current setup use a 710 I bet your server had at least a 711 and all other "world writable" are 755 instead of 777, just playng with apache setup and correct chmod, chown and umask security could be incremented in the whole server.

Anyways is the hole in a Dragonfly script or someone else script?

move to server chat?

NanoCaiordo wrote:

So what happen was: trought someone else script within some else webs space someone was able to get into the db deleting the whole database. Correct? Or a script from someonelse web space was able to jump to each other web space deleting each user database? I think the second case, but this could be a server security issue, also chown your cache you:apache and then chmod 755 to make your webspace safer since they dont even know that its a server related issue. A script shuold not be able to run trought users home. First your public_html must have restricted access, my current setup use a 710 I bet your server had at least a 711 and all other "world writable" are 755 instead of 777, just playng with apache setup and correct chmod, chown and umask security could be incremented in the whole server. Anyways is the hole in a Dragonfly script or someone else script? move to server chat?

As far as I know it was done by someone uploading a file to a directory that was chmod 777.
Once uploaded the hacker was able to run the script and get into the bottom of the site and into cpanel files and mess with DNS info which in turn caused sql problems as well as doing things to the hard drive.

Yes this person was able to jump to multiple sites that had directories of 777 and do the same thing.

I don't think it was a whole in DF itself but a folder in the structure that is 777. They never said it was df. they said it was the permissions.

This criminal did damage though because as one of the rules in the NOC is, any sites that where hacked get deleted to stop any further problems. So it is all gone.

This is the last info that I received.
---------------------------------------------
Some stuff you cannot prevent and our NOC is coming up with some 'new rules' for their dedicated server clients. As for what you can do......... truly the absolute best thing is to make sure NO folder you have (except maybe the www folder in the root of your account and we are working on changing this), has 777 permissions.... no file or folder should have this because it is an open doorway for a semi clever hacker.

777 permissions means it's global and anyone can upload and execute files or folders. Now.. the BIGGEST problem with this is some scripts, especially ones in cpanel and fantastico that automatically install the scripts... have settings that are 777. So, as you can see this isn't an easy or 'quick work around'.. which is why some are going to continue with problems on server ... because we are going to experiment there 1st.

There will be a mass mailing about this once we have fuller details... it's not going to be soon because it's still a study of trial and error at this point. I can say ONLY php sites are the problems and create the issues.... I am not saying cgi or perl sites/scripts are 100% secure... but they are a LOT safer to use and keep alive securely.

Just remember this ......... no site in the world is ever fully secure... no server, no isp, no business... no bank.. nothing. If a good hack wants in..........they'll get in. Even symantec (Norton various PC securities and programs), was hacked..... that's truly saying something!
-----------------------------------------------------

I just really wanted everyone to know the risks of having those folder permissions set. Appearently it is something new.

They have placed me on a new server with all up to date stuff but It will still be a while before I am back up on both my sites.

It's regrettable that you have lost everything like that but it appears your host is the root cause of the issue. There should never be a need to set the root level to 777 and better hosts actually preclude this. DragonflyCMS does not need 777 on correctly configured hosts.

cgi/perl can be an extremely risky area - we don't recommend running cgi on your Dragonfly site due to its insecurity.

There are ways to drop the permission off 022 using umask (777-022=755)

scetter wrote:

cpanel and fantastico that automatically install the scripts... have settings that are 777

Phoenix wrote:

correctly configured hosts

NanoCaiordo wrote:

There are ways to drop the permission off 022 using umask (777-022=755) scetter wrote: cpanel and fantastico that automatically install the scripts... have settings that are 777 Phoenix wrote: correctly configured hosts

Yes I beleve that it was them at fault even though they say it started at a folder above the root. Possible but not really.

At any rate they are working on fixing this issue. Not sure why they didn't stay on top of security issues till now. This is the first problem I have had and I have been with them for about four years.

Well have lots of work to do.
Hopfully be back soon with more security.