Tag: security

Security is nuanced

As a software vendor, there are many reasons to prefer responsible disclosure of security issues. But the most important reason is also less obvious: vulnerability reports need to be correct.

I’ve seen countless “full disclosure” reports that are wrong and invalid. Most of these could have been prevented by privately disclosing it to the vendor and allowing them the opportunity to respond.

Everyone sees WordPress in the headlines, over and over again, but no one ever notices the “this report is invalid” response. We’ve prevented countless invalid reports from being published simply because they were disclosed to us first. This is better for the software’s users, who are otherwise left to scramble every time they see a report. They are not an expert, and often, neither is the reporter.

There’s another angle here, though: sometimes, the vulnerability report is correct, but incomplete. This too can send everyone scrambling, starting with the vendor who was not given the opportunity to straighten things out.

When responsible disclosure works, it works really well. I offer Jetpack’s recent vulnerability as a recent case study. While this was discovered internally at Automattic, the effect is the same: they were able to quickly and thoroughly investigate the issues and follow through with a plan of action. During their investigation they learned the problem was far more severe than they originally identified, and that their initial proposed fix was incomplete.

There will always be individuals who want everything to be fully disclosed, and there are some great arguments for that. I’m not trying to sway you one way or the other. But if you’re trying to do the right thing — you’re doing full disclosure in the interest of users, possibly even providing a patch or steps to mitigate — working with the vendor is a good way to ensure you haven’t missed anything.

I’m not sure how many times now I’ve responded to a mailing list saying, “well, this isn’t a vulnerability,” or “your proposed patch is incomplete,” or “your patch makes it worse.” Or when I don’t respond to the mailing list because my thought is This is worse than the reporter realizes.

Security is nuanced.

Last week, a security researcher disclosed some issues with WordPress. They stated that WordPress issues a cookie in plain HTTP that identifies the user. Correct. They also stated that this cookie does not expire when the user logs out. Also correct.

She went on to state that the cookie has a lifetime of 3 years, that it can be used to mess with the account’s two-factor authentication settings, and change their email and other settings. She followed that up with “have notified them and waited 24hrs for response, none yet. guessing it’s a wontfix for now, since their SSL support is patchy.”

Yes, absolutely, SSL support in WordPress is patchy. (Coincidentally, fixing all of this was already slated for the next major release.) While you can force SSL for the dashboard, we don’t have the concept of forcing SSL for the front-end of the site. So, that “logged in” cookie is issued over plain HTTP. It’s trivial in a plugin to force that cookie to be secure, but of course most users aren’t going to do that. Of course, most users also aren’t using SSL (sadly).

WordPress also doesn’t have any concept of session management. The user is authenticated and a cookie is issued, but there’s no way for it to be automatically invalidated upon logout (without you changing your password). Changing this is a major architectural change we’ve been planning for some time. But this is also why cookies are designed with a limited expiration: just 48 hours, or 14 days if you click “Remember me.”

But the report was that it didn’t expire for three years, right? This is where it gets a bit weird. I’d love it if “Remember me” remembered you for 30, 90, or even 365 days, but WordPress will wait to make any changes until cookies can be invalidated. Some time ago, though, WordPress.com configured this cookie to last for three years.

Normally, this wouldn’t be that bad. You see, the “logged in” cookie is relatively harmless. It allows presentational things like the toolbar, edit links in your theme, and such. But you can’t use it to manage your account, change your email, or do anything particularly crazy. In fact, WordPress issues a separate, secure “auth” cookie used for the “wp-admin” dashboard. It’s like Amazon knowing who you are after six months of not being on the site, but asking you to log in when you start to check out.

On WordPress.com, however, a lot of settings can be managed outside of the dashboard, on their “new dashboard,” at wordpress.com/settings/. As you might have guessed by now, they were not requiring the “auth” cookie on this page, only the “logged in” cookie. That is the true critical vulnerability here. A number of decisions came together to make a latent issue a very real one. The issue wasn’t reported like this because the reporter isn’t familiar with the intricacies of user authentication internals in WordPress, nor should anyone expect them to. Rather, an assumption was made it was a design decision that would probably just be a “wontfix” due to “patchy” SSL support.

The disclosure was well-intentioned, but because it happened within just 24 hours, Automattic wasn’t able to react quickly enough to identify the actual issue and request that it not be disclosed until they got a fix in place.

I’m just trying to set the record straight on what happened, since I keep seeing confused tweets, blog posts, comments, and Facebook chatter. (Favorite Facebook comment, after I posted a brief explanation: “Did we just open all those nesting doll layers to discover the belly was empty?”) This situation probably could have been handled better by everyone involved, but that’s not really the point. The primary issue is now handled, and other issues are also being addressed. I don’t think this requires post-mortem blog posts with a side of FUD. I’m not looking for a debate on full disclosure versus responsible disclosure. And I certainly don’t think anyone should be questioning the researcher, who has spent years dedicating herself to making the Internet more secure.

In this case, WordPress.com the service was able to react quickly to mitigate this issue for all of its users. Of course, with software, holes can’t be closed so easily, and in this case, the situation was probably exacerbated by confusing WordPress.com the service with WordPress the software. That confusion is easy to understand, especially since some of these issues have roots in the core software.

Security is nuanced.

I’ve not linked to any previous posts because I don’t want this to be a criticism of any researcher or writer, but if you’re looking for background: 1 2 3. Also, related work for WordPress 4.0 is happening here.

New Plugin: Filtered HTML for Editors

I just released a new plugin, Filtered HTML for Editors.

