Nice. 
I'm willing to bet that a lot of Facebook and Twitter users will be coming out of the closet in the near future... 
That said, I'd want to carefully glance over the code before running it. 
It's extremely common for websites to protect your password by encrypting the initial login, but surprisingly uncommon for websites to encrypt everything else. This leaves the cookie (and the user) vulnerable. HTTP session hijacking (sometimes called "sidejacking") is when an attacker gets a hold of a user's cookie, allowing them to do anything the user can do on a particular website. On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy.
After installing the extension you'll see a new sidebar. Connect to any busy open wifi network and click the big "Start Capturing" button. Then wait.
As soon as anyone on the network visits an insecure website known to Firesheep, their name and photo will be displayed:
Double-click on someone, and you're instantly logged in as them.
That's it.
Firesheep is free, open source, and is available now for Mac OS X and Windows. Linux support is on the way.
http://codebutler.com/firesheep
Unfortunately, my laptop runs Linux, so I can't try it out for myself yet...
]]>Interesting, indeed. I'll test it tonight ^^
]]>I would hope that this is common knowledge by now...
]]>It's not new, no, but it's never been this user friendly.
]]>I've not used public WiFi for a while for this reason (not because of Firesheep but because of traffic sniffing), I use private 3G connections instead...
]]>I only use public wifi if I can proxy via a SSH tunnel to my home network.
]]>Nice. I'm willing to bet that a lot of Facebook and Twitter users will be coming out of the closet in the near future...
That said, I'd want to carefully glance over the code before running it.
I'd try it, but I don't think WKU would like it if I sniffed around on their network.
]]>I'm willing to bet that a lot of Facebook and Twitter users will be coming out of the closet in the near future...
What? You mean we'll see a lot more of:
<real owner posts something debatable here>
<haxx0r posts this>
"HAHAHA! Disregard that, I sxxk cxxxs!"?
What? You mean we'll see a lot more of...
That, but also a more blunt approach... I know that when in college there was at least one instance where a student had forgotten to log off before leaving a computer lab and another user sent the entire school (students, faculty, etc.) an E-mail from his account confessing to being homosexual (using mailing lists). It looked sincere until it was recanted a few hours later from the same account. It was pretty hilarious for everyone (except for maybe the victim). 
It was also a lesson to the entire school to not leave your computer logged in and unattended; and to remember to log out before leaving.
I have a colleague that always does that (actually, most probably do, but I notice because her screen faces the door ) regularly at j0rb and I always have to fight the urge to change her home page to www.companynamesucks.com[1].
** APPEND **
Take a look at their list of affected sites:
http://github.com/codebutler/firesheep/wiki/Handlers
Wha..? Where's A.cc on that list?
]]>Take a look at their list of affected sites:
Every site that uses cookies without HTTPS will be affected, so the length of their list is only surprising in its sparseness.
]]>Not if you tie the session cookie to other information, such as the client's IP address. Unless both the attacker and the legit user are behind the same router, this should be pretty hard to spoof - but then the downside is that you will be logged out as soon as you're on a different network or your DHCP resets.
]]>Unless both the attacker and the legit user are behind the same router, this should be pretty hard to spoof
If you both are connected to the same unsecured WLAN (which is required for this exploit), you will very likely have the same external IP as well.
]]>If you both are connected to the same unsecured WLAN (which is required for this exploit), you will very likely have the same external IP as well.
Uhm, but then what's the problem? Logging into anything unsecured on any public network is like asking for problems.
]]>Uhm, but then what's the problem? Logging into anything unsecured on any public network is like asking for problems.
Exactly. This isn't a new exploit. It's just been made a LOT easier for people to use it.
]]>That's just what the OP said in his second post.
Brats.
]]>Every site that uses cookies without HTTPS will be affected, so the length of their list is only surprising in its sparseness.
Well they're targeting the masses so they're specifically adding support for popular social networking sites and sales companies and financial companies and the like. Besides, it isn't really a big deal if somebody manages to hijack your Allegro.cc session. The amount of harm they can do is limited. They can post as you, edit your most recent posts, modify your profile or settings, but the worst that they can possibly do is get you banned by ML. Well, they could also learn your real name if you entered it in A.cc and have been keeping it a secret. Most of the regulars have revealed their alleged names anyway.
It matters more on sites like Facebook and Twitter and PayPal where you have a lot of your information and a lot of your information is shared with others (some of which might even know you 
), as well as their information being shared with you. Access to somebody's Facebook account could easily open the door for social mayhem or even social engineering. Not to mention all of the personal information that the idiots of the world share with Facebook. It's a pretty serious thing for it to get hijacked. Albeit, it doesn't really matter because those same idiots have already installed "applications" that steal all of their information and sell it...
In any case, many sites just don't need that level of security because there isn't much to benefit from hijacking somebody's account (though you could still get a laugh out of it).
]]>Well, Firesheep broke the tabloid headline threshold in Finland.
]]>Seriously, isn't this "exploit" like 10 years old? O.o
What is the big deal?
]]>What is the big deal?
That the average Joe will be able to perform the attack.
]]>That the average Joe will be able to perform the attack.
The "average Joe" has no reason to do the attack, except to a) see if it works or perhaps b) goof with his "friend's" Facebook status.
The person who would actually do something bad with such a tool already knew how to do this, and probably already had his own tools that do the same thing.
]]>^++
]]>Hehe -> Idiocy tool.
]]>The significance of Firesheep isn't the danger of attack (which has always been there), but the potential awareness that users (and victims) can gain from it. While Idiocy does have the potential to be a little bit more educational for victims, it will probably be used less often because there isn't much in it for the attacker. Besides, many users will probably just think "oh well, doesn't hurt me" and go on with their day. Firesheep can hurt them and the "attackers" will probably install it with intent to do "harm", even if it's childish harm.
It matters more on sites like Facebook and Twitter and PayPal where you have a lot of your information
Wait... PayPal? It's impossible to do anything on there without HTTPS, just like most other financial sites who are even remotely intelligent.
]]>Wait... PayPal? It's impossible to do anything on there without HTTPS, just like most other financial sites who are even remotely intelligent.
That's what I had assumed... It's on their list though so maybe they know something we don't. It's possible that PayPal does non-financial/non-administrative operations over plain HTTP, but that seems risky and silly when you already have the security layer (obviously resources like images are fine over HTTP, but things like scripts and actually server-communication should be over HTTPS)... I think cookies would differ between HTTP and HTTPS sites (as the port would be different) so I don't think cookies would be shared between them. I could be wrong. PayPal is listed as one of the "incomplete" sites so maybe they're just calling out names.
It's now hit the local free newspaper ("Extra Östergötland") as well, with some wonderful sensationalism.
Are cookies readable from any website?
]]>Also front page of Stockholm Metro today. "FIRESHEEP WILL STEAL YOUR FACEBOOK PASSWORDS!!!111" (paraphrased).
]]>Well, I always use the https firefox plug and one that disables/protects cookies where possible.
Surely the likes of facebook/twitter would be encrypting the cookies and storing the main details in a database, as well as doing the usual stuff like id regeneration?
]]>If browsers allow any cookies to be read from any site, then the spec is already broken - it's a design flaw.
]]>Surely the likes of facebook/twitter would be encrypting the cookies and storing the main details in a database, as well as doing the usual stuff like id regeneration?
Cookies are sent in the headers of your HTTP request with Facebook. It doesn't really matter if the cookie is "encrypted" or not if the connection itself isn't because the information in the cookie isn't actually interesting (usually). What is useful is that Facebook (and all Web sites) identify user sessions by the cookie, which means that if you have the cookie to send to Facebook then as far as Facebook knows you are on that user session and can do anything that user can do. I don't have a Facebook account, but IIRC most of the pages are not over HTTPS though. Probably just the login process. In other words, you can't encrypt just the cookie (you can, but it wouldn't do any good). You can either encrypt the entire connection or accept hijacking.
If browsers allow any cookies to be read from any site, then the spec is already broken - it's a design flaw.
Cookies aren't so much "read" by Web sites as they are sent with HTTP requests in the headers. The beginning of every HTTP request has a header with the basic request information/protocol stuff followed by `name: value` lines. Cookies that match the host's domain or IP (however you are accessing the host) are sent with the request.
JavaScript, which runs client-side, can read cookies, but it only has access to cookies for its same domain. If the <script> tag is inline then it will be for the HTML document that it's embedded in. If the <script> tag is remote (i.e., src attribute) then I think that it applies to whatever host the script was fetched from. I haven't personally confirmed this though.
]]>The only real stopping point for HTTPS is the IP cost of some hosts. Once we are in a position where the folk who don't use HTTPS because it would double their hosting bill for the IP address is when this won't be an issue any more.
]]>The only real stopping point for HTTPS is the IP cost of some hosts. Once we are in a position where the folk who don't use HTTPS because it would double their hosting bill for the IP address is when this won't be an issue any more.
An extra IP address with my (our) host is only $1/month... Then again, if you encrypt your entire site then you only need one (albeit, the bandwidth costs to encrypt images and the like would probably be more than the cost of an extra IP).
]]>Also, HTTPS supposedly supports virtual hosting now. So you should be able to get a https/ssl key from your hosting provider that you can use without having to get a second IP.
Of course some old clients might not support that, but how many people here want to support browsers like IE6?
According to info gathered from various sites, Firesheep uses the winpcap library to sniff packets coming through the wi-fi network.
Firesheep reads the cookies sent by the browser to the target site and then uses them for accessing the accounts of the target site.
This means that any account where cookies are used for authentication can be compromised.
According to the info, this is a well known attack method known as session hijacking. Firesheep's originality is that it's the first program to allow any user to do it with a click of a button.
The web will not be secure until everything is encrypted, including DNS requests (of course). But this is something that will never happen, not because of cost (after all, if something is so important, hardware can be made specifically for that; graphics accelerators, for example), but because the authorities will lose the capability to eavesdrop the general public.
]]>How much is the cost of the plan you're on?
Also, I know of a host that doesn't offer static IPs (and by extension HTTPS) because of the fact IPv4 is running out of room.
[edit]
Of course some old clients might not support that, but how many people here want to support browsers like IE6?
And Windows XP users running Chrome, Safari, IE7 and IE8
]]>Seems the affordable private servers are sold out. 
How much is the cost of the plan you're on?
We have the $80/mo plan. With a ram upgrade.
]]>Are cookies readable from any website?
No. Cookies are always restricted by the top level domain. Optionally they can be restricted by path or sub-domain. You can also limit a cookie to only be set via SSL.
]]>you could guard against this without having to ssl every page by:
A) Having the user only use a single tab and do ajax for all page requests, probably implement your own javascript window manager and task bar like a web app so they can still browse multiple pages at once within a page.
Share a secret in the SSL reply to successful login that sets this up, a secret key that is used as a seed to a psuedo random number generator which is submitted with each page requests (as a cookie or a GET variable or whatever). The server stays in sync with a session variable to check if it is valid or not.
Snooping attacker can read your details but cannot form a valid reply.
An issue here is that the browsers rand() and the servers are likely to be different, plus the server must cache the state of it in session variable. This means you will have to implement your own PRNG in both server-side scripting and javascript, which is easy and fast.
B) An improvement that would allow multiple browser tabs would be if you can set javascript cookies that do not get sent to the server that could be used as a point of synchronization between all pages, or even more effectively by embedding a flash object that uses flash cookies and the external-interface api to act as a local storage engine for the javascript.
You'd still need to either have every link call a javascript function that blocks until it gets auth code and then modifies request and allows page to send and load, or instead prerequest one for each different link at page load and preset them to their own code, and the server tests if the code is within the next or previous 9,001 cycles of the PRNG for example, but will never accept the same code twice, to allow someone to not have to maybe wait at opening a new page and still open many links in new tabs for a new page even after its been sitting there for a few minutes (if all on same page used same preload value, only first would load a page the rest would be denied).
Each page has a javascript function and embedded flash object, javascript function onload disables all links replaced with a function that pops an alert saying "please enable flash or wait for flash object to initialize!" and then the flash object in frame 1 reads its flash cookie if it exists and then calls a JavaScript callback function to re-enable all linsk with future auth codes that it provides as an array argument.
The ssl login page would serve the initial seed value as a value of <input hidden or a hard coded return value of js function, that the flash object within that page would call when it's ready and set the flash cookie and then use js api to forward this intermediate "please wait" page to the success homepage or user control page or something.
Bullet Proof.
]]>Regarding ^ these lies, if unencrypted, anything you send between client and server is known to the attacker. That includes Flash communication. In theory, you can come up with your own PRNG that is the same between client and server, but you'd have to ensure that both client and server have the same inputs (seeds), which is no easy task. More than likely, whatever algorithm you use would be discoverable by an attacker using the system or by analyzing traffic. And anyway for all intents and purposes it's just reinventing the square wheel. It's encryption. Instead of a secret key you have a secret algorithm. You might as well just rely on SSL, which is tried and tested, instead of relying on your homebrew attempt at security which is likely nowhere near as sophisticated as the standards trusted by the rest of the planet. 
All of that is before accepting that not all clients have JavaScript/Flash. I hate sites that are crippled without them. So fucking annoying. 
Reports have been trickling in that Microsoft’s anti-virus software is now detecting Firesheep as a threat, despite the fact that Firesheep poses absolutely no threat to the integrity of the system it’s installed on, and as mentioned earlier, has many legitimate uses. By installing anti-virus, you grant a third party the ability to remove files from your system trusting that only malicious code will be targeted. Microsoft and other anti-virus vendors abuse this trust and assert what they think you should or should not be doing with your computer. This is dangerous, but unfortunately not unprecedented.
http://codebutler.com/firesheep-a-week-later-ethics-and-legality?c=1
]]>I thought this video from the minecraft thread was rather apt:
Not only does it have Firesheep, it has Firepigs[1]
Where do you think I got the link?
All of the cookie hash is used in every login, it's not some secure table?
Append:
Ah, the whole cookie is transfered unencrypted?
Ah, the whole cookie is transfered unencrypted?
If http is used, nothing in the headers is encrypted. If https (ssl) is used, then everything is encrypted including the headers.
]]>Lemme guess, SSL is more computational power consuming, and it's often vital for the servers? 