Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.

 

 

Pick an apple! 
 
Keep Markup Tools Active in PDFpen

By default, PDFpen switches back to the Edit tool each time you add text, scribbles or other markup. To keep a tool selected (continuous use mode), double-click it. To exit continuous use mode, click the Select tool or press Command-1. You can also make continuous use mode the default by selecting Keep Tools Selected After Use in PDFpen's Editing preferences.

Visit Smile

 
 

Firesheep Security Tool Highlights Perils of Open Networks

Send Article to a Friend

Sometimes in the security world there are problems we know about for a long time that are mostly ignored until someone finally kicks us in the face with a dramatic demonstration. On 24 October 2010, freelance developer Eric Butler virtually body slammed a large percentage of the Internet with the release of Firesheep, a Firefox plug-in that enables anyone on the same local network to sidejack certain webmail, social networking, shopping, and other sessions without any technical skills; it does not work past a local router. Users on the same network connecting to sites such as Twitter, Yahoo Mail, Hotmail, and Facebook are all potentially vulnerable to Firesheep. (For more details, see our original coverage of the problem in “Sidejack Attack Jimmies Open Gmail, Other Services,” 27 August 2007.)

How Firesheep Works -- Firesheep is based on a simple premise. The plug-in constantly sniffs the local network for Web page requests from a browser to a site that Firesheep knows about. When a request is made, Firesheep extracts a browser cookie from the Web request, and offers its user the chance to hop onto the session at the vulnerable side as if he or she were the hijacked party.

This attack is known as HTTP session hijacking or sidejacking. You don’t need to steal a user’s username and password, just the special bits of information that keep his or her session active with the site they are visiting. This includes a unique token sent by the Web server to a browser; for some sites, a few other details are captured, too.

One of the problems when building a Web application is keeping track of users logged into your site. Unlike pre-Web network applications, the network protocol the Web uses—HTTP—is stateless. That means the protocol itself doesn’t include any way to maintain a persistent idea of who is retrieving pages from one request to the next, unlike many other protocols.

With HTTP, your Web browser merely sends a series of requests for pieces of data to one or more Web servers specified in an HTML page, but these are all independent actions. Your browser builds all the returned data into the Web page. (Web browsers and servers can use HTTP authentication to maintain a session, but it has an awkward interface—a pop-up dialog—and security model problems. Some private sites may use this kind of login instead of a Web-page login.)

This is in contrast to communications protocols like FTP or SSH, which build a connection when you log in. That connection is unique to the login and is maintained until it’s manually disconnected or times out from lack of use. It’s like making a phone call.

To solve this problem the masters of the Internet—that would be Netscape back in the 1990s—created the infamous cookie. A cookie is merely a bit of text that’s stored in your browser’s memory or as a persistent file on your hard drive. Barring a security failure (of which we’ve seen many), one site can never peek at the cookies set by another site. Thus a site can set your user and/or session ID as a cookie, and then use that to track you as you browse around. Other cookies keep track of things like your personal settings and preferences.

The problem is that if someone else obtains a copy of that cookie, unless the server implements additional security measures, it’s trivial for the attacker to impersonate you to the server. And those security measures are very hard to implement if you set cookies that work across multiple sessions (as is done very time you check the “keep me logged in” button on a site).

To ferret out these cookies, Firesheep merely sniffs the network to which the machine it’s running is connected. It then presents them in a nice user interface and enables the person running Firesheep to sidejack any interesting sessions. (I use the term “sidejack” since the users themselves are still logged into the site; Firesheep hasn’t “hijacked” and taken their connections away.) Firesheep is not the first tool to do this—Hamster and Ferret by Errata Security have been around for 3 years to perform the same attack—but Firesheep is elegant and insanely easy to use. It includes profiles of 26 sites that can be sidejacked.

Keep in mind, sidejacking works any time you are on the same network as the attacker, unless that network implements security to isolate traffic from sniffing. You most often see this on open hotspot networks that use Wi-Fi, or over Ethernet in places like hotels. You may even have seen this yourself when you launch iTunes in some location and see other user’s shared libraries.

Why Firesheep Works on Only Some Sites -- You might be saying to yourself, “But I know my user and password are encrypted when I log into Facebook/Twitter/whatever, so how can someone still sidejack my session?” Most major sites encrypt your login using something called SSL/TLS, commonly (though erroneously) shortened to just SSL. SSL encrypts a browser’s communications with a server, protecting you from someone sniffing on the local network.

SSL is exactly how to prevent an attack like sidejacking; the problem is that while sites may encrypt your username and password, they then drop the rest of your session back to an unencrypted state. Your password is protected, but your browser sends the cookie to the site with every single request, and thus it’s completely exposed to the attacker. You may be protected from someone harvesting your credentials to log in as you from their home later, but until that cookie changes and you are on another network they have full access to your account. They can even change your password and lock you out of your own account.

The only way a site can protect against sidejacking is to encrypt the entire session, including all the cookie exchanges. Google’s Gmail and Apple’s MobileMe are examples of services that do exactly that—you can never establish an unencrypted connection with their servers.

