Now Reading
Security and Hacking: The State of WordPress Blogs

Security and Hacking: The State of WordPress Blogs

WordPress SecurityLast year, there was a lot of noise about WordPress being especially vulnerable to attacks and hacks. Not all of those reported hacks and wild fire assuptions about WordPress security were true.

In “SecurityFocus SQL Injection Bogus,” talked about one false report:

Online, apparently, it’s fine for someone to run into a crowded theatre and yell “fire” and the less basis there is in fact the more people link to them. It’s not uncommon to see crying-wolf reports like the above several times in a week, and a big part of what the WP security team is sifting through things to see what’s valid or not.

…All that said, there is a wave of attacks going around targeting old WordPress blogs, particularly those on the 2.1 or 2.2 branch. They’re exploiting problems that have been fixed for a year or more. This typically manifests itself through hidden spam being put on your site, either in the post or in a directory, and people notice when they get dropped from Google. (Google will drop your site if it contains links they consider spammy, you’ll remember this is one of the main reasons I came out against sponsored themes.)

“Sponsored” WordPress Themes were banned from the official WordPress Theme Directory due to inclusion of ads, spam, and malicious links in Themes offered for free, with a hidden price. WordPress Theme scams continue and WordPress users are warned repeatedly to be cautious about downloading and using WordPress Themes without careful inspection and testing.

In the last issue of this series on “Cyber Attacks on the Rise in 2009,” I covered the current spread of the Downadup Worm Infection that uses websites to spread its evil, impacting more than 3.5 million sites worldwide. Such attacks are becoming more rare, but hackers targeting blogs are growing in numbers and resourcefulness. We must be on our guard to protect our blogs more this year than ever before.

Everything has a weak spot, and there are always people hunting for them. With a huge WordPress Community of techno-savvy coders and hackers representing some of the biggest mouths in the world (aka bloggers), word spreads fast when a vulnerability is detected, and action is taken immediately, often fixing it before the issue becomes public.

WordPress is now being used my millions of bloggers, businesses, major corporations, and governments around the world. It is in the best interest of and to keep WordPress as secure as possible.

Even so, each is using a unique combination of WordPress Plugins and Theme code that could make it vulnerable to security issues if you aren’t upgrading or paying attention.

How Safe is WordPress?

This doesn’t mean WordPress is safe from hackers. Many WordPress blogs were hacked last year after failing to upgrade immediately. After one major vulnerability was announced and an upgrade issued, a hacker published a list of the blogs he’d found still using the vulnerable version, claiming he would start going down the list and hacking each blog – and he did. After the first few on the list were hacked, word spread, encouraging the rest on the list, and many more, to upgrade immediately.

Not all reports of WordPress security vulnerabilities are the fault of WordPress, either. In October of 2008, WordPress 2.6.3 was released to cover a Snoopy class vulnerability, an upgrade that involved two files and had to do with code that WordPress is dependent upon, not code within the WordPress core. Vulnerabilities can be found in PHP, MySQL, JavaScript, and server applications that WordPress depends upon, all out of the hands of the WordPress development team, but that doesn’t stop them from paying close attention and closing every loop hole they can find, and then some.

Many WordPress Themes and Plugins are easily authored by people with little or no experience, leaving the door open to all kinds of security issues and vulnerabilities. This is the year many are saying that better standards need to be developed to ensure Themes and Plugins are well coded to prevent such issues.

WordPress 2.7 now includes comment enhancements that include password protection checks and improvements to security from previous versions such as password disabling reset per user, improved password and cookie security improvements, SSL and cookies handling, triple cookie security checks, configuration keys to improve authentication issues, and even HTTPS settings for security protection on WordPress.com blogs.

In “WordPress Security Predictions in 2009,” BlogSecurity says that WordPress and websites were attacked this past year by “Cross-Site Scripting, SQL injection, SQL truncation, Cookie generation weaknesses, Directory Traversal, Arbitrary File Uploads and Cross Site Request Forgery attacks,” along with many other hacks and whacks, and takes a look at what might be in store for WordPress in 2009:

  • More fake backdoored WordPress sites exploiting the new WordPress upgrade feature.
  • More SQL Injection and Cross-Site Scripting vulnerabilities in the core code and/or new third party codes.
  • More WordPress Plugin-related attacks will result in improved secure framework for Plugin developers.
  • Attacks through Automattic products and services designed to integrate into WordPress.
  • Attacks against WordPress.com.

With the growing popularity of and , it’s inevitable these products will come under the magnifying lens of hackers, as can any blogging platform or web app. With the growing popularity of Twitter, Facebook, LinkedIn, and YouTube, they also could be the next target of an attacker in 2009.

