Thursday, November 4, 2010

Spotting Websites Vulnerable to Firesheep

Part 2 of the firesheep series (Part 1 - understanding firesheep attack)

Here is an easy way to determine if a website is vulnerable to the Firesheep attack.  (For the record, technically Firesheep is just a tool to easily exploit a website that does not send session cookies over TLS/SSL. You could perform this same attack with any number of tools.)

Easy Detection

An easy way to spot a vulnerable website is to look at the URL. 

  1. When you login is the URL HTTPS?
  2. After you login does the URL become HTTP?
If the answer is yes to both of these questions then the website is vulnerable.  Unfortunately answering no to question #2 does not necessarily mean the website is securely designed. Here is a better approach.

Fail Proof Detection
  1. Start up your favorite proxy tool (burp, webscarab)
  2. Login to the website
  3. Inspect the HTTP responses and look for the set-cookie
  4. For every set-cookie you should see the word SECURE at the end.  If you don't see that word then the website is vulnerable.
Vulnerable Example from Twitter:
HTTP/1.1 302 Found
<snip>
Set-Cookie: auth_token=; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: lang=en; path=/
Set-Cookie: auth_token=b34e2aa91082da041371a9891db49333084f9b94; domain=.twitter.com; path=/
Set-Cookie: _twitter_sess=BCh7DEoYcGFa37ec2bfd81b513a7; domain=.twitter.com; path=/

Secure Example from PayPal - Notice "Secure" used for every cookie
HTTP/1.1 200 OK
<snip>
Set-Cookie: navcmd=_login-submit; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: login_email=test%40t.com; expires=Tue, 03-May-2011 22:33:38 GMT; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: flow_back_cookie=; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: _3P0VieXqbXBuy=IuyJVqQ0CViZZuzOezihVTUgbUPrVsFvb56TSu; domain=.paypal.com; path=/; Secure; HttpOnly
Set-Cookie: navlns=0.0; expires=Wed, 30-Oct-2030 22:33:38 GMT; domain=.paypal.com; path=/; Secure; HttpOnly


A site could be designed to only use HTTPS and may argue that the SECURE flag is not needed. However, this is just not true. While that scenario is considerably more secure than the Facebook design (HTTPS login and then clear text cookie exchange) the website would still be vulnerable to session hijacking attacks that force the browser to send HTTP requests to site and thereby expose the session id in the clear.

A great table of popular sites and whether they are vulnerable or not can be found at digitalsociety.org:

Post #3 in the Firesheep series: Protecting Yourself From Firesheep

-Michael Coates