Brief aside: While I do work at Mozilla, this post is primarily focused on explaining the underlying website security controls that have failed to enable such an attack. To learn more about Mozilla's view of the Firesheep plugin I encourage you to read the post at the Mozilla Security Blog.
Why Is This News?
Firesheep does not exploit a new vulnerability. The vulnerable design of sending authenticated cookies over an unencrypted channel has been known for years. The reason Firesheep is making news is because of the ease of use to execute an attack and exploit this weakness in popular websites such as Facebook and Twitter. Perhaps all of this press, and a few angry users that are victim to unwanted status updates or tweets, may result in these large social networking sites actually fixing the issue.
How Does Firesheep Work?
First, Firesheep does not steal the victim's password that they are using with a website (twitter/facebook/etc). In fact, the passwords are correctly and securely sent to those websites. Instead Firesheep steals the session identifier for the user. The session id is a long random number that is used to represent the user after the user has authenticated to the website with their username and password. Without session ids a user would need to send their username and password with every request. The session id was created to eliminate this inconvenience and allow a user to simply provide their password once and allow the browser and website to handle the rest. The browser remembers the user's session id and the web server makes a record within their databases to associate the session id and user's identity. From this point on the web site knows that each time they receive the particular session id that the request is coming from the associated user.
Examples of session ids that would be stored on the web server
Session ID - Associated User
- 4364256265 - Joe
- 1239086434 - Sue
- 9938381123 - Bob
Many users are aware that before logging into a website they should check that they are on a page beginning with HTTPS (instead of HTTP). HTTPS uses Transport Layer Security (TLS) (sometimes referred to as SSL) to ensure that the password is sent over an encrypted connection. This means that a network administrator, the coffee shop folks running a wireless hotspot, or even the coffee drinker sitting next to you, is unable to view your password when it is sent over the network.
The problem is in the next step. As we discussed above, the username and password is only sent once. After that, the web browser sends the session id to the website in order to identify the user. Unfortunately many websites have decided not to implement TLS/SSL for the communication after the login process. This means that although your password is sent over an encrypted channel, the session id is not. Since the session id represents the user's identity with the website, anyone that obtains the session id thereby becomes the associated user.
How Does The Attacker Obtain Your Session ID?
[EDIT 11/4/10: A man in the middle attack is not necessary on many open wireless networks. Simply monitoring network traffic will reveal the session id of all users since the traffic is broadcasted to everyone. See comments 1 & 2 below for more info.]
This allows the attacker to easily view any data that is not encrypted like the session id. Encrypted data, such as the username and password, can not be viewed by the attacker even if he is executing a man in the middle attack.
To summarize, although the attacker can't obtain your password, they can obtain your session id. And this is just as good. Because with the session id the attacker can do anything in the website as you. In Facebook they could add new friends or make status updates and on Twitter they could tweet random messages. All of this would appear to normal just as if you had made these actions yourself.
Stay tuned for post #2 in the Firesheep series : Spotting Websites Vulnerable to Firesheep
-Michael Coates