Luckily, the WordPress Development team is forewarned and forearmed and ready to defend WordPress.

WordPress is Not Alone in the Fight to Protect Bloggers

While WordPress has been open and transparent about most of the security issues its faced, many think other blog platforms like Movable Type and TypePad are more secure. Not according to _ck_ who blogged that Movable Type isn’t good about reporting security issues:

See Also
YouTube features for Content Creators

Every so often I come across a comment on the web about how Movable Type “doesn’t have the security issues” that WordPress does, which really annoys me. No one likes bugs but to be misinformed about security is wrong.

The reality is this couldn’t be further from the truth – Movable Type has had at least three security issues this year but Movable Type is to blame for hiding/lying about the situation with no vulnerability reports and leaving people in the dark until they have a fix. So which is worse, warning people ahead of time there’s a vulnerability and not being petty about how it will make you look – or just not telling the users while the hackers already know how to exploit the problem?

Movable Type had several public security issues including the ‘publish post’ Security Bypass Vulnerability in January 2009, Security Update for a cross-site scripting (XSS) vulnerability in June 2008, and Security Update for blog template generation vulnerabilities in January 2008.

Anil Dash of Movable Type commented on security reports in early 2008, admitting that some security issues are handled “in house” before they ever make it to their customers or to the public, so often they are not fully reported:

Movable Type has a proven track record of having excellent security and an established reputation for fixing any known issues quickly. And that history of security is by design. We think there are some key things our community needs to know…

…Movable Type has the best security track record of any popular installable blogging software, according to the U.S. Department of Homeland Security’s own reports…When any issues have been found with Movable Type, they’ve typically been discovered through our own routine security audits, and fixed without ever having been exploited in the wild.

This isn’t an issue of which blog platform is best. All are working hard to protect their users with the resources they have available.

In the next issue in this series, I’ll offer some tips on how to protect thyself and thy blog from security vulnerabilities and hackers.

Article Series on Web and Blog Security

