How it Works

SSL/TLS, the encryption protocol commonly used for securing traffic between web browsers and servers, has a feature called a “heartbeat.” Every now and then, an exchange like this happens between the client and the server:

Client: You still there? If so, send back “ALIVE,” which is five characters.

Server: ALIVE

If the heartbeat succeeds, the connection stays open. This keeps happening, over and over, with a different value being passed each time.

Now here’s what happens if someone exploits the Heartbleed bug:

Client: You still there? If so, send back “KITTEN,” which is 300 characters.

Server: KITTEN, and here’s a block of random memory from RAM!

In this manner, an attacker can get a random 64KB chunk of data from memory every time a heartbeat is sent, thanks to a lack of validation of the length parameter. (So an attacker can just repeatedly make attempts.) Eventually, they’d get lucky and find something interesting. Such as the SSL certificate or users’ passwords and data.

Exploiting this bug is trivial. (There were people posting scripts to test for the vulnerability minutes after it was announced. Just imagine how quickly malicious types got to work implementing exploits for the bug!) It’s also possible that someone knew about it months or even a couple years ago, and has been exploiting it ever since. Bloomberg even suggests that the NSA has known about it for two years, and has been exploiting it rather than disclosing the problem.

Is it Fixed?

Yes! Your Linux distro should already have patched builds in their package manager, so it’s just a simple manner of running a couple of commands to update your openssl and libssl1.0.0 packages, then restarting any services that depend on SSL. (Or just do a full reboot if you’re paranoid.) In the case of Ubuntu, you’d just do something like this to update the packages:

sudo apt-get update
sudo apt-get dist-upgrade

You should now revoke any SSL certificates and issue new ones, in case they were leaked in an exploit of the bug.

What Should I Do, as a User?

Change your passwords! For anything important—email, banking, etc.—you should consider picking a new password.

It’s important to note that this is not a WordPress security flaw, but rather an attempt to systematically guess passwords.

The attacks consist of simple POST requests to wp-login.php with a supplied username of admin and one of many simple, insecure passwords. I’ve noticed plenty in my logs, including rainydays, sophie1, and wordpress. The requests come from a rotation of IP addresses in the botnet, making it difficult to block them outright.

It’s easy enough to protect yourself from the attacks, providing you follow some simple best practices.

1. Get Rid of the Admin User

Historically, every WordPress installation would come with an administrative user named admin, which was created during the setup process. In more recent versions, the setup screen prompts you to choose your own username instead of providing a default. Check the Users screen in your WordPress backend to see if a user named admin exists. If it does, you should replace it with a profile that has a unique name, ensuring that the new account has administrative privileges.

Having a user account with that default name is a bad idea, because numerous attacks over the years have operated under the assumption that the operators of many WordPress sites will have been too lazy to change it. The current attack only tries passwords for a user named admin, as well, so ensuring that such a user does not exist will go a long way toward protecting your site.

2. Set a Strong Password

What’s the common theme among these passwords?

• sophie1
• rainydays
• roberts
• online
• onions

They’re all incredibly simple and insecure, and they’re all ones that were tried right here on Webmaster-Source recently. Obviously you want to avoid passwords like those if you want to avoid being compromised.

For a basic, reasonably strong password, your password should:

• Be at least eight characters long
• Have a mixture of upper and lower case letters
• Contain numbers and non-alphanumeric symbols

An easy way to create something secure and memorable is to pick a phrase that means something to you and use the first letter of each word, mixing up the case and adding some numbers and symbols. For example, “The Wheel of Time turns and Ages come and pass” would become TWoTtaAc&p13. Complex, yet still possible to remember.

Or you could go with the XKCD method and pick four random, unrelated words and use them as your passphrase. (e.g. “double pizza kitten book.”) As the comic explains, such a password can actually be more secure against a brute-force attack, and is far easier to remember than a conventional password.

3. Block the Bots

