FYI, Hacker News is susceptible too.
Firesheep, Week+ later
11–20 of 22 posts
Re: Firesheep, Week+ later
#12At least one site, GitHub, has certainly deployed changes as a result (and also pointed out that the author of Firesheep gave absolutely zero warning to the sites it targeted, which unnecessarily left a great many users vulnerable on sites like GitHub that would have otherwise been able to close the hole before Firesheep made it public information).
They're now SSL only: http://twitter.com/#!/github/statuses/29534618326
Re: Firesheep, Week+ later
#13Aye Aye Aye deal with it dude, quit whining. Use a good VPN and you dont have to worry!
www.web-privacy.edu.tc
Re: Firesheep, Week+ later
#14At least one site, GitHub, has certainly deployed changes as a result (and also pointed out that the author of Firesheep gave absolutely zero warning to the sites it targeted, which unnecessarily left a great many users vulnerable on sites like GitHub that would have otherwise been able to close the hole before Firesheep made it public information).
unnecessarily left a great many users vulnerable on sites
Except that Firesheep didn't expose any new security problem. "Hey everyone, in a few weeks I'm going to make it easier for people to exploit long-known security problems that you may have been happily ignoring" is different to "Hey everyone, I found a brand new vulnerability and I want to let you fix it before I publish it".
Re: Firesheep, Week+ later
#15At least one site, GitHub, has certainly deployed changes as a result (and also pointed out that the author of Firesheep gave absolutely zero warning to the sites it targeted, which unnecessarily left a great many users vulnerable on sites like GitHub that would have otherwise been able to close the hole before Firesheep made it public information).
unnecessarily left a great many users vulnerable on sites Except that Firesheep didn't expose any new security problem. "Hey everyone, in a few weeks I'm going to make it easier for people to exploit long-known security problems that you may have been happily ignoring" is different to "Hey everyone, I found a brand new vulnerability and I want to let you fix it before I publish it".
Yes, the problem was known before-hand by security researchers and a number of other people involved in web development. That doesn't mean it was known to users or to the developers of GitHub. In fact, given the fast response by GitHub and the tweet by pjhyett (http://twitter.com/#!/pjhyett/status/28924943340), it definitely appears that the GitHub team were not aware of this issue prior to the release of Firesheep. In any case, the release of Firesheep dramatically increased the likelyhood of this particular hole being exploited in the wild. The responsible action would have been for the author of Firesheep to notify the targeted sites about this hole with a reasonable delay before releasing the tool. His point would have still been made, but the sites that were willing to fix this would have been able to put a fix in place before users were unnecessarily left exposed.
Re: Firesheep, Week+ later
#16Earlier quoted context omitted.
unnecessarily left a great many users vulnerable on sites Except that Firesheep didn't expose any new security problem. "Hey everyone, in a few weeks I'm going to make it easier for people to exploit long-known security problems that you may have been happily ignoring" is different to "Hey everyone, I found a brand new vulnerability and I want to let you fix it before I publish it".
Yes, the problem was known before-hand by security researchers and a number of other people involved in web development. That doesn't mean it was known to users or to the developers of GitHub. In fact, given the fast response by GitHub and the tweet by pjhyett ( http://twitter.com/#!/pjhyett/status/28924943340 ), it definitely appears that the GitHub team were not aware of this issue prior to the release of Firesheep…
I'm sorry, but this is a cop-out. Even five minutes of thought on how you authenticate your users would have shown that it depends on one string being a secret. Most people acknowledge that passwords shouldn't be passed in the clear. So what's the difference between a password and a session cookie in terms of its sensitivity. This is security 101. I think its highly irresponsible, and a disservice to users of all web applications, to suggest that this is new in any sense.
And, in a practical sense, who would you have expected the creators of firesheep to have warned? The top100 sites? the top500? At what point should github have entered the list? Again, this is not a vulnerability in a specific app, its a well known design error.
Re: Firesheep, Week+ later
#17Earlier quoted context omitted.
Yes, the problem was known before-hand by security researchers and a number of other people involved in web development. That doesn't mean it was known to users or to the developers of GitHub. In fact, given the fast response by GitHub and the tweet by pjhyett ( http://twitter.com/#!/pjhyett/status/28924943340 ), it definitely appears that the GitHub team were not aware of this issue prior to the release of Firesheep…
I'm sorry, but this is a cop-out. Even five minutes of thought on how you authenticate your users would have shown that it depends on one string being a secret. Most people acknowledge that passwords shouldn't be passed in the clear. So what's the difference between a password and a session cookie in terms of its sensitivity. This is security 101. I think its highly irresponsible, and a disservice to users of all web…
The vulnerability is wide-spread, but Firesheep was released with handlers written targeting specific sites, including GitHub.
So, yes, I would have appreciated a heads up from those guys.
Re: Firesheep, Week+ later
#18maybe because it's not a new threat and it's not their responsibility?
I agree with this. How is it facebook's responsibility if the user's wireless network is unprotected? Of course the companies are silent. It's not their vulnerability and it's nothing new, it's been like that since forever. Encrypting all traffic for them is expensive and breaks functionality. What are they supposed to say, to warn users? Something along the lines of: "Warning, HTTP session hijacking has become REAL USER FRIENDLY recently."
Re: Firesheep, Week+ later
#19This security-hole is for people surfing unencrypted networks. There are warnings you get from windows when you connect to such a network. I can assume OSX does the same.
The ferret and hamster tools did the same thing, just not packaged as an extension for firefox, and that was over three years ago. Just needed to find the cmd windows, run two programs, change your proxy and you're set.
See: http://erratasec.blogspot.com/2007/08/sidejacking-with-hamst...
Also how would you warn the right users? You don't know which of them are affected or at risk for this issue. Maybe promote http://hotspotshield.com/ or a similar product.
Lastly, if your on a unencrypted wifi network you're vulnerable to a lot more attacks than the firesheep one. So please don't assume that just using ssl is enough to protect you. One example: http://forums.remote-exploit.org/tutorials-guides/3157-ssl-s...
Re: Firesheep, Week+ later
#20This security-hole is for people surfing unencrypted networks. There are warnings you get from windows when you connect to such a network. I can assume OSX does the same. The ferret and hamster tools did the same thing, just not packaged as an extension for firefox, and that was over three years ago. Just needed to find the cmd windows, run two programs, change your proxy and you're set. See: http://erratasec.blogspo…
"This security-hole is for people surfing unencrypted networks."
I wish that was correct; however, according to http://www.airtightnetworks.com/WPA2-Hole196 even WPA2 is vulnerable. It states: "AirTight Networks uncovered a weakness in the WPA2 protocol, which was documented but buried on the last line on page 196 of the 1232-page IEEE 802.11 Standard (Revision, 2007). Thus, the moniker "Hole196". [...] Exploiting the vulnerability, an insider (authorized user) can sniff and decrypt data from other authorized users as well as scan their Wi-Fi devices for vulnerabilities, install malware and possibly compromise those devices. In short, this vulnerability means that inter-user data privacy among authorized users is inherently absent over the air in a WPA2-secured network."
The only prerequisite is for the attacker to be same WPA secured wireless network as the victim. There are ways to accomplish that even for private WiFi.
WEP has been cracked a long time ago. So, no actual security over WiFi alone. Need to use SSL, VPN, etc. for everything.