How do I put an end to this reoccurring CMS/hosting security breach?

January 10, 2009 11:06 PM

How do I put an end to this reoccurring CMS/hosting security breach?

I am using Drupal as a CMS and all my sites are hosted through the same provider. On a few of my installs (version 6.8 - the latest of Drupal) mysterious directorys full of porn and prescription drug HTML pages keeps occuring. Said host said this was due to a security breach in my CMS, which I do believe. How do I stop it though? I delete these folders when I notice inbound traffic in analytics but I want to solve this problem once and for all. If anybody has any advice or experience with this kind of situation please clue me in.

posted by serial_consign to computers & internet (12 answers total)

Someone I knew had this problem too, and it turned out that it was a compromised server on the webhost's side, although they had denied it up and down for months. YMMV, obviously.

The only things I can think of would be:
- Make sure that your Drupal install always has the most recent version of the software.
- Change your login often, not just for Drupal but for your FTP and admin access to the webserver as well.
- Is there any way that you can ask your hosting company to only allow uploads of content to your domain from set IP addresses?
posted by gemmy at 12:04 AM on January 11, 2009

This might be of help.
posted by benzenedream at 12:59 AM on January 11, 2009

Is there any distinctive text in the pages? The drug names are useless, but if there's any significant string of words, even--or especially--if misspelled, you might try searching for it to see if you can hunt down a little more information or other references. There's an exploit that turns up every once in a while in the MT forums where someone's index pages will have similar crap tacked onto the bottom of them. There's no known exploit for MT that would lead to this(always with the caveat of "currently," of course), but on several occasions, searching for some of the text has revealed it it to be a case of someone gaining direct access to the server and modifying the files, not the application. This then leads to "change your ftp password(s)" and the like rather than trying to lock down your CMS.

On that point, it's also worth checking whether the spam content is visible from within Drupal or if there are just mystery HTML files appearing on your server. My experience with Drupal is minimal, but I believe that it doesn't normally produce static HTML files, which would put your host's response into question. Them telling you it's a problem with your CMS shouldn't be accepted at face value; the moment there's mention of any software they don't explicitly support or install for you, they tend to shut down and blame it.
posted by Su at 5:05 AM on January 11, 2009

At this point, if it has been on-going for some time, it's likely the persons exploiting your site have built themselves some backdoors into your site; probably in the form of custom modules, extra users in your database, perhaps even new users on your webhost, etc. In short, at this point, it's probably going to take a fairly comprehensive rebuild of the software running your site and a thorough analysis of the data in order to get things locked down again. I'm not a Drupal expert, but under the assumption that it keeps all of its information in a backend database, I'd suggest completely wiping the Drupal installation, making sure to keep your database intact, and re-installing, pointing to the existing database. Then, disable any custom modules that may be installed. Then check for any users in the database that don't belong (be sure to do this after reinstalling and disabling custom modules - something could have been done to hide users they created), and change the passwords on all the users that do belong.
That should be a good start towards getting things cleaned up, but if you're truly serious about web hosting, I'd recommend finding somebody who knows Drupal and web security to give your site a once-over just to be sure. This will probably cost you some money or beer, but will be well worth your while.
posted by jferg at 6:27 AM on January 11, 2009

You might also want to take a look at your rich text editor's settings. I remember getting slammed in a very similar way when I had FCKEditor improperly secured.
posted by advicepig at 6:39 AM on January 11, 2009

If you can't find the hole, I'd say it's time to start monitoring your raw http and ftp logs very, very closely.

In the mean time, it might be worth doing a few things:

1. Hand-check each drupal user's permissions. Delete any users that you don't need or don't know where they came from.
2. Change all FTP usernames and passwords. Use STRONG passwords.
3. Examine every single file that is web-accessible on your server. If you don't know what a file is or what it does, find out.
4. Use some diff-like program to check your drupal files against the stock files to ensure that no back-doors have been added. (alternately, just delete and re-upload with the stock)
5. double check that all drupal modules are needed and up to date.
6. Start checking your directory structure every day. Don't wait until the spam starts showing up in analytics. If that sounds like a daunting task, pick up a piece of software like this and have it email you any time a file/folder is added or changed.
posted by toomuchpete at 7:24 AM on January 11, 2009

7. If you're running on *nix, make sure that your directory permissions (chmod) are as restrictive as possible to someone reduce the risk from a security hole on someone else's site in a shared environment causing problems for you.
posted by toomuchpete at 7:25 AM on January 11, 2009

Wow. You've given me a lot of work with and think about folks. I'll look at this material later today, take some preliminary steps ASAP and report back here. Thanks!
posted by serial_consign at 7:53 AM on January 11, 2009

Although I believe Drupal 6.x will return an error message (and possibly fail the install/upgrade) if it's on, you should make sure that the PHP value register_globals is set to "off."
posted by camcgee at 10:06 AM on January 11, 2009

Also, be sure to check Drupal's watchdog logs. What security holes do accasionally pop up in core and third-party modules leave a trail: they are stuff like "sneaking some XSS into a post title" or "uploading a malicious file when posting via a blogging client"; it's been, literally, years since there was any sort of invisible security hole someone could exploit. Anything they're doing on your CMS should leave a trail, and if that isn't there, it's another point in favor of your "the server is compromised" theory. The only time I've had a Drupal install compromised was when I uploaded a test database for some tinkering, and forgot that I'd left the admin password as "password". Embarrassing, but also a bit comforting: I had to be REALLY stupid to compromise my site.

As others have mentioned, any software not explicitly installed by the hosting company tends to take blame first, even if there are no known exploits that would result in the kind of stuff you're seeing.

Alos, is there any other information about where these files are appearing, what the permissions on them are, and so on? Make sure that your directory permissions are locked down: if the /sites or /files directories have too broad of permissions, Drupal should be flashing warnings at you when you visit the /admin pages; we really try to alert people if there's anything in its reach that could be misused.

FTP logs and any other OS-level logs you can get your hands on are nice as well. Apache and PHP logs from the time when the files appeared can also help eliminate possibilities.
posted by verb at 10:57 AM on January 11, 2009

On review, what everybody else said.
posted by verb at 10:57 AM on January 11, 2009

This might be of help.

Just a note: webpages can die or 404 all the time, so sometimes it's useful to give context to a link in case it no longer works later on.

In this case (in case something happens to the link), the link is to a web page on securing Drupal, and the key tips are:

1. Keep software up to date
2. Don't use dev modules
3. Make sure Drupal is set to handle files in the file directory and set "download mode" to private
4. Don't allow PHP input type
5. Check your .htaccess
6. Secure user login
7. Restrict file types allowed by upload module
8. Check logs
9. Use https for logins and cookies

posted by Deathalicious at 10:16 AM on March 29, 2009