Install a plugin like Bad Behavior (which will also help cut down on spam comments) or Limit Login Attempts. Both plugins attempt to hinder bot activity, though through different means. Bad Behavior detects suspicious requests and blocks them, optionally using the Project Honeypot database to improve its effectiveness. Limit Login Attempts will block IP addresses if they continually make incorrect login attempts.

4. CloudFlare

CloudFlare is an interesting service that speeds up your site and mitigates security threats by sitting between the user and your server. You update your domain to point to their servers, and they act similarly to a CDN, caching your site and analyzing the incoming traffic. If you’re running off a cheap shared hosting plan, it could make a significant improvement to your loading speed. I don’t use their services personally, but they’ve been instrumental in mitigating DDoS attacks and traffic spikes for some high-profile sites, and they’re on top of the current WordPress threat.

Apparently Chrome, Safari, Internet Explorer and Opera all have a flaw in their localStorage implementations that allow a website to use a little trick to fill your hard disk up. They allow each subdomain of an origin to have its own storage pool, so you can bypass the quota by looping around and storing data for tons of subdomains. FillDisk manages 1GB per 16 seconds on the author’s MacBook Pro. Firefox gets it right and sets the quota for the entire second-level domain.

Now Mozilla’s solution doesn’t exactly seem optimal to me. There are plenty of sites that allow users to host things on subdomains, GitHub Pages being a noteworthy example. It seems to me that a more equitable solution is to extend the partial solution Firefox implements and prompt the user to allow the pool to be enlarged when needed.

Introducing the HTML5 Hard Disk Filler™ API [Feross.org]

The PHP contributors want to help combat this problem—at least among companies using PHP, obviously the issue is by no means limited to PHP developers—with the new API. A couple of simple functions that even the most novice of developers can use will automatically take care of the hashing using bcrypt with a reasonable work factor.

The proposed syntax is something like this:

//hashing a new password
$hash = password_hash($password_entered);

//Checking a password
if (password_verify($password_entered, $hash_from_database)) {
    //password is valid if password_verify() returns true
}

For compatibility with versions of PHP prior to 5.5, you can even download a PHP implementation that will automatically be disabled in a PHP 5.5 environment.

The new Secure Password Hashing API in PHP 5.5 [GitHub]

That’s not good, however you look at it. While updates to the post explain that it’s not necessarily indicative that Pandora is storing passwords in their database in plaintext—they could just be caching them client-side—it’s definitely in the realm of possibility. Not using a slow one-way hash and this sort of thing tend to go hand in hand.

Given that I was able to see my password, on a new computer I had yet to use Pandora on, with a browser that I had recently cleared of cookies and other local storage, Pandora is most likely storing passwords in plaintext and transmitting them over the internet. (Or, at best, using a two-way encryption scheme, which is little better.)

Pandora doesn’t one-way hash their passwords [Google Plus]

I discovered this by accident when I was leaving a Facebook API example for a commentator, and posted a code snippet that included the <script> tag referencing http://connect.facebook.net/en_US/all.js#xfbml=1. To my surprise, a Facebook Comments widget appeared within my comment!

I did some testing with a fresh WordPress installation and ensured that it wasn’t related to any of my own customizations or installed plugins, and that only high-ranking user accounts could do it.

This could potentially be a Cross-Site Scripting (XSS) vulnerability, as a user with Editor privileges could conceivably “go rogue” and post malicious JavaScript in comment threads. This could be used for any number of nefarious things, such as injecting a malware loader into the page or inserting spam links.

So I did some digging, wondering whether I should report the issue to the core developers, and found this:

Users with Administrator or Editor privileges are allowed to publish unfiltered HTML in post titles, post content, and comments. WordPress is, after all, a publishing tool, and people need to be able to include whatever markup they need to communicate. Users with lesser privileges are not allowed to post unfiltered content.

[…] Regardless, an Administrator has wide-ranging super powers among which unfiltered HTML is a lesser one.

In WordPress multisite, only super administrators can publish unfiltered HTML, as all other users are considered untrusted.

