WordPress Security Issues

Hacks are ALWAYS a WordPress Issue

by Ben Cook on April 14, 2010

Any time a WordPress site is hacked, it becomes a WordPress problem.

Now don’t get me wrong, hacks happen.

Unfortunately that’s just a fact of life in our online world. When a platform becomes popular enough, the ne’er-do-wells will eventually attack it.

WordPress is no exception.

It’s been the target of countless attacks and hacks over the years; some because of vulnerabilities in its code, but most due to vulnerabilities in plugins, servers, or outdated versions.

I recently reported on a nasty attack that’s been targeting WordPress sites with Google cloaked pharmaceutical spam. Just days later, a different hack hit the WordPress installs of many Network Solutions customers.

Disclaimer: I’m the SEO Manager for Network Solutions. I had no involvement in the recent WordPress episode on a professional level. Also, this blog does not, and never has spoken for NetSol. I’m not an official rep for the company or anything like that. I’m simply a big fan of the WordPress platform.

In reading Network Solutions’ blog posts, it seems the WordPress community was very helpful in this situation. However, the sentiments expressed following these hacks, and readily apparent in Matt’s recent post, are what I’m calling into question.

There was so much press about WordPress hacks going around that Matt Mullenweg felt the need to address the issue in a blog post published yesterday. While he was talking specifically about the NetSol attack, the impression I got from that post is “if the vulnerability isn’t in the core code of WordPress, it’s not our problem.”

Not My Problem

When reporting the “pharma hack” in the WordPress support forum as well as the WPtavern forum there were several replies that seemed to be reprimanding the poster for suggesting it could be a WordPress issue and that a smoking gun would be needed before it would be taken seriously.

It was in fact that sentiment, and the lack of coverage about the ongoing pharma hack, that prompted me to cover the attack again, despite it having already been mentioned months ago on several different sites!

Again, let me be clear. I’m by no means suggesting that all hacks are due to faults in the WordPress code. In fact the large majority aren’t.

However, they ALL impact the community, the platform’s brand, and should be dealt with swiftly and aggressively. In short, they’re ALL WordPress’ problems to deal with.

Thousands of WordPress users are being hit with the “pharma hack” (Google has just under 2 million results for title tags that match the hacked pattern) and WordPress hasn’t said a word about it.

Mark Jaquith has reached out privately to a few people and there’s finally a thread on the support forums that didn’t get deleted but we still don’t have the vulnerability pinned down months into this attack.  Chris Pearson has been tweeting about it, in an attempt to solve the issue, but that only earned him a lecture from Matt!

Whether WordPress is the source of this problem or not, if no solution is found, what option will these blogs have other than to stop using WordPress? Sure it might not be WordPress’ fault, but if another platform isn’t being exploited in this way, it won’t much matter.

Brand Damage

WordPress has earned a well deserved reputation as a great CMS. However the frequent updates, many of them security related, have also earned it a reputation of being insecure.

Users who don’t update to the latest version are obviously posing significant security risks, but every time they get hacked, it’s one more person that has a WordPress hack story to tell. Every hack that targets a WordPress plugin is another Do Matt and others within the community really not care whether WordPress’ reputation is damaged in this fashion?

Defensiveness

The root of this “not my problem” attitude is likely defensiveness. No one wants to be at fault when a hack happens. And, WordPress get’s more than it’s fair share of accusations. Since WordPress is developed by a team of volunteers, it’s easy to see why they would take offense to these accusations.

However, with as many security releases as WordPress has put out in the last year or so, it’s certainly not unreasonable to suspect the platform could be the source of a vulnerability. Yes, security releases mean that a threat is being dealt with, but it also means that exploits were there in the first place.

As I said, hacks happen. The WordPress dev team has very limited resources. Unfortunately there are probably thousands of hackers out there right now trying to figure out how to exploit the platform.

The fact of the matter is it’s only a matter of time until the next one is found. That doesn’t mean the WordPress team is made up of horrible people. It just means they’re out-manned.

What would you have us do?

