-3

UPDATE II: I honestly fail to see how my question is inappropriate for this site, and no one seems to want to give me a reasonable response for that, but whatevs, I solved it. Thanks to the actual people that read and helped (instead of trying to enforce seemingly arbitrary "rules" for what should or should not be posted here).

UPDATE: Despite this being tagged as a duplicate, this question is trying to figure out HOW a site could have been compromised in this situation, NOT asking a generic question about how to secure a server.

I was recently alerted by Dreamhost that a few of my websites directories had been compromised with 3 letter php files written into them. Decoding them, I have discovered that they are files that send out spam when executed. When I started looking into the problem, I noticed some very strange things that make me question how I could have been hacked if the server itself (shared space with who knows how many other websites) was not hacked at the root level.

Here are some of the details and oddities:

  1. Only six directories out of more than 50 had these files written into them.
  2. 4 of the directories contain WordPress, but only 3 of those are even being served at the moment.
  3. The other 2 directories are mostly static html, no db access at all, with a little javascript.
  4. None of the directories had openly writable permissions (777) on anything in them
  5. All the files were written into the top level of each website directory, nothing lower down that I can find.

So I am let wondering how this could have happened and with the following questions:

  1. What are the possible vectors for attack here? Since some of the directories were not even web accessible, it seems unlikely that web access was the vector. Since some contain static files, it seems unlikely that this is related to one of the recent WordPress vulnerabilities.

  2. Is it possible or likely that there has been a root server level hack on the Dreamhost server, giving the attacker access to all directories and accounts?

  3. I suppose it is possible my shell account password was hacked, but if so, why would only 6 of the directories be written into? (and in random order as far as I can tell, there are many other directories in the alphabet between them and they are not in order of date modified or created either). In any event, I have changed my shell password just in case.

I am not a system admin, much more of a web designer and developer, but I would like to figure out how this could have happened so that I can better protect against this type of attack in the future. Thanks for any advice!

Stephen
  • 143

1 Answers1

3

If all the folders are owned by one system user (somewhat implied by you suggesting you have a shell account that can see everything), and the PHP scripts are run as that user (any host worth their salt will be doing so), they can write into any directory you own/have write enabled (eg 777 isn't required - owner-write is enough).

Each distinct website should run under it's own system user for maximum seperation.

As to expecting or attempting to deduce logic behind skiddies and where they drop files: that way, madness lies.

Update

Your hosting account has all of the various websites running under one user account on the server. Your shell login is as that same account.

When the webserver executes your PHP scripts (in wordpress, etc) it will be doing so as that user. This means that, absent any very clever hackery by your host, any PHP script that runs under any of the directories in your account has exactly the same access to all of the files in your account as you would when connected to the shell. This includes modifying files outside of the website's document root (eg: in other directories, even directories not "published"), writing into directories with permissions 700, reading database credentials from your configuration files, etc.

All of this means that this likely started with just the one site being exploited, and files being dropped in directories from there.

Change all your database passwords. Upgrade all of your sites and plugins (check the access logs for suspicious POSTs to see where the original entry point might have been). Check all of your sites to ensure no new users have been added in the database.

Switch to an account/product/host where each website can have it's own unix account, or you remain at risk of one website being exploited leading to all of them being defaced/impaired.

Update 2

Your host says that there was a login to the shell - presumably they were explicit in saying it was "suspicious" rather than just any login to the shell (which might be suspicious to them to begin with - few people use shells with webhosting IME).

Occam's razor says your host is mistaking your logins for an attacker's logins and this still started as (or was entirely) PHP.

If it was bruteforced, your password will have had to have been terrible or your host has no bruteforce protection to speak of.

Alternatively, you typed your password into a compromised machine or using an unencrypted protocol (such as vanilla FTP) over an insecure network (which is pretty much anything, really).

It is less likely, but possible, that there is a vulnerability in the host's systems that allows customer passwords to be lifted from say, a control panel (assuming they are stored and visible from inside there) but we'd be hearing about thousands of hacked sites at your host by now (ditto if there was some sort of server wide backdoor/vulnerability). Some attacks rely on social engineering attack on the host itself (this is seriously unlikely to happen unless you host really interesting or important sites).

Phil
  • 1,232