Firesheep demonstrates how ineffective Web security is
October 24, 2010 8:24 PM Subscribe
“When it comes to user privacy, SSL is the elephant in the room.” Meet Firesheep: a Firefox plugin that sniffs out unencrypted HTTP sessions on your network segment and lets you impersonate any of the users found. Eric Butler unveiled it today at Toorcon 12, a San Diego conference on computing security, and it demonstrates what amounts to a gaping hole in the Web security model.
Really good point. I've actually experimented with doing this very thing, albeit using more tedious methods (Ethereal and editing cookie files).
posted by weston at 8:41 PM on October 24, 2010
posted by weston at 8:41 PM on October 24, 2010
I've actually experimented with doing this very thing, albeit using more tedious methods (Ethereal and editing cookie files).
And there's the rub. Developers (myself included) often know about this problem but don't feel any urgency to solve it. After all, it takes a bit of effort to capture/analyze/exploit the problem, which makes actually attacks rare (outside of DEF CON). And what's the payoff? The ability to post shit to your roommate's Facebook account.
But now there's a plugin with a slick GUI... time to buy more SSL certificates.
posted by sbutler at 8:46 PM on October 24, 2010
And there's the rub. Developers (myself included) often know about this problem but don't feel any urgency to solve it. After all, it takes a bit of effort to capture/analyze/exploit the problem, which makes actually attacks rare (outside of DEF CON). And what's the payoff? The ability to post shit to your roommate's Facebook account.
But now there's a plugin with a slick GUI... time to buy more SSL certificates.
posted by sbutler at 8:46 PM on October 24, 2010
sbutler: "time to buy more SSL certificates."
Startcom offers them for free, if you're fine with a cert that only involves individuals.
posted by pwnguin at 9:02 PM on October 24, 2010 [4 favorites]
Startcom offers them for free, if you're fine with a cert that only involves individuals.
posted by pwnguin at 9:02 PM on October 24, 2010 [4 favorites]
Basically sites should be using proper RFC2965 cookies with the port attribute specified. In this way, compliant browsers will not send the cookie if the web developer blundered and sent the user to a port 80 URL (http:) rather than a port 443 URL (https:). It also won't send it when the user reaches the host by some other means, such as via a bookmark or hand-typing a URL.
posted by George_Spiggott at 9:22 PM on October 24, 2010 [5 favorites]
posted by George_Spiggott at 9:22 PM on October 24, 2010 [5 favorites]
There are still people using non-switched Ethernet or switches dumb enough to fall prey to ARP table overflow attacks? I suppose it's true that half my clients don't have their router in a secure location, so it would be trivial to do an MITM attack, but by the same token they'd notice the extra stuff plugged in and ask me about it.
posted by wierdo at 9:24 PM on October 24, 2010
posted by wierdo at 9:24 PM on October 24, 2010
George_Spiggott wrote: "It also won't send it when the user reaches the host by some other means, such as via a bookmark or hand-typing a URL."
That seems unnecessary, but maybe I'm not thinking it all the way through...
(sorry for the two in a row..didn't preview)
posted by wierdo at 9:26 PM on October 24, 2010
That seems unnecessary, but maybe I'm not thinking it all the way through...
(sorry for the two in a row..didn't preview)
posted by wierdo at 9:26 PM on October 24, 2010
Wierdo: WiFi is open so this attach would work well at any public hotspot.
posted by cftarnas at 9:29 PM on October 24, 2010
posted by cftarnas at 9:29 PM on October 24, 2010
By "open" I mean all packets sent are open to inspection by anyone.
posted by cftarnas at 9:30 PM on October 24, 2010
posted by cftarnas at 9:30 PM on October 24, 2010
In this way, compliant browsers will not send the cookie if the web developer blundered and sent the user to a port 80 URL (http:) rather than a port 443 URL (https:).
There's already the 'secured' flag for cookies... but re-read the post. The problem is with developers only using SSL for the authentication phase, unsecured otherwise.
It also won't send it when the user reaches the host by some other means, such as via a bookmark or hand-typing a URL.
No popular site is going to do things this way. It's also unclear to me that not explicitly specifying 80/443 in the URL will keep all browsers from sending the cookie anyway.
There are still people using non-switched Ethernet or switches dumb enough to fall prey to ARP table overflow attacks?
Think: cafe/hotel wireless, or other places that are usually unsecured. That's really the largest target for this kind of mischief IMHO. And WEP won't save you from this, and there's a recent flaw in WPA that is pretty serious.
so it would be trivial to do an MITM attack
This has nothing to do with MITM.
posted by sbutler at 9:32 PM on October 24, 2010 [2 favorites]
There's already the 'secured' flag for cookies... but re-read the post. The problem is with developers only using SSL for the authentication phase, unsecured otherwise.
It also won't send it when the user reaches the host by some other means, such as via a bookmark or hand-typing a URL.
No popular site is going to do things this way. It's also unclear to me that not explicitly specifying 80/443 in the URL will keep all browsers from sending the cookie anyway.
There are still people using non-switched Ethernet or switches dumb enough to fall prey to ARP table overflow attacks?
Think: cafe/hotel wireless, or other places that are usually unsecured. That's really the largest target for this kind of mischief IMHO. And WEP won't save you from this, and there's a recent flaw in WPA that is pretty serious.
so it would be trivial to do an MITM attack
This has nothing to do with MITM.
posted by sbutler at 9:32 PM on October 24, 2010 [2 favorites]
It's kind of funny that to download a plugin that demonstrates a huge security vulnerability, it looks like you go to a random website and install random software.
Does Mozilla vet plugins?
posted by meowzilla at 9:58 PM on October 24, 2010
Does Mozilla vet plugins?
posted by meowzilla at 9:58 PM on October 24, 2010
No, you're thinking of Apple.
posted by klangklangston at 10:21 PM on October 24, 2010 [2 favorites]
posted by klangklangston at 10:21 PM on October 24, 2010 [2 favorites]
I get "Backend exited with error 1" whenever I try to run Firesheep in Firefox 3.6.11 on Windows 7 x64. I did install Winpcap...
posted by killdevil at 10:50 PM on October 24, 2010
posted by killdevil at 10:50 PM on October 24, 2010
For laughs, I tried this out, opening Facebook in Chrome whilst running Firesheep in Firefox. My account picture and name show up in Firesheep, but double-clicking brings up Facebook's authentication page. I also tried placing an order with the captured Amazon data and I had to enter authentication info.
At first I was really worried, but my own testing cannot get me into Facebook or allow me to place orders as "myself-as-someone-else-within-Firesheep".
Is this is a real issue and just a bug with the plug-in, or is this something people don't need to worry about, because sites have figured out how to get around this?
posted by Blazecock Pileon at 11:14 PM on October 24, 2010
At first I was really worried, but my own testing cannot get me into Facebook or allow me to place orders as "myself-as-someone-else-within-Firesheep".
Is this is a real issue and just a bug with the plug-in, or is this something people don't need to worry about, because sites have figured out how to get around this?
posted by Blazecock Pileon at 11:14 PM on October 24, 2010
Same with Google. It captures some kind of Google token, but the token doesn't appear to grant access to any of my Google account data.
posted by Blazecock Pileon at 11:16 PM on October 24, 2010
posted by Blazecock Pileon at 11:16 PM on October 24, 2010
Interesting, BP. Check based on the user agent signature, maybe?
posted by weston at 11:19 PM on October 24, 2010
posted by weston at 11:19 PM on October 24, 2010
https-everywhere is worth installing in your browser, if you use firefox. It makes sure common sites that provide https also (such as facebook and google) only use the https port.
posted by winjer at 11:45 PM on October 24, 2010 [14 favorites]
posted by winjer at 11:45 PM on October 24, 2010 [14 favorites]
Interesting, BP. Check based on the user agent signature, maybe?
To test this, I installed a user-agent switcher in Chrome and was able to reload Facebook between agent changes, without having to re-authenticate. I don't think that's it.
posted by Blazecock Pileon at 11:55 PM on October 24, 2010
To test this, I installed a user-agent switcher in Chrome and was able to reload Facebook between agent changes, without having to re-authenticate. I don't think that's it.
posted by Blazecock Pileon at 11:55 PM on October 24, 2010
Or maybe the user-agent switcher just doesn't work. The extension didn't get very good reviews.
posted by Blazecock Pileon at 11:56 PM on October 24, 2010
posted by Blazecock Pileon at 11:56 PM on October 24, 2010
Hmm. Just tried the same thing using Safari's developer menu, and changing my UA to IE8 doesn't make Facebook blink.
posted by weston at 12:09 AM on October 25, 2010
posted by weston at 12:09 AM on October 25, 2010
There are still people using non-switched Ethernet or switches dumb enough to fall prey to ARP table overflow attacks? I suppose it's true that half my clients don't have their router in a secure location, so it would be trivial to do an MITM attack, but by the same token they'd notice the extra stuff plugged in and ask me about it.
That's what I used to think until someone started using cain&abel on my network. Basically, they don't attack the arp tables on the switches; they attack the clients. It sends out arp broadcasts to the clients telling them your attacking pc is now the server you're interested in; and they happily send you all the traffic and the switches happily comply. You listen in, and then forward it to the real server, and nobody is any the wiser except maybe things slow down a bit if you're overambitious in how much traffic you try to listen in to at once. It then gives you all the passwords it got that were in the clear (imap is a favourite), and has built in cracking against older login systems - including the ability to tell both sides of a windows client/server login to fall back to non-ntlmv2 auth - which they will do unless you've told the servers not to specifically...
There are two main defences; manual static arp tables on all your switches (huge PITA), or private vlans (with appropriate IP ranges per vlan) talking to a layer 3 router - the private vlan stops them spoofing each other on the segment, and obviously the layer 3 stops them talking to anything outside their segment because ARP broadcasts aren't normally routed.
Switched networks alone through are not a defence to ARP MITM attacks.
That said, I don't think this attack (firesheep) is using arp spoofing. If used on an open wifi point, everything is broadcast in the clear anyway, so you just sit there with your wifi card in promiscuous mode and capture everything - encrypted stuff is worthless, but all the http traffic is easily captured. Presumably it also works on a WEP/WPA network if you either also have the key, or are able to crack it.
I don't have time to test it this morning, I'll try it out later and see what happens.
posted by ArkhanJG at 12:33 AM on October 25, 2010 [5 favorites]
That's what I used to think until someone started using cain&abel on my network. Basically, they don't attack the arp tables on the switches; they attack the clients. It sends out arp broadcasts to the clients telling them your attacking pc is now the server you're interested in; and they happily send you all the traffic and the switches happily comply. You listen in, and then forward it to the real server, and nobody is any the wiser except maybe things slow down a bit if you're overambitious in how much traffic you try to listen in to at once. It then gives you all the passwords it got that were in the clear (imap is a favourite), and has built in cracking against older login systems - including the ability to tell both sides of a windows client/server login to fall back to non-ntlmv2 auth - which they will do unless you've told the servers not to specifically...
There are two main defences; manual static arp tables on all your switches (huge PITA), or private vlans (with appropriate IP ranges per vlan) talking to a layer 3 router - the private vlan stops them spoofing each other on the segment, and obviously the layer 3 stops them talking to anything outside their segment because ARP broadcasts aren't normally routed.
Switched networks alone through are not a defence to ARP MITM attacks.
That said, I don't think this attack (firesheep) is using arp spoofing. If used on an open wifi point, everything is broadcast in the clear anyway, so you just sit there with your wifi card in promiscuous mode and capture everything - encrypted stuff is worthless, but all the http traffic is easily captured. Presumably it also works on a WEP/WPA network if you either also have the key, or are able to crack it.
I don't have time to test it this morning, I'll try it out later and see what happens.
posted by ArkhanJG at 12:33 AM on October 25, 2010 [5 favorites]
Windows version doesn't work for me (same error as killdevil), and there's no Linux version, so my plans to play confusing tricks on my wife in the next room have come to nothing, alas...
posted by Jimbob at 4:23 AM on October 25, 2010
posted by Jimbob at 4:23 AM on October 25, 2010
Hmm, so it turns out "sidejacking" totally doesn't mean what you would expect it to mean. Keep up the good work on those neologisms, computer nerds.
posted by indubitable at 5:17 AM on October 25, 2010
posted by indubitable at 5:17 AM on October 25, 2010
I get "Backend exited with error 1"
I too get this. Usually after a good curry.
posted by srboisvert at 7:03 AM on October 25, 2010 [4 favorites]
I too get this. Usually after a good curry.
posted by srboisvert at 7:03 AM on October 25, 2010 [4 favorites]
I'm sure it's a wonderful tool but it seems limited in which versions of Firefox it's compatable with. Which doesn't include FF 3.5.9/OSX or apparently FF4. Freeware, you get what you pay for.
posted by scalefree at 7:18 AM on October 25, 2010
posted by scalefree at 7:18 AM on October 25, 2010
So this only works with unencrypted login pages. I have actually gotten into heated arguments at work about this, as I work in the financial industry and the bevy of unsecure login pages for financial websites drives me up a fucking wall.
Don't give people keys if the locks are attached to the doors with staples.
posted by Civil_Disobedient at 7:33 AM on October 25, 2010
Don't give people keys if the locks are attached to the doors with staples.
posted by Civil_Disobedient at 7:33 AM on October 25, 2010
WEP will keep me safe!
You're being sarcastic, right?
posted by kbanas at 8:15 AM on October 25, 2010
You're being sarcastic, right?
posted by kbanas at 8:15 AM on October 25, 2010
If you're at a wifi hotspot and you're not running all your traffic through an encrypted tunnel to a host you can trust, you're doing it wrong.
posted by flabdablet at 8:17 AM on October 25, 2010
posted by flabdablet at 8:17 AM on October 25, 2010
If you pass authentication cookies in the clear, it can be captured and subsequently used in another browser. The cookie itself is all you need to be logged in to a site. Sniffing the line/wireless doesn't require capturing the user name or password. I haven't taken a look into firesheep yet, but the cookies on most sites store your username/id in the cookie itself and from there it's pretty easy to map back to your picture.
There are a few techniques that make cookie capture/replay a bit more difficult, such as: associating the cookie to a specific browser User Agent, associating it an IP, issuing a separate cookie for https, ... etc.
Unfortunately some of these are not practical. Associating to a User Agent means that on every browser update the cookie expires, plus the User Agent is in the clear anyway and can also be spoofed. Associating it with an IP is problematic, since there are large NAT instances and several ISPs like to randomly re-assign an IP, plus in this particular case you're already on the same network segment as the attacker and will most likely be using the same outbound gateway. Issuing a separate cookie for https works, in that it would most likely protect any configuration settings for your account, but you still have many "critical" user actions on sites (ie commenting) that wouldn't normally use https.
Switching everything to use SSL likely isn't practical. For any sizable site, you'd need an SSL accelerator card on each server in order to handle the load. The set up/tear down of SSL connections is still a fairly expensive operation.
In short, they've greatly simplified a known practice.
posted by o0o0o at 8:35 AM on October 25, 2010
There are a few techniques that make cookie capture/replay a bit more difficult, such as: associating the cookie to a specific browser User Agent, associating it an IP, issuing a separate cookie for https, ... etc.
Unfortunately some of these are not practical. Associating to a User Agent means that on every browser update the cookie expires, plus the User Agent is in the clear anyway and can also be spoofed. Associating it with an IP is problematic, since there are large NAT instances and several ISPs like to randomly re-assign an IP, plus in this particular case you're already on the same network segment as the attacker and will most likely be using the same outbound gateway. Issuing a separate cookie for https works, in that it would most likely protect any configuration settings for your account, but you still have many "critical" user actions on sites (ie commenting) that wouldn't normally use https.
Switching everything to use SSL likely isn't practical. For any sizable site, you'd need an SSL accelerator card on each server in order to handle the load. The set up/tear down of SSL connections is still a fairly expensive operation.
In short, they've greatly simplified a known practice.
posted by o0o0o at 8:35 AM on October 25, 2010
Just want to point out the possible merits of Firefox extension Force TLS. This extension will force the site you are talking to to use HTTPS, which will require your attacker to do some arpspoofing to make their sslstrip script work and...oops. I've said too much.
Joking aside, stuff like this is how security moves forward - sure, this type of attack is trivial for anyone who knows a few things about computer security. But now that this attack has been automated into something as simple as a firefox extension, actual people (instead of just security experts) might start to demand increased security measures.
posted by antonymous at 8:42 AM on October 25, 2010
Joking aside, stuff like this is how security moves forward - sure, this type of attack is trivial for anyone who knows a few things about computer security. But now that this attack has been automated into something as simple as a firefox extension, actual people (instead of just security experts) might start to demand increased security measures.
posted by antonymous at 8:42 AM on October 25, 2010
There's also a firefox extension created by the EFF called HTTPS Everywhere which will do the same thing as the extension I linked to above, but you can sleep better at night knowing you're using a tool provided by the EFF, you dirty dirty hippies.
posted by antonymous at 8:52 AM on October 25, 2010
posted by antonymous at 8:52 AM on October 25, 2010
I was under the impression that SSL handshakes and end-to-end encryption were expensive.
Google Techie Person Analysis of SSL load...
But it appears that may not be the case for most modern hardware.
posted by bastionofsanity at 8:59 AM on October 25, 2010 [2 favorites]
Google Techie Person Analysis of SSL load...
But it appears that may not be the case for most modern hardware.
posted by bastionofsanity at 8:59 AM on October 25, 2010 [2 favorites]
There are still people using non-switched Ethernet or switches dumb enough to fall prey to ARP table overflow attacks?
Bees are on the what now?
posted by Skot at 9:47 AM on October 25, 2010
Bees are on the what now?
posted by Skot at 9:47 AM on October 25, 2010
I was under the impression that SSL handshakes and end-to-end encryption were expensive ... But it appears that may not be the case for most modern hardware.
It still is right now. However it may be less expensive in the future with both client and server side updates to the handshake and session re-establishment processes. It will be a few more years before this is baked into everything.
posted by o0o0o at 10:14 AM on October 25, 2010
It still is right now. However it may be less expensive in the future with both client and server side updates to the handshake and session re-establishment processes. It will be a few more years before this is baked into everything.
posted by o0o0o at 10:14 AM on October 25, 2010
"WiFi is open so this attach would work well at any public hotspot."
A lot of the cookies that would be most problematic would be time-sensitive, though, right?! (i.e. It will allow you to be someone else for a rather limited amount of time... probably only while they are still around aforementioned hotspot.)
The biggest threat I see with Firesheep has nothing specifically to do with whether someone can impersonate you on Facebook, but rather, if they can use the knowledge this app gives them to access someone's email, determine their existing passwords, or modify Firesheep itself so it becomes less of an example of what this technique can do on some social networking sites, and more of a tool to go after people where they're *really* vulnerable. Depending on the particular sites in question, I suppose someone could "log in" as someone else, change the email address for their account to one they control, and then perhaps have an email sent to them that would allow them to reset the password, or, more dangerously, actually be notified of what their password actually is.
At that point, you'd likely have their email service, and, quite likely, a password that would work on it. From there, it's a relatively small step to get access to their online banking, PayPal, etc.
I used to help run LJ years ago, and we *hated* those times when people were obviously using cookie exploits to gain access to people's accounts. It usually required someone actually having access to someone else's system, though, and it was usually pretty clear who was doing the abusing. Despite time-sensitive cookies, though, Firesheep does make all of that time-consuming sysadmin drama into a very easy-to-do, rather anonymous exploit.
Would not want to be handling the security for one of these sites right about now...
posted by markkraft at 10:40 AM on October 25, 2010
A lot of the cookies that would be most problematic would be time-sensitive, though, right?! (i.e. It will allow you to be someone else for a rather limited amount of time... probably only while they are still around aforementioned hotspot.)
The biggest threat I see with Firesheep has nothing specifically to do with whether someone can impersonate you on Facebook, but rather, if they can use the knowledge this app gives them to access someone's email, determine their existing passwords, or modify Firesheep itself so it becomes less of an example of what this technique can do on some social networking sites, and more of a tool to go after people where they're *really* vulnerable. Depending on the particular sites in question, I suppose someone could "log in" as someone else, change the email address for their account to one they control, and then perhaps have an email sent to them that would allow them to reset the password, or, more dangerously, actually be notified of what their password actually is.
At that point, you'd likely have their email service, and, quite likely, a password that would work on it. From there, it's a relatively small step to get access to their online banking, PayPal, etc.
I used to help run LJ years ago, and we *hated* those times when people were obviously using cookie exploits to gain access to people's accounts. It usually required someone actually having access to someone else's system, though, and it was usually pretty clear who was doing the abusing. Despite time-sensitive cookies, though, Firesheep does make all of that time-consuming sysadmin drama into a very easy-to-do, rather anonymous exploit.
Would not want to be handling the security for one of these sites right about now...
posted by markkraft at 10:40 AM on October 25, 2010
If you're using WPA-PSK and think you're protected from a tool like this, guess again.
posted by cellphone at 10:48 AM on October 25, 2010
posted by cellphone at 10:48 AM on October 25, 2010
That said, if there's one "saving grace" for the people running online communities today, it's that the level of support you can expect to get from them nowadays if your account gets hijacked, well... it's probably going to be little more than a form letter. You're basically on your own, regardless of the fundamental insecurity of using their sites.
This will be especially true once people start making tools like FireSheep into wifi parlour games.
posted by markkraft at 11:03 AM on October 25, 2010
This will be especially true once people start making tools like FireSheep into wifi parlour games.
posted by markkraft at 11:03 AM on October 25, 2010
So this only works with unencrypted login pages. I have actually gotten into heated arguments at work about this, as I work in the financial industry and the bevy of unsecure login pages for financial websites drives me up a fucking wall.
No, it works with sites where the login page is encrypted, but subsequent page views, including the session cookie, are unencrypted. Like Metafilter, for instance.
(For what it's worth, it looks like GMail now defaults to always using HTTPS. I don't know if this applies to other Google services.)
It seems like a pretty useful tool to me — not because this was hard before, but because it makes it very clear to people what is possible. I think many knowledgeable users are aware that people can see what they are doing on an open wifi network unless they are going to an HTTPS site. But what is not at all obvious, unless you are a web developer or otherwise someone who spends time thinking about how cookies work, is that seeing what you're doing means being able to steal your session at all kinds of sites — even those with an HTTPS login. There are a lot of people who don't care if people watch what they are doing on Facebook at the coffeeshop but care very much if someone starts posting status updates using their account.
posted by enn at 11:04 AM on October 25, 2010 [1 favorite]
No, it works with sites where the login page is encrypted, but subsequent page views, including the session cookie, are unencrypted. Like Metafilter, for instance.
(For what it's worth, it looks like GMail now defaults to always using HTTPS. I don't know if this applies to other Google services.)
It seems like a pretty useful tool to me — not because this was hard before, but because it makes it very clear to people what is possible. I think many knowledgeable users are aware that people can see what they are doing on an open wifi network unless they are going to an HTTPS site. But what is not at all obvious, unless you are a web developer or otherwise someone who spends time thinking about how cookies work, is that seeing what you're doing means being able to steal your session at all kinds of sites — even those with an HTTPS login. There are a lot of people who don't care if people watch what they are doing on Facebook at the coffeeshop but care very much if someone starts posting status updates using their account.
posted by enn at 11:04 AM on October 25, 2010 [1 favorite]
Civil_Disobedient: So this only works with unencrypted login pages.
No, it doesn't care if the login pages are encrypted or not; it steals cookies from non-encrypted traffic after the target logs in. Read the article.
posted by ericost at 11:05 AM on October 25, 2010 [1 favorite]
No, it doesn't care if the login pages are encrypted or not; it steals cookies from non-encrypted traffic after the target logs in. Read the article.
posted by ericost at 11:05 AM on October 25, 2010 [1 favorite]
"sure, this type of attack is trivial for anyone who knows a few things about computer security"
I wouldn't say "trivial" exactly, in that your standard script kiddie wouldn't know how to do it. What I am concerned about, really, is whether that's the case after today...
NPR did a story on this kind of exploit awhile back. Interestingly enough, it found that the most common profile for those who used the exploit for criminal gain were overseas CS students in the US, who have been having a harder time finding work, and who pay higher tuitions to go to college.
posted by markkraft at 11:13 AM on October 25, 2010
I wouldn't say "trivial" exactly, in that your standard script kiddie wouldn't know how to do it. What I am concerned about, really, is whether that's the case after today...
NPR did a story on this kind of exploit awhile back. Interestingly enough, it found that the most common profile for those who used the exploit for criminal gain were overseas CS students in the US, who have been having a harder time finding work, and who pay higher tuitions to go to college.
posted by markkraft at 11:13 AM on October 25, 2010
"seeing what you're doing means being able to steal your session at all kinds of sites — even those with an HTTPS login"
... which is why FireSheep is designed to only let people steal sessions on a certain limited collection of social networking sites, presumably.
That said, people hack software all the time. How hard will it be for someone to figure out how to modify FireSheep to, indeed, steal sessions at basically any site?
I understand the justification for creating this tool, but that doesn't mean it's not damn dangerous and quite possibly misguided, because the solution will not be a quick, easy one.
In fact, it could also really hurt the idea of free, anonymous WiFi, because if the options are exposing all your users to potential harm -- and your company to possible liability -- or pulling the plug, well...
Hm. We'll have to see how this plays out.
posted by markkraft at 11:22 AM on October 25, 2010
... which is why FireSheep is designed to only let people steal sessions on a certain limited collection of social networking sites, presumably.
That said, people hack software all the time. How hard will it be for someone to figure out how to modify FireSheep to, indeed, steal sessions at basically any site?
I understand the justification for creating this tool, but that doesn't mean it's not damn dangerous and quite possibly misguided, because the solution will not be a quick, easy one.
In fact, it could also really hurt the idea of free, anonymous WiFi, because if the options are exposing all your users to potential harm -- and your company to possible liability -- or pulling the plug, well...
Hm. We'll have to see how this plays out.
posted by markkraft at 11:22 AM on October 25, 2010
I wouldn't say "trivial" exactly, in that your standard script kiddie wouldn't know how to do it.
Sure he would. Piece together the other guy's HTTP stream with Wireshark, find the cookie header, use one of the Firefox cookie editing plugins to spoof it. You don't need to know how to write code or much about security — you just need minimal knowledge of the HTTP protocol, and not very much of that. It's certainly well within reach of anyone who knows how to run Aircrack.
posted by enn at 11:28 AM on October 25, 2010
Sure he would. Piece together the other guy's HTTP stream with Wireshark, find the cookie header, use one of the Firefox cookie editing plugins to spoof it. You don't need to know how to write code or much about security — you just need minimal knowledge of the HTTP protocol, and not very much of that. It's certainly well within reach of anyone who knows how to run Aircrack.
posted by enn at 11:28 AM on October 25, 2010
Really it should all be encrypted. HTTPS's overhead is not as bad as people think.
posted by cftarnas at 11:51 AM on October 25, 2010
posted by cftarnas at 11:51 AM on October 25, 2010
No, it works with sites where the login page is encrypted, but subsequent page views
Well sure, that makes sense since the cookie is in the http-request. I guess I was a little shocked that you would have an encrypted login page but redirect to a non-SSL after-the-fact, as if that solved anything.
A huge part of this problem is with the browser writers and their half-assed implementation of caching. The assumption they make is that everything in an http request w/ssl requires encryption, when in fact most things don't. But even when you explicitly set the expiration & cache-control headers, it's often ignored by the browser if it sees HTTPS (actually what happens varies between browsers and even versions). So everything has to get downloaded every request, which is slow as dogshit, which makes people think SSL is inherently slow, causing website operators to find all manner of ways to get around using SSL.
posted by Civil_Disobedient at 12:06 PM on October 25, 2010 [2 favorites]
Well sure, that makes sense since the cookie is in the http-request. I guess I was a little shocked that you would have an encrypted login page but redirect to a non-SSL after-the-fact, as if that solved anything.
A huge part of this problem is with the browser writers and their half-assed implementation of caching. The assumption they make is that everything in an http request w/ssl requires encryption, when in fact most things don't. But even when you explicitly set the expiration & cache-control headers, it's often ignored by the browser if it sees HTTPS (actually what happens varies between browsers and even versions). So everything has to get downloaded every request, which is slow as dogshit, which makes people think SSL is inherently slow, causing website operators to find all manner of ways to get around using SSL.
posted by Civil_Disobedient at 12:06 PM on October 25, 2010 [2 favorites]
Does Firesheep work?
posted by Blazecock Pileon at 1:24 PM on October 25, 2010
posted by Blazecock Pileon at 1:24 PM on October 25, 2010
Does Firesheep work?
It's a little picky about which versions of Firefox it installs with, but once you find one it likes (FF 3.6.11 on OSX 10.5.8 for me) it works just like it says. Point, click, steal.
posted by scalefree at 1:56 PM on October 25, 2010
It's a little picky about which versions of Firefox it installs with, but once you find one it likes (FF 3.6.11 on OSX 10.5.8 for me) it works just like it says. Point, click, steal.
posted by scalefree at 1:56 PM on October 25, 2010
I was under the impression that SSL handshakes and end-to-end encryption were expensive.
Oh man this reminds me of how I was shopping for reagents for lab in grad school online in the late 1990s and the Merck website forced everything (EVERYTHING) through SSL. It was so painfully slow that I was ready to fill out an order form by hand and hunt down a fax machine.
posted by exogenous at 2:11 PM on October 25, 2010
Oh man this reminds me of how I was shopping for reagents for lab in grad school online in the late 1990s and the Merck website forced everything (EVERYTHING) through SSL. It was so painfully slow that I was ready to fill out an order form by hand and hunt down a fax machine.
posted by exogenous at 2:11 PM on October 25, 2010
"The reason it focuses on specific sites, rather than work as a generic tool is because its purpose is publicity and effectiveness."
I absolutely agree. That said, it clearly, visibly simplifies an exploit in a way that might easily change the environment for not only security, but for free wifi -- and for those who might seek to exploit it.
I support the goal... but it really isn't going to be an easy, quick fix... and meanwhile, it makes it dead simple for anyone to exploit pretty much anyone else.
You're right that it does change the assumption that anyone can do this crap. But the fact is, most people didn't bother... even script kiddies. As I pointed out previously, the people who were the criminal exploiters of this tended to have a higher level of computer savvy.
Yes... the reality was that anyone who wanted to put their mind to it could do the exploit. There really are few exploits that aren't trivial, to those who are willing to read a few pages of text and follow directions. My concern, however, is that by making this exploit blindingly simple, many more people will, in fact, do it.
Yes, security is nice. But anonymous, ubiquitous WiFi is nice too... and arguably of more value to me. And, let's face it, this country (and its businesses) has a history of hysteric overreaction -- as opposed to effective action -- when it comes to anything having to do with perceived lack of security.
Hopefully, there won't have to be too many more costly sacrifices made, as a result.
posted by markkraft at 2:17 PM on October 25, 2010
I absolutely agree. That said, it clearly, visibly simplifies an exploit in a way that might easily change the environment for not only security, but for free wifi -- and for those who might seek to exploit it.
I support the goal... but it really isn't going to be an easy, quick fix... and meanwhile, it makes it dead simple for anyone to exploit pretty much anyone else.
You're right that it does change the assumption that anyone can do this crap. But the fact is, most people didn't bother... even script kiddies. As I pointed out previously, the people who were the criminal exploiters of this tended to have a higher level of computer savvy.
Yes... the reality was that anyone who wanted to put their mind to it could do the exploit. There really are few exploits that aren't trivial, to those who are willing to read a few pages of text and follow directions. My concern, however, is that by making this exploit blindingly simple, many more people will, in fact, do it.
Yes, security is nice. But anonymous, ubiquitous WiFi is nice too... and arguably of more value to me. And, let's face it, this country (and its businesses) has a history of hysteric overreaction -- as opposed to effective action -- when it comes to anything having to do with perceived lack of security.
Hopefully, there won't have to be too many more costly sacrifices made, as a result.
posted by markkraft at 2:17 PM on October 25, 2010
Exactly.
posted by Civil_Disobedient at 2:29 PM on October 25, 2010
posted by Civil_Disobedient at 2:29 PM on October 25, 2010
Rats, I meant "exactly" to exogenous's comment about slow browsing. If you didn't have to download every image, external CSS file, javascript file, and HTML document every stinkin' request it would have been a lot faster.
posted by Civil_Disobedient at 2:30 PM on October 25, 2010
posted by Civil_Disobedient at 2:30 PM on October 25, 2010
Just read the following regarding FireSheep's default design of allowing people to only see other's sessions on a limited collection of social networking sites...
"that’s just the default setting— anyone can write their own plugins, according to the post."
...because it was clearly too hard for those with malicious intent to hack the code and add it otherwise?!
Yeah, I understand those of you who might want visibility for this problem. But what if your visibility comes at the price of someone else's victimization?!
So... is this is why we can't have nice things?!
posted by markkraft at 2:44 PM on October 25, 2010
"that’s just the default setting— anyone can write their own plugins, according to the post."
...because it was clearly too hard for those with malicious intent to hack the code and add it otherwise?!
Yeah, I understand those of you who might want visibility for this problem. But what if your visibility comes at the price of someone else's victimization?!
So... is this is why we can't have nice things?!
posted by markkraft at 2:44 PM on October 25, 2010
I already knew I was depriving myself of some kind of globalised virtual connectedness and I still don't want to join, but browsing friends who aren't email conversation people and scattered across the globe but whether if it's rural Vietnam or Berlin or a cottage in Serbia with a river toilet or whatever, fucking posting from there, was sweet.
posted by yoHighness at 5:02 PM on October 25, 2010
posted by yoHighness at 5:02 PM on October 25, 2010
Firesheep apparently requires an Intel-based Mac. (Still in the PowerPC dark ages here).
posted by spock at 5:15 PM on October 25, 2010
posted by spock at 5:15 PM on October 25, 2010
It appears you have stumbled upon the age old argument over full disclosure of security issues, markkraft.
posted by wierdo at 8:34 PM on October 25, 2010
posted by wierdo at 8:34 PM on October 25, 2010
Um... no. I was fully aware of such things when I helped run a major open source project, thanks.
Surprisingly enough, you can fully disclose how simple it can be to violate a security issue, without releasing an easily customizable piece of software to the wild that enables unprecedentedly easy identity theft.
...perhaps you can't distinguish the difference anymore?!
posted by markkraft at 10:19 PM on October 25, 2010
Surprisingly enough, you can fully disclose how simple it can be to violate a security issue, without releasing an easily customizable piece of software to the wild that enables unprecedentedly easy identity theft.
...perhaps you can't distinguish the difference anymore?!
posted by markkraft at 10:19 PM on October 25, 2010
Mere disclosure wasn't sufficient. This is the next step.
posted by ryanrs at 11:01 PM on October 25, 2010
posted by ryanrs at 11:01 PM on October 25, 2010
"Mere disclosure wasn't sufficient. This is the next step."
Love to. How about Global Thermonuclear War?
posted by markkraft at 3:20 AM on October 26, 2010
GREETINGS, PROFESSOR FALKEN.
SHALL WE PLAY A GAME?Love to. How about Global Thermonuclear War?
WOULDN"T YOU PREFER A GOOD GAME OF CHESS?posted by markkraft at 3:20 AM on October 26, 2010
markkraft wrote: "Surprisingly enough, you can fully disclose how simple it can be to violate a security issue, without releasing an easily customizable piece of software to the wild that enables unprecedentedly easy identity theft."
It's not as if it's been previously unknown how easy it is to steal cookies and thus web logins. Since the authors of web apps have refused to do anything about it for quite some time now, I don't think it's particularly unreasonable for an exploit to be disclosed so as to spur action.
As you can tell, I'm one of those who thinks that if software authors refuse to cooperate with fixing their security issues, after being given reasonable time to fix them, it's time to kick them in the pants and get them to fix their shit. What I don't agree with is releasing an exploit publicly before giving the author a chance to fix the problem and release a patch.
posted by wierdo at 5:56 AM on October 26, 2010 [1 favorite]
It's not as if it's been previously unknown how easy it is to steal cookies and thus web logins. Since the authors of web apps have refused to do anything about it for quite some time now, I don't think it's particularly unreasonable for an exploit to be disclosed so as to spur action.
As you can tell, I'm one of those who thinks that if software authors refuse to cooperate with fixing their security issues, after being given reasonable time to fix them, it's time to kick them in the pants and get them to fix their shit. What I don't agree with is releasing an exploit publicly before giving the author a chance to fix the problem and release a patch.
posted by wierdo at 5:56 AM on October 26, 2010 [1 favorite]
"Since the authors of web apps have refused to do anything about it"
...we should punish the users?!
The simple fact is, for most people, when it comes to security, the only thing standing between their ability to stay financially secure or not is basically the information they have locked away in their email account. And if you can break into their other accounts, their email is likely to be pretty easy to get access to, even if it is protected from this particular exploit.
I think this piece of software would've been a great thing to show, certainly... and to make online videos of. And to release, in demo'y, limited form, to numerous people in the security industry, technology journalists, various dotcoms, etc. Hell, the programmer could've even threatened a future public release, if people didn't start acting to address the problem.
But the fact remains that even Facebook, that huge behemoth that is specifically targeted by this app, is only talking about being able to have a fix in one or two months. That's a HUGE security and privacy vulnerability to expose millions of people to.
In point-of-fact, it is quite likely an illegal act to have released this software. Meanwhile, they're now reporting that this app has been downloaded over 100,000 times in the last 24 hours alone.
What's going to happen? Financial pain. People having their online accounts deleted, their email hacked, their bank accounts drained and locked down, unable to pay rents and mortgages and groceries. The shutting down of free, anonymous WiFi sites, only to reopen as for-pay, locked down, non-anonymous WiFi... and instead of reasonable action, a completely destructive overreaction. Tens of millions of dollars in "year 2K" style overpriced contractors, expensive emergency expenditures, the mandating of security efforts to fix this, even though we, as a society, will have been better off beforehand by being insecure, in a relatively low-key way... and then, a short time later, we'll be rendered insecure by something else, I suspect.
The simple fact is, a potential short-term gain in computer security is not so valuable as to justify thousands of other's hardship and misery. This ain't the Donald Rumsfeld School of Computer Science we're talking about here... and the people who are going to suffer certainly didn't sign up for this. "The ends don't justify the means", y'know?!
Openness does not have to become an extremist ideological position that supports criminality and malicious intent. We should be careful not to make it one.
posted by markkraft at 7:57 AM on October 26, 2010
...we should punish the users?!
The simple fact is, for most people, when it comes to security, the only thing standing between their ability to stay financially secure or not is basically the information they have locked away in their email account. And if you can break into their other accounts, their email is likely to be pretty easy to get access to, even if it is protected from this particular exploit.
I think this piece of software would've been a great thing to show, certainly... and to make online videos of. And to release, in demo'y, limited form, to numerous people in the security industry, technology journalists, various dotcoms, etc. Hell, the programmer could've even threatened a future public release, if people didn't start acting to address the problem.
But the fact remains that even Facebook, that huge behemoth that is specifically targeted by this app, is only talking about being able to have a fix in one or two months. That's a HUGE security and privacy vulnerability to expose millions of people to.
In point-of-fact, it is quite likely an illegal act to have released this software. Meanwhile, they're now reporting that this app has been downloaded over 100,000 times in the last 24 hours alone.
What's going to happen? Financial pain. People having their online accounts deleted, their email hacked, their bank accounts drained and locked down, unable to pay rents and mortgages and groceries. The shutting down of free, anonymous WiFi sites, only to reopen as for-pay, locked down, non-anonymous WiFi... and instead of reasonable action, a completely destructive overreaction. Tens of millions of dollars in "year 2K" style overpriced contractors, expensive emergency expenditures, the mandating of security efforts to fix this, even though we, as a society, will have been better off beforehand by being insecure, in a relatively low-key way... and then, a short time later, we'll be rendered insecure by something else, I suspect.
The simple fact is, a potential short-term gain in computer security is not so valuable as to justify thousands of other's hardship and misery. This ain't the Donald Rumsfeld School of Computer Science we're talking about here... and the people who are going to suffer certainly didn't sign up for this. "The ends don't justify the means", y'know?!
Openness does not have to become an extremist ideological position that supports criminality and malicious intent. We should be careful not to make it one.
posted by markkraft at 7:57 AM on October 26, 2010
As has been pointed out repeatedly, it's not as if this is some novel exploit that hasn't been known. Nefarious folks have been able to do this for years, yet nothing has been done. I guess we should just continue to leave the users to the wolves out of the fear of script kiddies?
Thankfully, I don't have to worry about some jackass getting control of my email, and even if I did, none of my banks are stupid enough to send me authentication credentials over email. I don't use the webmail package my users do, but it has been protected against this sort of thing through source IP verification and user agent verification for at least 5 years.
I guess the question becomes how long should full disclosure wait? There will always be morons who never patch. Shall we wait on them also? Sometimes more than a mere threat is needed to get action. Microsoft was, until recently, the poster child for this. They wouldn't do jack shit to address security vulnerabilities until there was an exploit circulating in the wild. In the more distant past, Cisco also behaved that way, along with thousands of other companies that refuse to expend any effort on security.
Users are not being punished any more than before, as now that the vulnerability is widely known, they can make an informed decision to not use broken websites until they get fixed. I think that keeping everybody in the dark is helping these companies that refuse to fix their security issues at the expense of users.
posted by wierdo at 8:21 AM on October 26, 2010
Thankfully, I don't have to worry about some jackass getting control of my email, and even if I did, none of my banks are stupid enough to send me authentication credentials over email. I don't use the webmail package my users do, but it has been protected against this sort of thing through source IP verification and user agent verification for at least 5 years.
I guess the question becomes how long should full disclosure wait? There will always be morons who never patch. Shall we wait on them also? Sometimes more than a mere threat is needed to get action. Microsoft was, until recently, the poster child for this. They wouldn't do jack shit to address security vulnerabilities until there was an exploit circulating in the wild. In the more distant past, Cisco also behaved that way, along with thousands of other companies that refuse to expend any effort on security.
Users are not being punished any more than before, as now that the vulnerability is widely known, they can make an informed decision to not use broken websites until they get fixed. I think that keeping everybody in the dark is helping these companies that refuse to fix their security issues at the expense of users.
posted by wierdo at 8:21 AM on October 26, 2010
Come to think of it, I wrote something like this in 1998. The ethernet ports in my dorm building were misconfigured and everyone's traffic was visible to everyone else (like a hub). This was not fixed even after I complained. So I wrote a program that showed a running log of everyone's unencrypted web usage, both URLs and cookies. Because IPs were assigned in sequential order, it was easy to show the room number next to each URL.
I sent my script to the IT security people. As I recall, I framed it not as a threat, but as an tipoff: "Psst, hey guys, people on my floor are using this to spy on each other! Can you do something?"
The IT guys fixed the switch configuration the same day.
Moral of the story: nothing motivates security like an exploit.
posted by ryanrs at 8:49 PM on October 27, 2010
I sent my script to the IT security people. As I recall, I framed it not as a threat, but as an tipoff: "Psst, hey guys, people on my floor are using this to spy on each other! Can you do something?"
The IT guys fixed the switch configuration the same day.
Moral of the story: nothing motivates security like an exploit.
posted by ryanrs at 8:49 PM on October 27, 2010
His heart is in the right place : Fireshepard crashes Firesheep with floods of nonsense packets.
Meanwhile, Idiocy "is designed to warn people of the risks they're taking on public wifi networks. While quietly running in the background Idiocy watches for people visiting Twitter insecurely, hijacks the session and posts a tweet warning them that they are vulnerable, with a link to a page explaining what has happened." "I browsed twitter insecurely on a public network and all I got was this lousy tweet. http://jonty.co.uk/idiocy-what" .... which, when you get down to it, isn't all that fair to the people it takes advantage of. It's twitter that should be the one who sets up the ssl connection and keeps it up, not the user.
posted by crunchland at 2:12 PM on October 29, 2010
Meanwhile, Idiocy "is designed to warn people of the risks they're taking on public wifi networks. While quietly running in the background Idiocy watches for people visiting Twitter insecurely, hijacks the session and posts a tweet warning them that they are vulnerable, with a link to a page explaining what has happened." "I browsed twitter insecurely on a public network and all I got was this lousy tweet. http://jonty.co.uk/idiocy-what" .... which, when you get down to it, isn't all that fair to the people it takes advantage of. It's twitter that should be the one who sets up the ssl connection and keeps it up, not the user.
posted by crunchland at 2:12 PM on October 29, 2010
« Older Roller derby has its policy debate moment | On the interface of the two cultures of modern... Newer »
This thread has been archived and is closed to new comments
posted by Artw at 8:34 PM on October 24, 2010 [4 favorites]