Thankfully, there are several actions the WordPress community (myself included) can take to improve this situation. They include:

  • Be more vocal in praising the WordPress developers for improvements and successes.
    Sure there’s more motivation to comment or blog when you’re upset. But if the team deserves criticism, then they also deserve credit when they succeed (which happens much more frequently than the slip-ups). I’m one of the chief perpetrators of this and resolve to do better in the future.
  • Volunteer to beta-test new releases.
    The WordPress dev team is always looking for more testers. The more people looking at the beta releases, the better chance problems will be found before the full release, thus preventing more of the updates we all love to hate.
  • Don’t take criticism personally.
    This one isn’t easy but just because someone suggests there could be an issue with your theme, plugin, or even platform, doesn’t mean they hate you. Mistakes happen. Let’s figure out how to fix the problem and move on.
  • Discuss hacks openly.
    One of the biggest mistakes I see being made right now is that information about hacks and vulnerabilities is often treated like a state secret. While I certainly can see the merit in keeping information about how to perpetrate a hack private, in today’s Twitter world, everyone is going to know when an attack happens.You’re not going to keep the discussions from happening, so you might as well bring the conversation onto your own turf. When something surfaces that’s affecting thousands of WordPress users, you need to address it.
  • Face the facts.
    Whether it’s earned or not, WordPress has a reputation as being a security problem. The very fact that WordPress get’s so many hack reports proves that people are naturally inclined to blame the platform. Realizing and accepting that will make it easier to go about fixing it.
  • Hire more security experts.
    One of the biggest ways to change the security reputation would be to hire more security experts. It’s obvious the team will never be able to compete with the number of would-be hackers out there. However, by publicly hiring security experts, you’ll not only be making a good PR move, you’d improve the product as well.More folks focusing on security would allow more thorough review of plugins and themes that are submitted, as well as more active pursuit of active hacks or attacks.

Your Suggestions

Thankfully, the WordPress community is full of people a lot smarter than me. I’m by no means a security expert (as I’m sure you’ve seen over the course of the last few posts) but there are plenty of you out there. What kinds of suggestions do you have? How can WordPress improve the security situation, or are things fine the way they are?

image source: rpongsaj

{ 12 comments… read them below or add one }

Doug Waltman April 14, 2010 at 2:32 pm

“How can WordPress improve the security situation…?”

Here are just a few ideas I had off the top of my head that would help improve security:

1) One thing I think has been needed for a long while is a built in, easy way to change the wp-admin directory to something else. It’s way to easy to detect if a website is running WordPress just by typing /wp-admin at the end of the site. I could see a plug-in following up this functionality by changing the directory daily based on a preset convention.

2) The default username is always “admin”. Version 3 will correct this by allowing you to select your own username, but this won’t solve the situation for all of the current WordPress installs out there with “admin” as the username. A check should happen when upgrading to version 3 that forces you to pick a new username if your username is admin.

3) A plug-in verification and/or filtering service would be great. I know this would be quite an undertaking.

4) Add some code that checks the file permissions of critical files, and alerts the user in the admin panel if they are not setup correctly.

5) Give an alert in the admin page that urges the user to move their wp-config file out of the root web folder. This could be followed with an explanation on why doing so is important as well as instructions on how to accomplish the task.

Joe Hall April 14, 2010 at 2:45 pm

Here’s the way I see this:

Network Solutions, and many other hosting providers dropped the ball on this one by configuring their default shared hosting packages to have open file permissions in the root directory. Any web developer with a bit of experience with server management will tell you that’s a BIG no no whether the client is using WordPress or not! This ISN’T a WordPress issue its a hosting security issue. One that could potentially harm any site on those systems….with or with out WordPress….To assume that WordPress has a heighten responsibility simply because their software is popular enough to be hit with a faulty server is illogical.

Ben Cook April 14, 2010 at 3:56 pm

Joe, I guess I must not have been very clear because you’ve missed the point entirely.

Whether the vulnerabilities in these two cases were in the WordPress core or not, they’re still an issue for WordPress to deal with.

WordPress isn’t responsible because the platform is popular, it’s popular because it’s an issue impacting large segments of the community. Not to mention because of the brand/reputation issue that I highlighted. Again, I’m not looking to assign blame for any specific hack or hacks. I’m trying to discuss the attitude the community has about these hacks.

Joe Hall April 14, 2010 at 4:09 pm

Discussing the attitude of the community is a valid point to an extend. But to shed some light on why some folks might be defensive regarding this issue is because some with in the security industry and the blogging community are quick to cast blame on WP to simply make a name for them selves. While doing so they spread inaccurate information about WordPress and security as a whole.

Its the same when we see folks in the SEO community spout complete garbage as truth just so they can attract links and attention.

Another issue that I think not enough people have talked about in regards to why open source developers may be defensive, is because they didn’t get into all of this with a business mindset. Instead the business expectations and performance was expected as their systems grew. I think that’s got to be a hard transition for anyone that just wanted a platform for their own uses and now is responsible for a whole world of blogging software.

Ben Cook April 14, 2010 at 4:41 pm

Joe, I understand why folks might get defensive. The number of false “WordPress let me get hacked!” claims is probably pretty ridiculous. But again, as I said in my post, that only underscores the perception problem WordPress faces.

Also, the amount of misinformation surrounding this subject is so high because, similarly to SEO, it’s a complicated topic. I certainly don’t know very much about security and rely on what others tell me.

However, there’s a big difference between warning people about hacks or issues that are ongoing & can impact their sites, and simply yelling fire or in this case “hack” to make a name for themselves.

In regards to your point about open source developers being defensive, I would certainly argue that Matt Mullenweg obviously now has a business mindset. Now, the volunteers that work on the project may not and again, it’s easy to see how they could become defensive (this is their baby after all) but that doesn’t really help anyone in this situation and only alienates members of the community.

