Last week, you may have heard about Firesheep, a plug-in for the Firefox web browser that lets an eavesdropper take over another user's session—such as a login to Twitter or Facebook—by intercepting packets on a local network and copying the victim’s cookie. What Firesheep does is to take advantage of a known security flaw and make it easy to exploit, by carrying out sidejacking (or session hijacking). There are two main parts to this exploit:
- The attacker needs to be able to “sniff” the network packets, in order to grab the cookie. Firesheep doesn’t do that by itself, but works with packet capture software that comes standard on many computers (or can be freely downloaded). The attacker places himself on the same network as the victim – such as a wireless hotspot in a coffee shop – and if the network is unencrypted, the attacker can eavesdrop on all traffic that flows over the wireless link.
-
Firesheep then monitors the network traffic, looking for a “cookie” to be sent. When you log in to certain websites, you first provide a username and password, which are often sent encrypted. (You’ll see “https:” in the URL of encrypted pages.) However, after you log in successfully, some sites use a session cookie that stays active during your login: anyone who captures and sends that cookie to the originating website can mimic you. If you log in to Twitter, for example, session cookies are then sent between your computer and Twitter, which the attacker can then exploit to send tweets under your name.
The attacker doesn’t need to know your password: the website will simply believe the attacker is you, because they have your cookie. Many websites only protect the login page (encrypting your username and password), but turn off the encryption on the rest of the website. Result? Cookies are sent in the clear (unencrypted), attackers can intercept them, then hijack your session and gain access to your account. There is no way to detect that someone else on your Wi-Fi connection is using Firesheep. This vulnerability has been noted on a number of websites, including Flickr, Tumblr, and WordPress.
Although Firesheep garnered a lot of coverage, this is not a new problem. Its author points out that sidejacking tools already existed, and that Firesheep is simply a more user-friendly tool. However, Firesheep’s ease of use and its subsequent publicity shone a spotlight on a persistent security problem, making more people aware of this vulnerability and highlighting the need to address it.
Preventing the transmission of unencrypted cookies
Website operators can deploy encryption to protect their session cookies.
- For website operators: Wherever possible, websites should ensure that cookies are not sent in the clear, by using encryption (SSL/TLS/HTTPS) on more than just the login page. Some sites provide this feature by default, and others as an option—by default is definitely preferable. At a minimum, if you provide HTTPS as an option, then publicize it so your users know about it. (You can also set the HTTP Strict-Transport-Security header and turn on the Secure option for session cookies so that browsers send them only over SSL connections.)
There has been some resistance to deploying SSL, due to fears that the performance hit is too high. However, this is an outdated idea in most cases: the overhead is minimal, and services like Google’s Gmail have successfully deployed SSL for entire sessions (not just for the login portion). SSL has low costs and provides huge gains for protecting your users.
- For website users: if you have an account on a website (like a social networking site), check for an “https://” version of that site - making sure that the site doesn’t just turn back to “http:” once you’ve logged in. For Firefox users, there are helpful plug-ins, such as HTTPS Everywhere and Force-TLS, that try to ensure you are using an https:// connection wherever it is supported. (Note that sometimes a site just doesn’t make https:// available - in which case these plug-ins can’t provide you with extra protection, unfortunately.)
Protecting cookies that are being sent unencrypted by a website
If https:// is not provided on a site, then users can take steps to put encryption in place.
- You can use a virtual private network (VPN), which acts like a middleman to provide encryption for you. VPNs encrypt and transmit your network traffic from your computer to a remote server, which then connects to the actual website. If you don’t already have access to a VPN (often provided by workplaces for their employees), low-cost and adware-based VPN services are available. (Those with the technical ability and interest to try a free/alternative solution can set up an SSH tunnel.)
This solution does have some drawbacks. You can only guarantee encryption over part of the network—and the final connection to the destination site may be unencrypted—but it is likely that your traffic is much harder to intercept if you use a VPN. Another downside is that a VPN does require some effort (and possibly cost) to set up, and may sometimes not work reliably. However, this may be users’ only real option, while the website operators roll out their own sidejacking solutions.
Just don’t go there?
One simple solution that has been suggested is to stop using open Wi-Fi networks: lock down your own Wi-Fi, and don’t use public open Wi-Fi networks. As with many simple solutions, this is a stopgap measure that only partially addresses the problem. Fundamentally, the problem is not about wireless. It’s about the dangers of transmitting sensitive information— unprotected—over any kind of network, wired or wireless. It’s unwise to assume the network will protect you: consider secured Wi-Fi as a bonus, not a guarantee. So, while there are some benefits to limiting access to a wireless network and turning on encryption, this is not a “silver bullet” to stop Firesheep: end-to-end encryption is required for a truly effective security solution. Wireless security, where provided, should be in addition to https://—not instead of it.
Steel wool: armouring yourself
The takeaway message is that both websites and users have a role to play in dealing with sidejacking. While the ultimate solution requires websites to roll out SSL, the steps you can take as a user are:
- If you do use open Wi-Fi, without the additional protection of a VPN, limit your activities to low-risk ones, like reading the news. If you must log in to an account, like a social networking site, then try to ensure you’re on a site that uses “https://” throughout – which protects your cookies -- not just on the login page. (Firefox users can try the plug-ins listed above to help them.) If https:// is not provided, and you have no VPN, then you have no protection – bad idea.
- For better security, use a VPN, which provides another layer of protection through encryption. This will help you whenever you use untrustworthy networks. You can subscribe to a VPN service, in order to make this task easier.
- Let website operators know that you want them to provide more secure connections for your accounts: ask them to deploy https:// throughout their sites to protect your information.