View Comments (14)
  • The DHS graph makes a pretty bold statement for whatever it’s worth.

    2005
    WordPress: 11 vulnerabilities
    MovableType: 6

    2006
    WordPress: 18
    MovableType: 1

    2007
    WordPress: 49
    MovableType: 3

    2008 YTD (June)
    WordPress: 42
    MovableType: 0

    I’m not sure what the search criteria was for that graph, so I just ran two searches of my own for basically all types of vulnerabilities and all severity.

    WordPress
    2004: 2
    2005: 13
    2006: 21
    2007: 63
    2008: 61
    2009: 0

    Movable Type
    2003: 1
    2004: 0
    2005: 6
    2006: 1
    2007: 3
    2008: 2
    2009: 3

    Make of it what you will.

  • I’d also note that the post at _ck_ is totally unsubstantiated. Secunia did create a category for Movable Type 4.x and I’ve seen no proof that 6A has hid any information from its users about vulnerabilities.

    Repeating such accusations without proof isn’t a terribly responsible thing to do, imho.

    • @Paul William Tenny: A statement of assumption is not a fact nor an accusation. I’ve heard this said by many about WordPress, Movable Type and others. Anil Dash admitted that few security issues ever see the public light, and most are discovered before they impact users. WordPress is definitely more transparent, and does fix security vulnerabilities before they ever see the public light. Even with the high concern and fast response times to these issues, WordPress is more often accused of being “swiss cheese” by many, as you can see in the comments here, when that accusation is also not the truth.

      The DHS graph and other security monitoring systems for security vulnerabilities are often misleading, I’ve found out. WordPress admits theirs right up front, and often these WordPress specific issues have to do with MySQL, PHP, and Plugins rather than the core of WordPress, leading many to assume WordPress is less secure. I don’t work for WordPress nor Automattic, nor Movable Type or others directly. I am an advocate for WordPress, which makes me biased, of course, but I’ve learned that such reports don’t tell the whole picture, since there is no single reporting agency nor requirement for reporting. The WordPress Community is very response and reports widely, whereas other platforms keep their information closer to the chest.

  • I have a WordPress blog that runs the 2.6 version at the moment,however I could upgrade to 2.7 if I wanted to.I think the problem why people don´t upgrade immediately is because some of the plugins will not work after the upgrade and another reason is that there is a new upgrade coming out often.

    • @Tom Lindstrom: It’s true that the past perception is that upgrading will be a mess due to Themes and Plugins not being compliant with the new version. Expect to see that change dramatically this year with improvements in auto-upgrade of the core, Plugins, and soon Themes. Last year was a major push to bullet proof the WordPress core for Plugins and expect that also to continue. WordPress is still in the early years of its development and last year taught the WordPress Community a lot about security issues.

  • I think the reason that people don’t upgrade is because WordPress sells itself as a brand to people that just want it to work, and don’t care beyond that. The result, unsurprisingly, is that people who don’t care about security.

    It might also help if WordPress didn’t resemble Swiss cheese.

  • Many of us don’t upgrade as quickly as you would prefer because one of your recommened hosts… bluehost.com… uses Fantastico for upgrades and they take their sweet time making the upgrade available.

    They are #1 on your recommendation page.

    I’ve suggested this before: put Bluehost/Fantastico on notice. Get with it, or get dropped from your recommendation list.

    • @GoingLikeSixty: It helps to target such requests directly to WordPress. Have you? Be sure and complain to bluehost and Fantastico as that will often work even faster since WordPress is not responsible for server upgrade timing. As for the order of the list, I think it’s in no particular order.

  • Upgrading isn’t always an option but it would be very helpful if WordPress was more open about the security vulnerabilities it has fixed. I cannot, for example, upgrade to 2.7 so its not helpful to know that there is improved security available in 2.7 while the 2.6 branch has been left unpatched.

    WP2.7 is a significant change. Our in-house testing revealed that the new UI is less usable for our company, while the new comments features are unneeded (and unwanted) by us. The automatic upgrades present some significant risks to us so our only option is to remain on 2.6.5 and keep as much up-to-date with security news as possible. Or move to a different platform.

    WP does not clearly identify code changes that are made for security. This makes it hard for anyone to make manual changes to harden their sites.

  • A statement of assumption is not a fact nor an accusation.

    Lorelle,

    I’m not sure where you get “assumption” from.

    The post by ck directly accuses 6A of covering up security vulnerabilities in order to “keep their security stats low (or non-existent)” with no evidence provided to backup such an irresponsible claim. And coming from a WordPress user (him, not you), it looks like nothing but petty sour grapes from a CMS fanboy.

    Perhaps that is not the case, but it sure looks like it is.

    Anil Dash admitted that few security issues ever see the public light, and most are discovered before they impact users.

    And there’s a significant distinction and benefit between flaws found in-house that are never discovered in the wild, and those that are. The fact that few MT vulnerabilities are ever discovered and exploited in the wild is a good thing, it means 6A has security policies that are working while Automattic does not.

    WordPress is definitely more transparent, and does fix security vulnerabilities before they ever see the public light.

    If 6A and Automattic both fix vulnerabilities before they become known or are exploited in the wild , and yet WordPress still has significantly more vulnerabilities discovered and then exploited in the wild, then WP has a serious problem and it seems pretty reasonable for 6A to be able to claim to be one of the most secure CMS platforms out there.

    Moreover, why do people use it as a sign if dishonesty or deception when 6A does it, but a positive when Automattic does it? It smells like a double standard.

    Even with the high concern and fast response times to these issues, WordPress is more often accused of being “swiss cheese” by many, as you can see in the comments here, when that accusation is also not the truth.

    How is it not?

    After leaving a comment here, I returned to Dash’s post on MT security and read through some of the comments and took up (partially) a challenge that Matt Mullenweg had left. I went through all the reports in the NIST database for 2008 for Movable Type and WordPress and did a separate count the core, plugins, and third party libraries and applications.

    Movable Type had 2 reports for the entire year, both affecting the core. WordPress had 20 reports for the core, 40 for plugins, and 1 for a third party lib/app (PHP’s random number generator).

    The total for 2007 was the same as 2008 overall, a little more than 60 vulnerabilities according to NIST. If that breakdown holds, that means that WordPress didn’t get any more secure in 2008 than it was in 2007. Meanwhile, like it or not, there havn’t been more than 5-6 reports for Movable Type in any given year, and some years there are as few as 2 (such as 2008).

    The DHS graph and other security monitoring systems for security vulnerabilities are often misleading, I’ve found out. WordPress admits theirs right up front, and often these WordPress specific issues have to do with MySQL, PHP, and Plugins rather than the core of WordPress, leading many to assume WordPress is less secure.

    Saying that the graph is misleading without bothering to verify it for yourself is equally as bad as relying on the graph as accurate without verifying *that* either.

    Well, I did verify it:

    WordPress 2008:
    Plugins: 40 reports.
    Core: 20 reports.
    Third party: 1 report.

    Movable Type 2008:
    Plugins: 0 reports.
    Core: 2 reports.
    Third party: 0 reports.

    The total of 61 reports for WordPress is misleading, the total of 2 for Movable Type is not, but WP is still looking like swiss cheese to me.

    And to address a comment of yours from above but addressed to somebody else:

    WordPress is still in the early years of its development and last year taught the WordPress Community a lot about security issues.

    WordPress is over five years old. If it took four years just to start caring about security and there are still excuses being made half a decade after being created, I see no reason to believe that WP will ever be safe to use.

    Personally I hope that isn’t the case. I’d be thrilled if WP actually did start caring about security given the installation base, but we need to see results follow promises *first*. Until the results come, the WP security track record is awful and getting worse by the day.

  • Your counting of CVEs in 2008 appears notably different from the one in the Codex that I did, albeit a few months ago:

    http://codex.wordpress.org/CVEs

    I think the point that 6A’s security problems don’t get as much attention is a fair one. At the time when they posted they had no vulns in the DHS database, they had already done at least one security release that year. So by definition there was a problem that wasn’t recorded in the CVE.

    As an open-source project and more importantly community, WordPress makes sure every valid problem is listed with a CVE. Unfortunately because of how the database works lots of invalid things submitted by other people are in there as well.

    But the proof is in results. If WordPress truly were swiss cheese than the blogs of CNN, Fox News, NY Times, Time Magazine, Wall Street Journal, and more would have been hacked a hundred times now, certainly around election time.

    With any web application (or browser, or operating system) you need to stay up to date to be the most secure. Now that WordPress has built-in core upgrade functionality this should be much easier for everybody, even non-technical users.

  • Your counting of CVEs in 2008 appears notably different from the one in the Codex that I did, albeit a few months ago:

    Matt,

    So it seems. I can’t speak to the “invalid” CVEs because I don’t have the requisite knowledge of WP to spot them, and I don’t know what you consider to be “legacy” since that term is not defined on the page you provided. I counted a total of 20 that were not plugins or third party and I didn’t happen to notice anything talking about WordPress.com, versus the distributable. I don’t know if it’s fair or not to use WordPress.com+WordPress distributable, but this post is throwing Movable Type and typepad.com in the same pot so that appears fair in this context.

    I think we should discuss this, and set forth a common set of parameters so that this information can be reliable and agreeable amongst all. Hopefully I can get a discussion going on the MTOS list and maybe prod some better accountability out of 6A.

    As an open-source project and more importantly community, WordPress makes sure every valid problem is listed with a CVE.

    I’ve queried the MTOS list to see what the policy is on this and why it’s not more open, but I don’t have any direct control over that. They should be more forthcoming, but even if they aren’t, what does that have to do with the disparity between *known* MT vulnerabilities and *known* WP vulnerabilities?

    But the proof is in results. If WordPress truly were swiss cheese than the blogs of CNN, Fox News, NY Times, Time Magazine, Wall Street Journal, and more would have been hacked a hundred times now, certainly around election time.

    The individual security of those sites are not proof that WordPress is or is not secure. Matt Cutts urges people to limit access to the WP admin scripts by IP with .htaccess files — a wonderful idea — that could “secure” a site that still has active vulnerabilities. The security of site A is not proof of the safety of the software that site A runs.

    What we can do is judge the security of that software by measuring its known vulnerabilities, and WordPress over the past two years has had quite a few.

    Now that WordPress has built-in core upgrade functionality this should be much easier for everybody, even non-technical users.

    It’s a good start.

  • I think the problem is more or less, how well WordPress does in the future than how poorly it did in the past. If WordPress did nothing about the attacks and security holes, then yes, I think the points would be well made.

    The problem is not “My Dad can beat your Dad up,” because we are not children. Which is what, “Look at the past security problems” amount appear to be at the surface.

    It is not easy to step up and say, “We were wrong in the past, here is how we are going to change.” It should not be a sign of weakness to tell people about security problems, and I don’t think it is a sign of guilt to not speak openly about security problems.

    In the best case scenario, everyone would be on SVN checkout and upgrade whenever there was an issue. That does not appear to be the case. Whether the reason, by not upgrading any software, it opens the door for issues.

  • “But the proof is in results. If WordPress truly were swiss cheese than the blogs of CNN, Fox News, NY Times, Time Magazine, Wall Street Journal, and more would have been hacked a hundred times now, certainly around election time.”

    Aren’t those hosted and admined by WordPress staff (wordpress.com). There are obvioulsy things you can do to mitigate attacks that aren’t available to the regular user hosting a wordpress.org blog on their own isp.

Scroll To Top