The owner of the site also needs to set a special cookie so an attacker can’t trick your browser into sending it in an unencrypted session. These cookies will be sent to the server only over an encrypted connection, and the feature is built into all major Web browsers. Even if a site uses SSL, the moment you attempt to connect to a non-SSL version of the site (which happens if you type the address in with http instead of https at the start, or if someone sends you a link without https), your browser sends your cookie unless it uses that special protection.

In other words, this is a problem you can’t fix yourself, and which must be resolved by the people developing the sites you visit.

Why Don’t All Sites Use SSL? -- If the fix is so easy (full-session SSL and protected cookies) you would think every site, especially major webmail, retail, and social networking providers, would implement the feature. The problem is that many of these companies fear the extra cost of full-session SSL, since it requires extra processing power to handle all the encryption (SSL is already an option on every Web server). The bigger the site, the greater their fear of additional costs.

But Google, whom I often criticize for their privacy foibles, recently implemented full-session SSL for all their Gmail connections (see “Google’s Gmail Defaults to Encrypted Sessions,” 13 January 2010). And in a blog post, Adam Langley of Google stated, “we had to deploy no additional machines and no special hardware.” Thus these fears seem to be unfounded, and there’s no longer any real excuse for leaving users so unprotected.

To be honest, as simple as sidejacking is, it hasn’t been the sort of thing most people had to worry about unless they spent time at security and hacker conferences like Defcon. Previous tools took significant technical knowledge to utilize and weren’t well known outside of security circles. But now that Firesheep is a simple Firefox add-on, your grandmother could easily take over your Facebook account when you connect your laptop to her Wi-Fi network during those boring family visits.

How to Protect Yourself -- The reality is there is only so much you can do to protect yourself until the sites you visit build in the proper security measures. If you have the option, you can send all your traffic over an encrypted VPN (virtual private network), although you are still vulnerable to sidejacking where your VPN connects (for example, at your work network). If you do use a VPN, keep a careful eye on your connection status, especially on iOS devices that frequently drop VPN connections and leave your traffic unprotected.

There are two Firefox plug-ins that force your browser to use SSL sessions for sites that support them. HTTPS-Everywhere works with a preset list of sites built into the plug-in, while Force-TLS lets you specify your own site list. Both of these are mentioned in an updated post by Firesheep’s creator.

Finally, you can avoid using public Wi-Fi networks. This isn’t an option for many people, but for years now I’ve avoided them by using 3G wireless for my mobile access (either a 3G card, portable router, or by turning off Wi-Fi on my iPhone). That limits my risk to Verizon or AT&T sidejacking me, which I consider pretty darn low.

As with many security issues hyped in the headlines, Firesheep isn’t the sort of thing that should keep you up at night, but if you frequently use public networks (wired or wireless), you might try to stick to sites that use full-session SSL as much as possible, or take the other precautions noted above.

 

Fujitsu ScanSnap Scanners — Save your business time and money
with our easy-to-use small ScanSnap Scanner line. Eliminate
paper piles by scanning documents, business cards, and receipts.
Visit us at: <http://www.ez.com/sstb>
 

Comments about Firesheep Security Tool Highlights Perils of Open Networks
(Comments are closed.)

barefootguru  2010-10-28 11:16
Public Wi-Fi spots can raise the bar considerably by setting a password for the network, even one stuck to the wall:

http://steve.grc.com/2010/10/28/instant-hotspot-protection-from-firesheep/
Glenn Fleishman  2010-10-28 14:19
I don't believe this is correct, but I am looking into it. WPA preshared keys may still allow those with the key to observe traffic of others. I'll post an update after I get more details.
JohnB (SciFiOne)   2010-10-28 11:25
FYI. I could not get Force-TLS to work with Firefox/3.6.11 on my iBook running 10.4.11. The Preferences button would not operate.
Ian Eiloart  2010-10-29 02:45
This isn't about open networks, it's about sloppy web sites. If you're passing secret information (like a login cookie), it needs to be all SSL. Securing your wifi network reduces the exposure, but still leaves plain traffic with your secret somewhere on the network.
Ian Eiloart  2010-10-29 02:55
Oh, and let's not forget that, even on a secure network, using a secure connection, you still need a secure machine to work from. Keylogging hardware and software can still capture your login credentials, and email them to a criminal. Cyber-cafes are not safe, unless you bring your own hardware.
The one place this is a big problem is on college/university campuses. The types of sites most vulnerable (built-in to Firesheep) are ones that college student frequent often. It's amazing how many people are vulnerable to this on my campus alone.
strobelight  2010-11-02 05:50
So, if you think you've been sidejacked, how to resolve?
Herouth Maoz  2010-11-02 10:04
The issue with switching to SSL everywhere is not necessarily the processing power, but rather the issue of certificates. A certificate can only be matched with an IP, not a host name, because SSL works at a lower level than the HTTP/1.1 protocol that allows several hosts on the same machine. Working with a single IP is very limiting.
Glenn Fleishman  2010-11-02 11:38
That's no longer correct. And you can get wildcard SSL certificates rather easily.