Why Firesheep works and how to counter it

Dag Erik Vikan Norwegian University of Science and Technology, Department of Computer and Information Science http://dvikan.no May 26, 2011

Introduction

Firesheep is an extension for the Firefox web browser, created by Eric Butler, a freelance web application and software developer. Essentially, Firesheep is a packet snier which grabs unencrypted cookies over a wireless network. Firesheep also allows the user of Firesheep to take over someones session. Although packet sning is not something new, Butler wanted to demonstrate the security risk to users of websites, which only encrypt the login process, and not the whole session. This may seem like a good solution of protecting the users login credentials and preserving server resources, but due to the nature of HTTP and the Internet, the user is not safe at all. This essay will try to give the reader an understanding of why Firesheep works, and how packet sning can be countered. To limit the scope of this text, only the protection of the HTTP cookie will be discussed. As you will see, Firesheep does not exploit any code or take advantage of poor implementations, but works because of how the way Internet is built.

Problem discussion

Popular websites like Facebook and Twitter allows for users to login, and read and share data. Because HTTP is stateless [1], the server cannot tell the dierence among HTTP requests. That is, a server cannot know if two successive requests are the same user. The HTTP cookie was introduced to solve this problem. To understand how Firesheep can take over someones session, a short introduction to session management is needed.

2.1

Session management with cookies

It would be extremely impractical if users had to enter their username and password each time they wanted to request a resource on a website. The HTTP cookie made it possible for HTTP servers to maintain state. 1

Session management is the process of keeping track of a user across sessions of interaction with a computer system. The server generates a session identier(SID) and gives it to the user. On each subsequent request from the client, the SID is appended along with the request. In HTTP, the session handling is typically done in the HTTP headers, and the client sends the SID along in the cookie header. A typical SID exchange in HTTP: GET /index.html HTTP/1.1 Host: www.example.org HTTP/1.1 200 OK Content-type: text/html Set-Cookie: name=value; Expires=Wed, 09 Jun 2021 10:18:14 GMT (content of page) The server keeps track of the SIDs on the lesystem with associated user data, and responds with the appropriate interface for anyone who presents that SID. The SID is like a key or a proof, that you are indeed in possession of the password for that user, because only someone with a correct user/pass combination could have gotten that SID. In PHP for example, the session identier is called PHPSESSID and is 128 or 160 bits long(MD5 or SHA-1 respectively), which makes it infeasable to guess it. An example: PHPSESSID=64cd786173875c162d3b84cdf5bbac9d After the client has been provided with a SID, the client provides the SID on each subsequent request. GET /spec.html HTTP/1.1 Host: www.example.org Cookie: PHPSESSID=64cd786173875c162d3b84cdf5bbac9d; This is how a web application keeps you logged in. The SID is the temporary key which gives access to your prole. Try inserting the SID cookie in another browser than your default one, and hit refresh; you will see that you become logged in.

2.2

Why Firesheep works

As Butler has shown with Firesheep, it is insucient to only encrypt the login request because the unencrypted SID will be exposed on subsequent client requests. Not only will Firesheep be able to grab cookies, but any other 2

packet snier would do the job. This is how the Internet works; at default, nothing is encrypted and everything is in plaintext. This is particularly bad news for wireless networks(e.g. open WIFI hotspots). But in principle, wired networks are just as vulnerable to packet sning as wireless are, though it requires physical access to a node.

2.3

Encryption comes to the rescue

To remedy the problem of plaintext cookies on the loose, encryption is the solution [2]. What we want is condentiality(only sender and receiver can see content). Interestingly, it is possible to provide encryption in any of the top four layers of the Internet protocol stack. It is generally easier to deploy new Internet services at higher levels of the protocol stack. Many application developers do this, instead of waiting for security to be broadly deployed at the network layer. Secure Sockets Layer(SSL), is a very popular protocol which provides end-to-end encryption [3]. From a developers perspective, SSL lies at the transport layer, encapsulating application layer protocols such as HTTP, FTP and SMTP. SSL is supported by all major web browsers, and is used by all Internet commerce sites.

Conclusion

As Firesheep has shown, the Internet is a very open place. Everyone can connect to it, and enjoy many of its services. But your privacy may be invaded if not security features are deployed. Many years of research and hard work have resulted in a set of security protocols, which today, secures sensitive data all around the world. SSL would render Firesheep and any other packet snier useless, because they would only see garbled ciphertext. Butlers Firefox extension Firesheep, has made many ordinary users alert of the dangers of travelling through wireless unencrypted networks. The road ahead must be to further encourage big sites like Facebook and Twitter to turn on SSL by default, so that our privacy will not be invaded.

References
[1] Mike Andrews, James A. Whittaker, How to break web software, Addison-Wesley, 2006 [2] William Stallings, Cryptography and Network Security Principles and Practices, Prentice Hall, fourth edition, 2005

[3] James F. Kurose, Keith W. Ross, Computer Networking: A top-down approach, Addison-Wesley, fth edition, 2010