Quantcast
Channel: Neural Core Dump » Webcomics
Viewing all articles
Browse latest Browse all 10

Firesheep, GPF, and Neural Core Dump

0
0

By now, the tech savvy among you have probably heard of Firesheep, the infamous unofficial Firefox plugin that lets you swipe other people’s session cookies and impersonate them on various popular, less-than-secure websites if you and they share the same unencrypted WiFi access point. The less tech savvy ones probably could care less, or are so terrified and spooked that you’ve turned off and unplugged your computers, buried them in a 20-foot-deep hole in the backyard, and layered on top of them concrete, asbestos, Kevlar, lard, and ten thousand old AOL CDs you’ve been hoarding in the closet since 1990.

OK, I was only kidding about the lard.

Last week I tweeted that “Firesheep makes me want to weep for the Internet and laugh maniacally, both simultaneously”. That’s no exaggeration. On one hand, it’s performing wonders by raising awareness of just how insecure many of our favorite sites really are. The problem Firesheep exposes has been around for ages; hard-core hackers could perform all the tasks that this plugin does through readily available tools and a lot of dedicated logging and log scanning. What Firesheep does is take a complicated, hard-core hacker task and make it bone-headedly simple: install, scan, infiltrate. It provides a wake-up call to Web 2.0 developers that they need to look seriously at security rather than just pay it lip service. And at this task it seems to be doing quite well; already Google has made moves to force SSL for all GMail access and Facebook is mumbling under its breath that they’re “looking into it”.

What scares me about Firesheep is the bone-headedly simple aspect. I won’t get into the ethics of responsible disclosure of security flaws, but releasing a tool like this that makes such a questionable task as simple as clicking a button is bound to have repercussions. Putting this tool in the hands of everyone means putting it in the hands of everyone, no matter what color hat they wear. Yes, we’ll hopefully see lots of increase in security at many of the websites we use every day, but how many innocent and ignorant users will be maliciously attacked before those changes occur? The gun was a very useful tool for early pioneers to hunt and protect one’s family, but it’s also useful for criminals to steal, coerce, and murder their victims. Technology is inherently amoral; it is people that are moral or immoral.

I won’t go into the details of how Firesheep works or the many ways it can be easily thwarted. A quick spin by your favorite search engine will likely provide all the information you may need. However, I did want to take a few minutes to publicly analyze the various aspects of this site and the GPF site and reassure all my readers that your information should be reasonably safe. Right now, it looks like the person most likely to be impacted would be me, directly or indirectly, and the risks are actually pretty darn low.

First up, this site: Firesheep does indeed include information on how to “hack” WordPress. Well, how to hack WordPress.com. Since Neural Core Dump is self-hosted, the built-in attack against WordPress.com hosted blogs won’t affect us here. However, Firesheep is open source, so it is trivial to modify the code to attack specific domains, so the WordPress.com attack can be tweaked to attack an individual self-hosted WordPress blog. My original assumptions here proved to be incorrect; in looking back over the the Firesheep code, it doesn’t look specifically for WordPress.com domains, but for common cookie names used by all instances of WordPress, whether it’s self hosted or not. Thus, any logged-in user here could potentially be exposed. In this case However, this blog’s small size becomes its advantage; the likelihood that anyone will directly attack it is pretty low, and even then I keep extensive backups and can easily back out malicious comments or posts. (Mind you, being too small should not be used as an excuse not to be concerned, just that the threat can be downplayed for the time being.) I rarely use public, open WiFi hot spots (to be honest, there aren’t that many of them around where I live), and on the rare case that I do, it’s easy enough for me to create an SSH tunnel to my home Linux box and proxy all my HTTP traffic through it.

As for GPF, all logins occur over SSL, so no passwords are ever sent in the clear. Of course, Firesheep does not sniff passwords but rather session cookies, so this isn’t really the problem. I thought of a few scenarios where Firesheep could be used against GPF to varying degrees of success:

  • Perhaps the most susceptible part of the site is the forum. phpBB uses session cookies like many of the sites targeted by Firesheep, and is thus theoretically vulnerable. However, phpBB forums reside on the domain of the server they are installed upon and the session cookie names are easily configurable. Thus, attacks would have to be directly targeted against a specific site in order to work. Like the blog here, GPF’s relatively low profile makes it unlikely to be targeted, although the possibility exists. Also like the blog, I’m the only one with full admin access, so correcting problems shouldn’t be too difficult. All admin sessions occur entirely over SSL, and even if I check the box to have the browser remember my login, phpBB forces me to authenticate before granting access to the admin interface.
  • The wiki is currently configured (quite accidentally but fortuitously) to always use SSL during and after login. Thus, any session cookies the wiki may set are only sent over SSL and thus can never be sniffed. This is also moot for now since I’m the only one with write access to the wiki, but I’ve been considering giving access to a handful of volunteers to help me maintain it.
  • The GPF Store is configured (quite intentionally) to always use SSL, whether you’re logged in or not.  No vulnerability there.
  • GPF Premium presents two problems: account creation/management and the day-to-day “branding” cookie that enables Premium features.
    • The Account Creator and Account Manager always use SSL and do not use session cookies in any way. Their session data is currently stored in an encrypted, hidden form field on the page.  Since these pages never leave SSL, no information is ever sent in the clear. The weakest point of these systems are the user name and password you set. (You did pick a nice, strong password, didn’t you?)
    • It is theoretically possible for someone to sniff the Premium “branding” and options cookies and thus gain access to Premium features. However, that’s about all they can do: steal Premium access. These cookies do not let them gain access to your account in any way, and making any form of modification to your account requires login via the encrypted Account Manager. No features in Premium currently use these cookies to provide identity information to the system. (I did consider adding a few features that did, but those are all currently scrapped post-Firesheep.) Furthermore, the branding cookie is tied very closely to your individual browser and operating system, and there are safeguards to prevent tampering with the data and modifying it (like pretending to be an Eternal subscriber when the original cookie is really for a Bronze subscriber). The options cookie is useless without the branding cookie. Thus, the only person standing to lose anything from a sniffed Premium banding cookie is me, and that will only last as long as the cookie validates; even if the cookie thief modifies the cookie’s expiration date in the browser, embedded data in the cookie will invalidate it when the expiration date in the cookie data itself is reached.

Again, GPF’s probably far too small a target for anyone to really bother with, but the fact is that so little attack surface is visible that the only person likely to be hurt by it is me.

There, I hope I laid all your GPF/Firesheep fears to rest. What was that? The only person really concerned about this was me? Oh… well, in that case… um… never mind, I guess.

UPDATED November 4, 2010: Updated the paragraph about this blog to correct an incorrect assumption about only WordPress.com blogs being affected.


Viewing all articles
Browse latest Browse all 10

Latest Images

Trending Articles





Latest Images