Site was hacked (screenshots added)

Permalink
and sexy time URL inserted...

It looks like this:
www.www.my-domain-name.com/files/dating/online-free-dating-sites.htm...

Anyone else experience this? I'm trying to determine if it's a security hole in how I set up Concrete5 or if someone just hacked into FTP.

Some screenshots attached...

We haven't worked on our site at all in 2014, so it was pretty easy to find the changed files on the server.

1. I see a hell of a lot of activity in the files/tmp folder a couple days before the porno-dating site was added. Does this indicate some sort of activity trying to brute force into a Concrete5 weakness?

2. There are a few folders that seem to be altered randomly with blank index pages inserted. I am guessing a blank index is the jumping off point for some auto-installer to upload the porn-dating webpage.

1 Attachment

 
zoinks replied on at Permalink Reply
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.
frz replied on at Permalink Reply
frz
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
zoinks replied on at Permalink Reply
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?
zoinks replied on at Permalink Reply
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.
JohntheFish replied on at Permalink Reply
JohntheFish
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.
zoinks replied on at Permalink Reply
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.
ConcreteOwl replied on at Permalink Reply
ConcreteOwl
You can prevent index listings on your files folder by creating an htaccess file with this in the file
IndexIgnore *
just place it in your files folder..
frz replied on at Permalink Reply
frz
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.
Cahueya replied on at Permalink Reply
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.
zoinks replied on at Permalink Reply
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.
zoinks replied on at Permalink Reply
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.