I guess I already know the reply I will get when posting this, but I got the same reply the same time I posted about a security whole in Dragonfly and after a while you where forced to admit that the security hole did indeed exist (so much that you feelt you needed to remove my original post because of the nature of the hole)

Well point is, please take this one seriously to!

In my server two folders have been starting to appear magicaly
these folders are server_root\www\TD and server_root\www\https
Both folders contains server applets which creates a phishing site for two banking companies, apparently for credit card frauds.

Whenever I delete those two folders it takes just a few minutes and they will be recreated and containing the server applets.

I would hope you can help me out with tracking this issue and finding the reason to why it keeps happening.

Sound to me like you need to get with your webhost and notify them of this issue. It is (to me) not the DF security problem. It's your server (webhost) problem. Maybe their server had been hacked into and there is a cron job or something that create these directory automatically.

the only security issue we know of, is by using the SPAW wysiwyg on your site.

DJ Maze wrote:

the only security issue we know of, is by using the SPAW wysiwyg on your site.

As far as I know this is still not fixed:

NanoCaiordo wrote:

Hello, I'm able to reproduce the security hole and your post have been moved to an hidden forums until I'll patch the system. After i realse the patch I will send a new letter to all our users to encourage them to patch their own DragonflyCMS version. After I'll sent the newsletter I will move back your topic to our security Forums. I'll be glad if you keep this issue quite as possible since lot of users could run into troubles.

A problem which you had a real hard time admitting was in DF, so don't tell me theres no security issues in DF because there is. And it was the same excact story then "It's a problem with your host" you tell that to everyone don't you.

Anyway, over to my current problem, my host is of-course blaming DF, denying that there is a problem at there side, if there was then it would of course be in there interest to fix it.

I understand your concern but, posting <meta> and <script> tags inside a news story is something totally different then editing and storing files on a server.

database != files

So blaming Dragonfly is the same as blaming your host, it doesn't solve anything.

Untill we don't know how they got in and how they got permission to edit files, it is not Dragonfly nor your host its fault.

When you or your host figured out how they came in then you know who to blame.
Afterall i can't smell, nor have the access, from here how the server is configured!

Why we expect you or your host at first is easy:
1. Dragonfly on a proper server can't create directories in /server_root/www/
2. You made /server_root/www/ writable (chmod 777)
3. Uploaded images/files in coppermine/downloadspro are validated and non-executable
4. If Dragonfly can create directories/folders the server has an security issue

So if one of the above tests succeeds it's your hosting company at fault, else it might be ours.

Mysticaly .... i was able to add html tags because i was logged in as admin

DJ Maze wrote:

Why we expect you or your host at first is easy: 1. Dragonfly on a proper server can't create directories in /server_root/www/

Proper server? OK I will simply assume that my host that are hosting 6 other domains for me, where as two with dragonfly installations is the only two domains ever hacked is actually hosting on a proper server. Never had any problems with there servers except for those two sites with DF installed.

Basically the theory that a cron job is runed at our server host seems weird to me, I would imagine that all the other sites hosted on the same exact server would report problems to our host.

DJ Maze wrote:

2. You made /server_root/www/ writable (chmod 777)

That might be a mistake you have experienced users doing, but I would never set 777 as attributes on my www root folder

DJ Maze wrote:

3. Uploaded images/files in coppermine/downloadspro are validated and non-executable

As far as I know they are all validated, every uploaded file needs to be before adding them. I will check trough the files again though.

DJ Maze wrote:

4. If Dragonfly can create directories/folders the server has an security issue So if one of the above tests succeeds it's your hosting company at fault, else it might be ours.

I have no idea to be honest if DF is creating the folders or if it is a file uploaded...

I will probably remove the whole www folder and start from scratch, I will keep the sql though.

If dragonfly can create files or folders is easy to test.

/server_root/www/test.php

PHP:

<?php error_reporting(E_ALL); # can create dir? mkdir('testdir'); # can create file? touch('foobar.php'); ?>

If one works, there's an issue

Yes, this would show a problem with permission in apache's root, or potentially worse issues.

Thanks guys for your ideas, I will test it out.

I deleted everything in my www folder, after this the problem have not occurred again, so probably some malicious files have been uploaded by a user..

I am now uploading DF to the server again and only with the most needed modules such as IRCChat, Competition, DF_Arcade and ForumsPro, other than this my site will run pretty much default DF for a couple of days to see if my problems reoccurres.

OK, I have now tested to create a file locally called test.php, I now uploaded it to various servers I have access to and it can create directories on all of them (except on one) when accessing mysite.com/test.php
What is up with that, most www folders on my sites seems to be 755, would make more sence to make them all 750 except then I can't access any files.
any ideas ?

In one of my sites it seems that it's secure as it should be
Warning: mkdir() [function.mkdir]: Permission denied in /home/timeshi/public_html/test.php on line 5

Warning: touch() [function.touch]: Unable to create file foobar.php because Permission denied in /home/timeshi/public_html/test.php on line 8

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

Edit: I'm an idiot and you all are correct, It's indeed a big security problem at my host.
With all the domains and web hotels they are serving I would never expect that they would leave such a big security problem open.
At my host I have 5 domains and they all creates "testdir" while using the tesp.php file.

I've tried my best to solve it with changing rights, but apparently my login account is limited and I am not able to change groups.

I have called the host support and they told me to call back tomorrow..
How on earth can they not make sure that stupid security holes like these once will not happen ?

contact you host and tell them to get there server(s) fixed or find another host that already had there security in order.

Dizfunkshunal wrote:

contact you host and tell them to get there server(s) fixed or find another host that already had there security in order.

Yes, I will have a chat with them tomorrow..
The worst thing is that my host have been pretty threatening and demanding that I solve this problem asap or they will close my account, and it's actually there fault. Incredible.

They want you to fix their issues ?

What about running phpsuexec is it ok ?