Saturday, April 13, 2013

WordPress attack - lessons from my personal security review

This week there's a  brute force password attack on WordPress sites. That inspired my security review, here are a few things I learned doing it:

  • I again appreciated the FileMaker database I've used since 1997 to track my net credentials. I dump data from it to a now dated version of 1Password, but it's hard to beat the ease of searching and editing my own repository. It lives on an encrypted disk image on my local machine.
  • It's easy to end up with orphan WordPress instances. I have one on Wordpress.com and two on my Dreamhost account, but I only use http://www.kateva.org/sh/. It archives my Pinboard/App.net shares; one day, if I figure out how to do it, I may append my old Google Reader shares (json).
  • I had a strong password on the wordpress.com account, but only pretty-good on my other two and they had the same pw. I upped both to very strong but still typable. I will have to review how IFTTT connects to kateva.org/sh -- obviously there are big security risk with many uses of IFTTT. 
  • I'd been keeping my WordPress blog software current (Dreamhost makes that easy!) but not the plug-ins and themes.
  • I'd changed a theme on one blog recently, and today I learned it didn't include a log-in link! I was briefly shut out, but a bit of web research turned up kateva.org/sh/wp-admin.

The most important thing I learned is that it's not trivial to safely delete a self-hosted WordPress blog. Yikes! No wonder there are lots of vulnerable old blogs lying around for the taking. WordPress.com blogs have a delete tool, but not self-hosted sites. Things can get nasty here -- two WordPress blogs can share the same database, so deletion must be done carefully. Reading some Google hits this is a very unsolved problem with lots of confusion.

We need a fix WordPress.org and we need it very soon. Dreamhost, you could help too.

at

4 comments:

  1. Martin14/4/13 4:00 AM

    Safely deleting a self-hosted WordPress installation is actually very trivial, I have done it many times:

    1. Delete root directory of WordPress installation and all its sub-directories – your WordPress installation will be gone forever if you don't have a backup …

    There are no necessary steps 2, 3 etc. You might also delete the related MySQL database but that is only necessary if you need to space …

    ReplyDelete
  2. JGF14/4/13 8:59 AM

    Thanks Martin, that's a good summary. Here are the things I have wondered about with my Dreamhost install (which is likely different).

    I have two blogs there -- does that represent two instances of wp install or one? If one then removing WP would not be good.

    I have two databases there, so I'm pretty sure I could remove one ... but not entirely sure because I don't recall the history of my database/blog testing -- one of them might be an experiment, the other might hold data for both blogs.

    Excluding Dreamhost for the moment, what if someone has configured WP to use one database for multiple blogs?

    What I'll likely do is rename a key file in my WP install and check that one blog is broken and the other works, then remove the code.

    ReplyDelete
  3. Martin21/4/13 7:09 AM

    I don't know how Dreamhost's WordPress setup works, I've never used installations provided by hosters. A typical WordPress installation uses one database only.

    Since WordPress 3.0, blog networks are supported too (formerly known as WordPress MU).

    In any case, the database used by a WordPress installation is listed in wp-config.php on line 21 by default.

    ReplyDelete
  4. John Gordon21/4/13 3:20 PM

    Thanks Martin!

    ReplyDelete