How To Protect Your Login Information From Firesheep(techcrunch.com)
techcrunch.com
How To Protect Your Login Information From Firesheep
http://techcrunch.com/2010/10/25/firesheep/
29 comments
If it were possible to pass the cookie on an encrypted channel but the content of the web page unencrypted this would match most people's idea of how it works. Unfortunately that's not the case.
Has there even been any attempt to standardize something like this? This problem certainly isn't a new one, so I would have guessed this had been looked into before
Has there even been any attempt to standardize something like this? This problem certainly isn't a new one, so I would have guessed this had been looked into before
> Has there even been any attempt to standardize something like this?
Yes. HTTP Digest authentication is an "encrypted cookie".
The problem is that it only protects against passive sniffing. Attacker able to inject packets can bypass it (e.g. replace Digest with Basic auth.)
Yes. HTTP Digest authentication is an "encrypted cookie".
The problem is that it only protects against passive sniffing. Attacker able to inject packets can bypass it (e.g. replace Digest with Basic auth.)
However, ForceTLS will only work if the server supports HTTPS.
IMO, a better solution is that of a SOCKS proxy as outlined in this comment: http://news.ycombinator.com/item?id=1828631
Using ssh as a SOCKS server has the added benefit of tunneling all traffic securely, not just that of Firefox.
IMO, a better solution is that of a SOCKS proxy as outlined in this comment: http://news.ycombinator.com/item?id=1828631
Using ssh as a SOCKS server has the added benefit of tunneling all traffic securely, not just that of Firefox.
SOCKS has no inherent encryption and is insecure as hell. Although there is an encrypted mode available in some servers, it's not supported by all clients, and it doesn't defend against MITM attacks, which limits its usefulness. (ever see a SOCKS client with a tickbox "only allow encrypted connections? didn't think so) SOCKS alone doesn't gain you any security advantage, it's SSH that does.
Note that if you have a tun/tap driver installed on both endpoints, ssh can even operate as a full-on VPN (-w option), thus not requiring any client software support.
None of the above (or OpenVPN) will work on a non-jailbroken iPhone/iPod/iPad, unfortunately. You'll need a pptp or IPSEC server for that.
Also beware of apps which do use SSL to communicate but don't check certificates. You'd be surprised how many get this wrong. This leaves the connection wide open to MITM attacks.
EDIT: objective arguments > downvoting
Note that if you have a tun/tap driver installed on both endpoints, ssh can even operate as a full-on VPN (-w option), thus not requiring any client software support.
None of the above (or OpenVPN) will work on a non-jailbroken iPhone/iPod/iPad, unfortunately. You'll need a pptp or IPSEC server for that.
Also beware of apps which do use SSL to communicate but don't check certificates. You'd be surprised how many get this wrong. This leaves the connection wide open to MITM attacks.
EDIT: objective arguments > downvoting
You didn't get it. SSH can be used for tunneling (encrypting) TCP connections between two machines and it can be set up so that the SSH client acts as a SOCKS proxy. Client apps connect to the SSH client, it tunnels the traffic trough the encrypted SSH connection to the other side where the SSH server decrypts it and connects to the target host. The traffic is thus encrypted between your machine and the SSH server, can't be sniffed from the air (unless the server is also connected to an insecure WIFI ;) ).
You didn't read my post: "SOCKS alone doesn't gain you any security advantage, it's SSH that does."
I've been using a SOCKS proxy over SSH for a while now, but I find it very slow, especially when loading a page that requires a few dozen HTTP requests.
So, today I set up a VPN using these instructions:
http://library.linode.com/networking/vpn-services/openvpn-ub...
Problem solved.
So, today I set up a VPN using these instructions:
http://library.linode.com/networking/vpn-services/openvpn-ub...
Problem solved.
Okay, I must have misunderstood something. At which point does Firesheep get your credentials? Really, the only case I am aware of is if you are on a wifi network, and I'm not sure if all the users on a secure network use the same encryption key.
I haven't seen a hub in ages, so when you're on a LAN you shouldn't be getting any packets that weren't meant for you. When exactly does Firesheep work?
I haven't seen a hub in ages, so when you're on a LAN you shouldn't be getting any packets that weren't meant for you. When exactly does Firesheep work?
I'm not an expert on wifi security, but here is what I found while doing some research:
"Wireshark can decrypt WEP and WPA/WPA2 in pre-shared (or personal) mode. WPA/WPA2 enterprise mode decryption is not yet supported."
Since Wireshark and Firesheep both use WinPcap, I assume this applies to both.
Also, while testing on an unsecured network, I found Firesheep was easily able to grab my HN session off my Android phone.
"Wireshark can decrypt WEP and WPA/WPA2 in pre-shared (or personal) mode. WPA/WPA2 enterprise mode decryption is not yet supported."
Since Wireshark and Firesheep both use WinPcap, I assume this applies to both.
Also, while testing on an unsecured network, I found Firesheep was easily able to grab my HN session off my Android phone.
I think that only applies to being able to decrypt packets after you've acquired the key, I'm not sure if it applies here...
Yes, you need the key to decrypt, but getting the key is not difficult for WEP [0], and only moderately difficult [1][2] for WPA PSK, if I understand correctly.
[0] http://www.cyberciti.biz/tips/howto-crack-wirless-wep-104.ht... "The actual computation takes about 3 seconds"
[1] http://www.renderlab.net/projects/WPA-tables/ "computed hash tables for the 1000 most common SSIDs against a million common passphrases"
[2] http://securityandthe.net/2008/10/12/russian-researchers-ach... "This means that a WPA or WPA2 key could be cracked in days or weeks instead of years."
[0] http://www.cyberciti.biz/tips/howto-crack-wirless-wep-104.ht... "The actual computation takes about 3 seconds"
[1] http://www.renderlab.net/projects/WPA-tables/ "computed hash tables for the 1000 most common SSIDs against a million common passphrases"
[2] http://securityandthe.net/2008/10/12/russian-researchers-ach... "This means that a WPA or WPA2 key could be cracked in days or weeks instead of years."
On the contrary, it is moderately difficult for WEP and almost impossible for WPA, if the key is long, and very very hard otherwise.
For WEP, the actual cracking is the easiest part, it's gathering all the IVs that's a hassle.
For WPA, the rainbow tables only cover common SSIDs and passwords, which doesn't really give you a very high probability of cracking it. The research in the third link you posted hasn't been made practical yet, as far as I know.
For WEP, the actual cracking is the easiest part, it's gathering all the IVs that's a hassle.
For WPA, the rainbow tables only cover common SSIDs and passwords, which doesn't really give you a very high probability of cracking it. The research in the third link you posted hasn't been made practical yet, as far as I know.
If you have a WLAN NIC that supports traffic injection, gathering IV:s can be done in a few minutes.
http://www.aircrack-ng.org/doku.php?id=simple_wep_crack
http://www.aircrack-ng.org/doku.php?id=simple_wep_crack
I know, I've been doing it for a while. It still isn't trivial, you need to get the handshake, do the replay attack, gather enough IVs, crack them, etc. It takes 5 minutes, but it's not plug and play.
It is more than "moderately difficult" to recover WPA keys; what you're looking at are tools and techniques used to crack passphrases for WPA.
Can you explain what makes it more than moderately difficult? Are you saying that getting the ssid and passphrase is not enough to get the key, or am I misunderstanding?
WEP can be broken given enough packets since it sends a portion of the key in each packet enabling the user to simply collect packets and break the key. There's a lot an attacker can do such as fake authentication with the server to force it send more of the necessary packets, etc.
WPA on the other hand cannot be broken like this. WPA is broken by capturing the handshake between the router and a user. This handshake can then be brute forced with a dictionary. The reason it's so difficult to crack is because the encryption key is salted with the essid of the router making rainbow tables extremely difficult to pre-compute. However, if the user uses a standard essid that came with the router, then pre-computed rainbow tables can most likely be found for it. They can be computed though while capturing the handshake, and I find it's beneficial to create the rainbow tables if you have a large dictionary.
Take a look at aircrack-ng for a lot more detail. This is just a basic overview of it all.
WPA on the other hand cannot be broken like this. WPA is broken by capturing the handshake between the router and a user. This handshake can then be brute forced with a dictionary. The reason it's so difficult to crack is because the encryption key is salted with the essid of the router making rainbow tables extremely difficult to pre-compute. However, if the user uses a standard essid that came with the router, then pre-computed rainbow tables can most likely be found for it. They can be computed though while capturing the handshake, and I find it's beneficial to create the rainbow tables if you have a large dictionary.
Take a look at aircrack-ng for a lot more detail. This is just a basic overview of it all.
When people talk about WEP insecurity, they are talking about fundamental flaws in the protocol that make the passphrase almost irrelevant.
Convincing an ethernet switch to send you packets that are not meant for you is, unfortunately, easy.
This is a concept that many people should really think about, since many belive that a switched network is "secure".
This is a concept that many people should really think about, since many belive that a switched network is "secure".
Hmm, how is it done? I guess you could send requests with fake IPs but real MACs?
Take a look at Ettercap's man page. That'll give you a nice list of making a network behave like this.
ettercap does ARP poisoning, if I remember correctly, for MITM attacks. I was wondering if there was a way to set it to the equivalent of promiscuous mode, not spoof IPs.
Yes, Ettercap, by default, is in promiscuous mode. It does quite a bit more than just ARP poisoning though, it can also do DHCP and ICMP spoofing among others.
Here's the man page: http://linux.die.net/man/8/ettercap
Here's the man page: http://linux.die.net/man/8/ettercap
I meant set the router in a sort of promiscuous mode (i.e. make it send you all the packets, regardless of their original destination), not the adapter. These types of poisoning are very useful, but they're not what you need for Firesheep. With a poisoning attack, you override the packet's destination and it's up to you to send (it's an active attack). Firesheep just monitors passively, which is why I was wondering if it worked anywhere.
I agree with you, I'm just saying that the type of passive monitoring Firesheep does only works on unsecured wifi networks and is, thus, not very useful.
I agree with you, I'm just saying that the type of passive monitoring Firesheep does only works on unsecured wifi networks and is, thus, not very useful.
Well, setting your adapter into promiscuous mode will allow you to capture all the packets. By using Ettercap though to put your adapter into promiscuous mode, it will handle the packet forwarding for you. Therefore, you can use Firesheep to monitor the entire network pretty easily.
From what I've seen it should capture them from everyone on the network, since Firesheep is simply capturing packets from whatever the adapter sees over TCP port 80. I haven't tried that yet, so you might be right.
Also, an attacker can simply use SSLStrip and get the cleartext passwords for online services anyway. This isn't anything novel, since there have been plenty of attacks that allow you to session hijack rather easily (i.e. hamster). You can even simply monitor in Wireshark and manually enter the session information into your cookies.
From what I've seen it should capture them from everyone on the network, since Firesheep is simply capturing packets from whatever the adapter sees over TCP port 80. I haven't tried that yet, so you might be right.
Also, an attacker can simply use SSLStrip and get the cleartext passwords for online services anyway. This isn't anything novel, since there have been plenty of attacks that allow you to session hijack rather easily (i.e. hamster). You can even simply monitor in Wireshark and manually enter the session information into your cookies.
Since I can't edit my comment, I'll reply. I tested this and it only appears to work on unsecured wifi networks. I can't find any other usecase where my network adapter will receive packets not meant for me.
What's so surprising about this? I don't get it. It's decades old news, unencrypted network traffic can be sniffed. And the solution is almost a decade old as well: use TOR (www.torproject.org) or JAP ( http://anon.inf.tu-dresden.de/index_en.html ) to hide your traffic from your local network operator. Be it your favorite dictator, government, employer, husband/wife, girlfriend/boyfriend or mother.
Even if on a WPA encrypted network, the AP operator (or anyone between the AP and the internet provider) can steal your data. (Of course the internet provider could do this as well, they are just probably less of a problem than the next guy with firesheep or an open AP set up for logging your sessions and passwords.)
Even if on a WPA encrypted network, the AP operator (or anyone between the AP and the internet provider) can steal your data. (Of course the internet provider could do this as well, they are just probably less of a problem than the next guy with firesheep or an open AP set up for logging your sessions and passwords.)
You can simply use "iPig"
http://www.iopus.com/ipig/
http://www.iopus.com/ipig/
For most people there is a huge gap between "can read everything I write" and "can gain full control/impersonate me". On the technology side, these two things are unfortunately coupled. It is way more than a privacy risk.
If it were possible to pass the cookie on an encrypted channel but the content of the web page unencrypted this would match most people's idea of how it works. Unfortunately that's not the case.