For example, a recent commenter had this to say after reading Matt’s recent post:

I don’t understand why Matt has to always be so cocky about everything. These discussions are good for the user base. I understand if a host is blaming Wordpress for loose practices, but get classy Matt and stay professional in how you address the situation.

THAT is the attitude & approach that I’m hoping to discuss and improve upon in this post.

Joe Hall April 14, 2010 at 5:39 pm

I agree that Matt Mullenweg does have a business mindset. But that doesn’t mean he’s a very good business person. (I hate myself at the moment for talking about what makes a good business person.)

Many good business people start out with a clear intention of being professional and growing their business. When you do that you are able to separate the emotion and passion from your work. As an open source developer I know how intensely personal projects can become simply because you don’t think of them as a business person would. Many times these projects are things people work on just for fun.

I think if I am ever so lucky to see one of my open source projects turn into something even half the size of WordPress, I will walk completely away from the project all together, because I am not sure I could take the pressures of being professional with a project that I am so passionate about.

Which is probably why I don’t do many open source projects any more and stick to most commercial premium products.

Norcross April 14, 2010 at 9:31 pm

I’ve fixed numerous hacked sites over the last 6 month, and it always came down to outdated versions of WP and old / unsecured plugins. And every time I ask the client why they didn’t update the site, I got the usual ‘I was afraid it was gonna break or do something weird’ response. For better or worse, WP has become the go-to platform for people who are tech-adverse, and treat it as such.

The catch-22, so to speak, is that most things that could be done to solve the issues go against the very free and open source nature of WP. Most (if not all) of the holes are due to something attached to WP and not WP itself. But as soon as you get into some sort of strict approval process on hosts or plugins, you’ve now handcuffed the very people who helped you grow.

DWcourse April 14, 2010 at 9:54 pm

Doug’s 4 and 5 are great ideas I’ve seen implemented in other products and there’s really no reason WP couldn’t implement them easily.

And I suppose they exist (if so, give me the link) but what about best practices documents for hosts and users?

But what I really don’t understand is why this post should be controversial or inspire the wrath of certain WP Ditto Heads (at least on Twitter).

Anything that affects a significant number of WordPress installations (no matter the cause) affects the WordPress community. Duh! It’s a simple statement of fact.

It doesn’t it matter what caused sudden acceleration in Toyotas or who was at fault. Toyota’s head-in-the-sand attitude nearly wrecked the company. Is that the model the WordPress community wants to follow?

Ben Cook April 14, 2010 at 10:09 pm

@Norcross, yeah, the reasons for not updating are many & diverse. And when those people get hacked, they usually blame WordPress even though it’s not actually WordPress’ fault.

My point is that if there’s a hack that’s going around, whatever the cause of it is, WordPress would do well to proactively address it, rather than having an attitude of “prove to us it’s our code that’s the problem and we’ll help you.”

Basically, the experience and attitudes I’ve seen in response to the pharma hack have been almost the exact opposite of what apparently happened with the NetSol hack where the community came together & helped solve the issue, despite the fact that WordPress code was not the vulnerability.

@DWcourse, the reaction on Twitter seems to be from people who either aren’t actually reading the post, or admittedly are too biased by the headline & their opinion of my contributions (or lack there of) to the WordPress community.

Norcross April 15, 2010 at 9:11 am

@Ben the Pharma hack has been an interesting one, since the previous ones I’ve dealt with have all been related to mucking the actual files (and thus easy to clean), and usually noticed some mention about it. As for the reaction of the community, I think it’s an issue of how you define the community itself. There is the ‘core’ community, then a much larger group of people who write tutorials, do some dev work, and help end-users on a case-by-case basis. I’d consider myself in the 2nd group, as would most folks I talk to.

KB April 16, 2010 at 9:40 pm

What I don’t understand is that nowhere am I finding anybody saying “I checked the logs and found…” Has anybody checked their logs??? — Apache and FTP. Apache will show any legit logins to the WP Admin section. FTP will show any logins via FTP.

If the access is being gained through XSS or an include, that won’t show up on a log, but the overwhelming majority of those attempts can be successfully stopped using mod_security with an inclusive ruleset. We’re getting dozens of emails noting such stops from our servers.

I find it a bit frustrating that I can’t seem to find anybody even mentioning the #1 diagnostic tool, server logs. Is it that this is happening only on crap hosts who have no customer service (and therefore no log access), or is it that no hard-core geeks have gotten hit yet (to run proper diagnostics on mode of entry)? 🙂

Ben Cook April 16, 2010 at 10:01 pm

KB, several people have looked through all sorts of logs. As far as I know they’ve not found much. It’s tough to tell when the hacks happened so wading through the logs is apparently a bit tedious. As I’ve said several times I’m no security expert but I imagine reaching out to any of the sites that have been hacked would be all that’s needed to gain access to some log files.

Previous post:

Next post: