Tag Archives: Security

What You Need to Know About the Heartbleed Bug

Apr 14, 2014 by Matt | Posted in Hosting 55 Comments

Heartbleed Logo If you haven’t already heard, a major exploit in OpenSSL was discovered recently. The Heartbleed Bug, which is as scary as it sounds, allows an attacker to capture potentially sensitive information from a server’s memory by exploiting a flaw in the implementation of the heartbeat function of OpenSSL’s SSL/TLS implementation.

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.

WordPress Security Advisory: Harden Your Admin Login

Apr 24, 2013 by Matt | Posted in WordPress 3 Comments

There has been news lately of a distributed attack against WordPress sites. A growing botnet has been running dictionary attacks against sites powered by WordPress, in effort to gain access to the the admin panel and infect the server. As is usually the case with botnets, infected servers are assimilated into the pool of compromised systems that make up the botnet and put to use for nefarious purposes such as DDoS attacks.

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.

Continue reading →

FillDisk Proof-of-Concept Demonstrates Flaw in Browsers’ localStorage Implementations

Mar 6, 2013 by Matt | Posted in Software & Scripts No Comments

HTML5’s localStorage API makes it possible for a web page to store 5-10MB of persistent data, much like cookies, but for more complex data—as you probably already know if you’re familiar with HTML5’s fancy new APIs. Feross Aboukhadijeh came up with an interesting and relevant proof-of-concept that’s been making its rounds on the internet: a little something called FillDisk.

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]

Proposed Secure Password Hashing API in PHP 5.5

Oct 17, 2012 by Matt | Posted in Coding No Comments

PHP 5.5 will be gaining a simpler and more newbie-friendly way to securely hash passwords. As those who are active in the PHP community are all to well aware of, it is quite a trial to educate everyone on properly securing passwords in their applications. Even large web companies are routinely outed for their lax measures. Sometimes they’re stored in plain text and sometimes they might as well be, like when weak MD5 or SHA1 hashes are used. Remember the big scandal when Gawker Media’s database of user passwords was leaked, and the weak hashes were solved within days? Or more recently, when it was discovered that Pandora not only stored your password in cleartext, but transmitted it that way as well? It seems that at least two well-known websites have a similar “facepalm” moment every year.

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]

Pandora Password Debacle

Sep 25, 2012 by Matt | Posted in Coding No Comments

There’s a post going around on Google Plus that shows off a glaring security hole in the popular internet radio site Pandora. If you use FireBug (or the HTML inspection tool in your browser of choice), you can see that the Password field on the account settings page clearly shows your password in the value attribute. It displays bullets because it’s a password type form field instead of a plain input, but the password is still right there.

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]

WordPress Admins Can Post JavaScript in Post Comments

Aug 31, 2011 by Matt | Posted in WordPress No Comments

Here’s an interesting fact about WordPress: users with Administrator or Editor privileges are allowed to post unsanitized JavaScript or markup in Post comments.

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.

What Everyone Missed About the Gawker Password Scandal

Jan 10, 2011 by Matt | Posted in Internet 2 Comments

A few weeks ago the internet exploded with news about the servers that host the Gawker blogs (Gizmodo, Lifehacker, Jezebel, etc.) being compromised by a distributed group of crackers known as Gnosis. Though the attack itself was covered fairly well by various tech publications (and less so by the traditional media, as usual), there was a recurring theme that just seems wrong…

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: Grey Hat Security?

Nov 8, 2010 by Matt | Posted in General 7 Comments

A scary new Firefox extension known as Firesheep came onto the scene recently. For years it has been possible for nefarious users to “sniff” unencrypted network packets for session cookies, allowing them to, with a bit of work, hijack your session with a website. This would enable them full access to, say, your email or Facebook account until you log out and destroy the session. This is probably the biggest security risk on a public WiFi hotspot, though until now it was fairly unlikely that you would happen to be on the same network as a nefarious user with the technical chops to pull it off. Until now.

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.

WordPress Administration Over SSL

Jul 16, 2010 by Matt | Posted in WordPress 2 Comments

Do you frequently log-in to your WordPress install over public WiFi networks? While it may seem like paranoia to some people, it’s really not a good idea to log into important sites over an unencrypted connection. There’s always a possibility that someone could be packet sniffing. If you run a high-profile blog, you might want to consider acquiring an SSL certificate. (A certificate is a sort of public key used to establish an encrypted connection.) With a certificate, you can log into WordPress with an HTTPS connection. This encrypts traffic between you and your server, making it impossible for anybody to intercept your password while you work from a café.

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.

It’s a Hosting Issue, Not a WordPress One

Apr 16, 2010 by Matt | Posted in WordPress One Comment

There has been some misinformation going around about an alleged security vulnerability in WordPress 2.9.2. A bunch of websites were recently compromised, and some people have tried to assign the blame to WordPress. The issue, however, comes from shared web hosts not taking the proper precautions to prevent users from accessing configuration files they shouldn’t have filesystem permissions for.

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.