Mysticaly wrote:

any ideas ? Now, what do i need to do to make it secure in all the other sites ?

1.
Probably your host has a chroot setup which means that PHP is executed with your UID (CGI mode) and not with the Apache UID.
This is the most secure way to prevent you from hacking the other people on the server, or even worse: you got hacked and the hacker hacks all other accounts.
Due to the server setup the crack is limited to your account.

2.
Another option could be that you can ls & mkdir in the other accounts directories, if so this it a W.T.F. (worse then failure) configuration and your host should shame himself (and i want to know who he is for blacklisting).

In case of #2 it is obvious but, in case of #1 it might result in a probable security issue with Dragonfly or one of the add-ons.

CHMOD the directory to 555 (read and execute only) and see what happens with test.php. It should give you a clue.

No, the site in question is biaworld.com
This site is hosted by Fastname.no - But don't black list them yet, I have arranged for a phone call with a technician later today to see if we can solve this.

DJ Maze wrote:

Mysticaly wrote: any ideas ? Now, what do i need to do to make it secure in all the other sites ? 1. Probably your host has a chroot setup which means that PHP is executed with your UID (CGI mode) and not with the Apache UID. This is the most secure way to prevent you from hacking the other people on the server, or even worse: you got hacked and the hacker hacks all other accounts. Due to the server setup the crack is limited to your account. 2. Another option could be that you can ls & mkdir in the other accounts directories, if so this it a W.T.F. (worse then failure) configuration and your host should shame himself (and i want to know who he is for blacklisting). In case of #2 it is obvious but, in case of #1 it might result in a probable security issue with Dragonfly or one of the add-ons. CHMOD the directory to 555 (read and execute only) and see what happens with test.php. It should give you a clue.

I have a feeling it's case 1. The gruop my www folder is in is users, I can not change group to i.e apache.

When I chmod to 555 test.php will not execute..

Execute as in...? (error message, blank page, etc..)

1. Who's the owner of test.php?
2. Who has permission in the directory? (Does the directory have execute permissions?)

So, I have now been trying to get something sensible from the support from my host Fastname.no, not an easy task

Here is about what they had to say:
There is in no way a security hole that webusers can "write" to there webarea, this is necessary for lots of dynamic webapplications. The point is that the scripts he is using is not doing a proper validation and allows people to upload and run files trough the site.

Honestly the reply form my host doesn't make much sense, it seems they don't understand the problem fully.

I have tried to explain that there's no malicious files on my webhotel, and that there probably is malicious files on there servers which are execed remotely and which will then again create files on both the webhotel for biaworld.com and mysticaly.net at the same time.
I informed of the above in my latest e-mail to them, they did not even bother to reply to my concerns.

Blacklisting Fastname.no seems more and more like a good idea. I gave them the benefit of doubt and asked if Dragonflycms.org would not do this at that time however I have a strong feeling they will not work to solve my problems.

Edit: Before I forget, They have of-course blamed the CMS for my troubles, meaning Dragonfly, however it's funny, on the other site (mysticaly.net) I am running Seditio CMS and have the exact same problems there, and both sites will as said above be infected on about the same time. mysticaly.net hardly have anything more than the bundled package from Seditio on the webhotel, hardly any extra files at all (a few images of me and that's basically it)

DJ Maze wrote:

Execute as in...? (error message, blank page, etc..)

I believe it was "No permission error" and foobar.php where not created. 555 makes no other pages accessible to from my site.
I can not really test it, since the support actually closed my website (removed DNS I believe), they promised to put it up as soon as I removed the new phising files and replyed to there e-mail, they have yet not succeeded with putting it back online.

Quote::

"There is in no way a security hole that webusers can "write" to there webarea, this is necessary for lots of dynamic webapplications. The point is that the scripts he is using is not doing a proper validation and allows people to upload and run files trough the site."

Can you validate this claim? Do you see HOW someone can upload files to your site and do you have the log/analysis of this information? What methods are you aware of for uploading files and how are you maintaining these uploads? Did the exploit occur as a result of files being uploaded legitametly by dragonfly?