This is in response to a published report suggesting there is a vulnerability in WordPress 3.0.4. The report is invalid, but I’m offering this plugin for sites that do not trust users given the Editor role.

For more information, please read my blog post on the WordPress Development Updates blog, and read the plugin’s description and FAQ.

CSRF attack strikes Twitter

I mean, who didn’t see this coming?

Twitter allows a URL to send a tweet. Many sites and retweet buttons and such rely on it. No POST, no nonce, nothing. Just a simple HTTP GET triggers a tweet. Clearly, someone was going to exploit this eventually.

Authentication is not the same as intention. You can’t just determine that a user is allowed to do something, but also that they intended to do something. When intent is not established, and especially when the form can be submitted via a GET request, it makes these kinds of exploits child’s play, as you can see by the complete exploit code below. It’s called a cross-site request forgery, or CSRF (or XSRF).

How do you determine intention? You’ll want to avoid accepting information over GET, but really that does nothing. Next step would be to check the HTTP referrer, but those can be spoofed. Since that isn’t foolproof, then you need to use something like a nonce check, like what we use in WordPress. For Twitter to secure the site from a CSRF vulnerability, they’ll be breaking a lot of embedded tools and buttons on many, many sites, so for now, they’ve apparently disabled the share endpoint that was exploited.

For the WordPress developers out there, probably the best read out there is this post by Mark Jaquith, from four years ago. It still applies as if it was written yesterday. For the non-WordPress developers, it’s still a great read as it explains what’s really going on, how WordPress prevents it, and why intention is important (if that isn’t obvious enough).

Once again, Twitter users are victims, thanks to the lack of basic security practices.

Update: Check out TechCrunch’s coverage. They quote a certain commenter who explained the issue. 🙂

Here’s the exploit:

<script type="text/javascript">
var el1 = document.createElement('iframe');
var el2 = document.createElement('iframe');
el1.style.visibility="hidden";
el2.style.visibility="hidden";
el1.src = "http://twitter.com/share/update?status=WTF:%20" + window.location;
el2.src = "http://twitter.com/share/update?status=i%20love%20anal%20sex%20with%20goats";
document.getElementsByTagName("body")[0].appendChild(el1);
document.getElementsByTagName("body")[0].appendChild(el2);
</script>

Update your WordPress

Updates are easy. They should be easier. Check out our proposal at the end of this post.

This week at Black Hat conference in Las Vegas, security company Qualys presented and released BlindElephant, a utility that scans web sites for insecure web applications. Their research identified that 70 percent of sites running Drupal are affected by critical vulnerabilities, and that the statistics only get worse for Joomla (92%), MediaWiki (95%), phpBB (100%). 1

I received a press release about BlindElephant earlier this week. At the time, I didn’t think much of it. It surely would have gotten my attention, however, had it included their WordPress statistic — 4 percent. (What did catch my attention was this IDG article.)

The application, the source for which Qualys released, isn’t about identifying critical vulnerabilities; it’s about identifying the versions of software that websites run. They made their own determinations which versions had “critical vulnerabilities.” 2 Check out their slides and white paper, both packed with great information and statistics.

For WordPress, they cited version 2.5.1 as the earliest release outside the critical barrier, which fixed an important security flaw in our secret key implementation.

In case you didn’t already know, that 2.5.1 is not secure. We’ve made countless incremental improvements to the security of WordPress in the four major versions and many maintenance and security releases over last two years.

Alas, WordPress has a security perception issue. It’s widely used and widely targeted. Plugins have extended it every which way. Of course, “My WordPress was hacked!!!!111” doesn’t mean that WP is the attack vector. It very rarely is.

But at the same time, WordPress is easy to use and easy to upgrade. Among major open source web applications, it quite possibly leads in both categories, and its developers and contributors have worked hard to make it that way.

That brings me back to BlindElephant. Their white paper says they checked more than 25,000 WordPress installs and found the vast majority of them to be running WordPress 2.9 or higher. Qualys cited the “application’s easy, reliable updating design” as why we have such a clear advantage. I’m down with that.

WordPress 3.0.1 and beyond

This post’s title comes from the 3.0.1 haiku. If you’re not running 3.0.1, please update. It’s easy, usually always painless, and will provide you (and me) peace of mind. But we do have goals to make it even easier. With that, I leave you with one such proposal, from Daryl Koopersmith (@darylkoop) and me: If you fall behind on your updates, we’re thinking a modal dialog box with a twist. What do you think? 3

Notes:

  1. The Drupal number may be slightly high, as this comment points out, as Drupal 5.22 may have been incorrectly classified as critical. (Their slides were not kind on Drupal, so I am unsure of the intention.) ↩
  2. WordPress and Drupal in particular received additional attention of the researchers, as a few dozen popular plugins and modules were also inspected. ↩
  3. Please know we’re not being serious. We do have plans, but this isn’t it. Well, probably. ↩

MediaTemple, WordPress, and attack vectors

WordPress has been mentioned a lot lately. Is this application specifically vulnerable?

No. WordPress is a high-quality project that updates their software whenever a security problem is found. The latest versions do not contain any vulnerabilities that we are aware of. If you are running an old version, please update yourself. This is a common practice and should be familiar to any Windows or Mac OS X desktop user.

This being said, due to the ubiquity as one of the world’s most popular open-source publishing systems, WordPress is often the target of the payload with code injections and backdoor entry points after the attackers have maliciously gained access to a user’s website. The fact that WordPress is frequently a payload target DOES NOT mean that WordPress itself is vulnerable. It just means it’s popular and very powerful. You should continue to use it and we think it’s great software.

I couldn’t have said it better myself. Thanks MediaTemple.