I want to delete the stuff... just wondering if there is any reason for those index.html pages to be there that I am not aware of. Some of them have been there for about a year, but I don't know why they're in there.

The vastly most likely scenario here is that a FTP client had stored
passwords and some maleware took advantage of that to stick these HTML
files up.

We've never seen a security issue with concrete5 that would give someone
access to the file system to place this kind of trash around, and there are
quite a few viruses and whatnot out there that target FTP clients this way.

best wishes

Franz Maruna
CEO - PortlandLabs Inc

Thanks.

Hmm! So, I am on a Mac using Coda 2 as my FTP client.

I just want to make sure of what you're saying: you think my computer has a virus which is accessing the stored password in Coda 2 and uploading HTML files?

Oh, and is there any reason at all for those blank index.html pages in the "tmp" and numbered directories within the "files" directory? I don't think so, right? I don't want to delete them and screw up something about how C5 works.

The empty files are there in case a web server is set up to serve directory listings when no index is found.

Ideally a web server should be set up to reject such page requests, but many servers try to be helpful and if there is no index.php will give a directory list or even file/explorer interface.

So all those index.htm are an important security measure for many of the cheap host accounts.

Thank you for that info.

Update after talking to support:
It looks like the CMS was compromised, according to tech support.

I couldn't delete the directory because I didn't have permissions. The reason why, tech support explained was because the directory was added with the username "nobody" under apache, which is what indicates to him that it was done through the CMS.

So, now I have two questions:
1. What is the best CHMOD permissions for the files directory? 775?

2. How do I change my superuser name? I'd like to change the main user AND the password. I tried going to Search Users and clicking the name and checking "edit properties" but a blank screen pops up that just says "user attributes" and there is no option to do anything.

You can prevent index listings on your files folder by creating an htaccess file with this in the file just place it in your files folder..

well the "nobody" user is the user on a shared hosting box that apache typically runs under. So access through any script, by any account on the server. Doesn't mean it has to be concrete5 at all. I'd love to see some logs or a trail to understand how this might have happened through concrete5. Certainly anything's possible in life, but the tech is making some pretty big assumptions there.

Permissions for the files directory depends on how PHP is setup. If nobody has ownership of the files directory, 755. Alternatively you may need it set to 777.

I had a similar issue on a virtual host some years ago and as far as I recall the explanation from the support guy, the error was that one of my "harddisk-neighbours" had a compromised webserver and because I was using FTP (instead of SFTP), the script was able to hijack my access and somehowlikethat get into my directory.

After I reported the issue, they found out that some other installations on the same harddisk were affected in a similar way.

Since then, I stick to SFTP - seems much smarter.

Hm. I guess I will call and ask about SFTP. When I try to use SFTP in general it never works for any host, so I'm guessing it's a setting that has to be made on the hosting environment itself.

Thanks, support said 777 was maybe why it was vulnerable and said the best option was to use a script wrapper such as suEXEC and php-cgiwrap. Which I don't understand yet, but I'm reading about it.

btw, there was nothing in the C5 logs except email form submissions from new clients.