It makes sense that Administrators be able to do that, as they have unfettered control over everything else. (And there are probably some cool things you could do by inserting JavaScript into your comments, like placing polls without having to use a plugin.)

So, the lesson here is to be cautious with who you assign Editor privileges to. If you don’t trust them, don’t give them an Editor account. Besides, a rogue Editor could play havoc on posts and comments even without being able to paste-in malicious code.

Many people commenting on the subject, whether in editorials, podcasts or discussion forums, would bring up the subject of how strong the users’ cracked passwords were. There were a large percentage of users with weak passwords like qwerty, password, 123456, or monkey. Yes, they are obviously weak passwords. However, I think it’s wrong to use them as an example of bad user-end security practices.

I, for one, would never use one of my more secure passwords for an account on a blog or discussion forum. I would be likely to come up with a throwaway that I would never use on a site where I would care if it were compromised. Considering that Gawker’s readers are probably a little more tech-savvy than your grandparents, why assume that they wouldn’t take the same approach? Given Gawker’s security breach, I think it’s a well-justified method to use.

Firesheep is a proof of concept that attempts to demonstrate just how big of a problem popular websites’ lack of HTTPS support is…by making “sidejacking” point-and-click simple. Anyone can install the extension, press a button to automatically scan for active sessions of popular websites being transmitted over the network, and then click on an entry to log in to the user’s account on the website.

What started out as a fairly innocent project demonstrate to websites like Facebook that they should be implementing SSL encryption has become a major security risk. Firesheep has sort of…went viral. A frightening number of people have downloaded the extension.

While developer Eric Butler’s intentions may have been honorable, his extension has had one very negative effect: it has made sidejacking much, much more prevalent. A year ago, I could be fairly sure that nobody on the local McDonalds’ WiFi hotspot would be trying to hijack my Twitter session. After all, I live in a fairly rural state with a low density of exceptionally computer-literate people. Now, some kid could be playing around with Firesheep.

This reminds me of the “grey hat” security researchers. They usually don’t have malicious intentions, but their methods can sometimes cause more harm than good. That seems to be Firesheep in a nutshell. Butler’s follow-up blog posts even read like those of a grey hat hacker.

I think Firesheep is the worst kind of way to promote security. It has done far more harm than good. Sidejacking was a fringe thing that you didn’t really have to worry about, except for higher-risk things like banking or checking your email. Now anyone can install a GUI tool and do it without even knowing how it works. This is going beyond enabling script kiddies. It puts cracker tools in the hands of the masses, therefore making sidejacking an actual risk.

It’s a bit of a pain to set up SSL, but many web hosts will do it for you. WPWebHost, for instance, will configure SSL for you if you get a certificate. They run around $89/year (I know, what a racket…) from most certificate authorities, and some hosts will charge a small set-up fee. VPS.net, on the other hand, has a deal with Comodo where you can get a free SSL certificate as long as you are hosted by them. You have to set everything up on your own, though.

What do you do once you have a security certificate? There’s a Codex article on the subject. There are a couple of WordPress constants in wp-config.php that you can toggle on to force everything in the /wp-admin directory to be served over HTTPS, the login page most importantly.

You probably won’t ever have to worry about this, unless you run a very large blog or you like to work from a coffee shop across the street from a computer security convention. WordPress.com users are lucky; they can just go to https://wordpress.com/wp-login.php to log in securely.

The exploit, in essence, involves capturing a WordPress blog’s database details from wp-config.php by having a hosting account on the same server, and building malicious script to open files outside of the zone that should be permissible. (Think along the lines of ../../other_users_files/wp-config.php.)

Some misinformed publications are claiming that it’s a WordPress vulnerability stemming from wp-config.php’s plain-text storage of  database passwords…something that every database-using script has to do in order to function. Any reversible encryption scheme is just as easily reversible by someone who can access you filesystem, and the one-way hashing used for users’ passwords doesn’t work in this sort of situation. The file should never be directly accessibly by anyone other than the creator on a properly-configured server.

A new post on the WordPress development blog is attempting to clear-up the misunderstanding.