7 ms·

What can an end user do to minimize this? This exploit is for insecure Wifi networks- so only using encrypted Wi-fi or Ethernet would seem to remove this attac

What can an end user do to minimize this? This exploit is for insecure Wifi networks- so only using encrypted Wi-fi or Ethernet would seem to remove this attack vector. Is there a real risk that someone (besides the government) can see your cookie?

bluesmoon 16y ago
vpn/ssh tunnel/encrypted wifi
- chrisbroadfoot 16y ago
  Encrypted WiFi won't stop clients on the network from sniffing your packets. It will, however, stop unauthorised computers from sniffing any network data.
  - gojomo 16y ago
    I would have expected each wireless client, on an encrypted network, to negotiate its own key with the access point -- so you'd only see neighbors' traffic if the access point chose to rebroadcast it to you. Are you sure that neither WEP nor WPA/WPA2 do it this way?
    - chrisbroadfoot 16y ago
      The encryption is between your client and the AP. Uaually everything after that is standard IP.
      - gojomo 16y ago
        That's what I thought -- enough to protect against fellow wireless sharers, but not the hosting establishment or path through their ISP to a website.
        chrisbroadfoot 16y ago
        No, you misunderstood. It's enough to protect you against random people sniffing wireless packets. Not other people that are on your network.
        gojomo 16y ago
        Your terminology "the network" or "your network" is still unclear; encryption to the AP could be unique per wireless network client, or not. If it is unique per client -- and it is my belief that recent standards, like WPA2 at least, provide this -- then casual passive eavesdropping by other wireless clients (as with the FireSheep tool) is thwarted. (And that's what most people are most concerned about.) Are you suggesting that no generation of WEP or WPA protects against other authorized wireless users of the same AP, because they're "on your network"? [rewritten completely to seek clarification]
        bluesmoon 16y ago
        WPA enterprise allows a separate (changing) key for each user, typically what you get from an RSA token. Once it gets to the AP, it's then clear text (assuming HTTP) over the rest of the internet until it hits your (HTTP) service provider. If you have control over the internet between the AP and your server, then you're safe. If you don't, then how safe you are depends on how much you can trust the owner of each router along the way. In general, you should be okay, except that every now and then you might end up on an untrusted router, and it's then game over.
        barfoomoo 16y ago
        Sorry, did not follow this part - "Not other people that are on your network.". Care to elaborate?
wwortiz 16y ago
Is there a real risk that someone (besides the government) can see your cookie? Yes, if you login and your cookie is sniffed and spoofed then basically you just allowed the attacker to login as you at the same time. Minimizing it is a little bit different: you can use a secure proxy/tunnel, you can limit your unencrypted wireless activity, you can make sure that sites that should be SSL encrypted are (stripping SSL is common when password sniffing) and you can avoid these services while on open wifi networks.
amanuel 16y ago
logging out will cause the captured sessions to be useless. So remember to logout. VPN is really the best overall option.
- cdine 16y ago
  Most sites don't properly invalidate sessions when you log out, you can't protect yourself as well as you think. See our slide on this topic: http://codebutler.github.com/firesheep/tc12/#18 http://codebutler.github.com/firesheep/tc12/#18
  - amanuel 16y ago
    Excellent points on the slideshow. The general lack of care on this topic among web companies is worrisome.
- tswicegood 16y ago
  That assumes the session is killed on logout. I know from first-hand experience that at least one version of Merb didn't do that. I hacked a pretty popular geo-socially site by grabbing the session cookie and playing around, then logging out. Was still able check-in after I had logged out and for good measure verified that my session was still valid after changing the password. I assume they were using the default sessions setup so I guess it expired. Didn't keep it around to see how long it stayed around. On reporting it, the response was essentially, "oh you didn't have to go to that much trouble, you could have just used your user/pass from curl…" Completely obvious to the fact that they're app/site was completely vulnerable to session hijacking. One of the problems of app frameworks, if you don't know what they're doing (and more importantly, not doing) you can get yourself in a heap of trouble before you even realize there's an issue. But boy, you sure can make it to market fast. shakes head
- phamilton 16y ago
  Just tried it with iGoogle Logging out doesn't kill the session.

bluesmoon 16y ago

vpn/ssh tunnel/encrypted wifi

chrisbroadfoot 16y ago
Encrypted WiFi won't stop clients on the network from sniffing your packets. It will, however, stop unauthorised computers from sniffing any network data.
- gojomo 16y ago
  I would have expected each wireless client, on an encrypted network, to negotiate its own key with the access point -- so you'd only see neighbors' traffic if the access point chose to rebroadcast it to you. Are you sure that neither WEP nor WPA/WPA2 do it this way?
  - chrisbroadfoot 16y ago
    The encryption is between your client and the AP. Uaually everything after that is standard IP.
    - gojomo 16y ago
      That's what I thought -- enough to protect against fellow wireless sharers, but not the hosting establishment or path through their ISP to a website.
      - chrisbroadfoot 16y ago
        No, you misunderstood. It's enough to protect you against random people sniffing wireless packets. Not other people that are on your network.
        gojomo 16y ago
        Your terminology "the network" or "your network" is still unclear; encryption to the AP could be unique per wireless network client, or not. If it is unique per client -- and it is my belief that recent standards, like WPA2 at least, provide this -- then casual passive eavesdropping by other wireless clients (as with the FireSheep tool) is thwarted. (And that's what most people are most concerned about.) Are you suggesting that no generation of WEP or WPA protects against other authorized wireless users of the same AP, because they're "on your network"? [rewritten completely to seek clarification]
        bluesmoon 16y ago
        WPA enterprise allows a separate (changing) key for each user, typically what you get from an RSA token. Once it gets to the AP, it's then clear text (assuming HTTP) over the rest of the internet until it hits your (HTTP) service provider. If you have control over the internet between the AP and your server, then you're safe. If you don't, then how safe you are depends on how much you can trust the owner of each router along the way. In general, you should be okay, except that every now and then you might end up on an untrusted router, and it's then game over.
        barfoomoo 16y ago
        Sorry, did not follow this part - "Not other people that are on your network.". Care to elaborate?

wwortiz 16y ago

Is there a real risk that someone (besides the government) can see your cookie? Yes, if you login and your cookie is sniffed and spoofed then basically you just allowed the attacker to login as you at the same time. Minimizing it is a little bit different: you can use a secure proxy/tunnel, you can limit your unencrypted wireless activity, you can make sure that sites that should be SSL encrypted are (stripping SSL is common when password sniffing) and you can avoid these services while on open wifi networks.

amanuel 16y ago

logging out will cause the captured sessions to be useless. So remember to logout. VPN is really the best overall option.

cdine 16y ago
Most sites don't properly invalidate sessions when you log out, you can't protect yourself as well as you think. See our slide on this topic: http://codebutler.github.com/firesheep/tc12/#18 http://codebutler.github.com/firesheep/tc12/#18
- amanuel 16y ago
  Excellent points on the slideshow. The general lack of care on this topic among web companies is worrisome.
tswicegood 16y ago
That assumes the session is killed on logout. I know from first-hand experience that at least one version of Merb didn't do that. I hacked a pretty popular geo-socially site by grabbing the session cookie and playing around, then logging out. Was still able check-in after I had logged out and for good measure verified that my session was still valid after changing the password. I assume they were using the default sessions setup so I guess it expired. Didn't keep it around to see how long it stayed around. On reporting it, the response was essentially, "oh you didn't have to go to that much trouble, you could have just used your user/pass from curl…" Completely obvious to the fact that they're app/site was completely vulnerable to session hijacking. One of the problems of app frameworks, if you don't know what they're doing (and more importantly, not doing) you can get yourself in a heap of trouble before you even realize there's an issue. But boy, you sure can make it to market fast. shakes head
phamilton 16y ago
Just tried it with iGoogle Logging out doesn't kill the session.