Cookie Stealing in SSL

John Pliam

The original article: (ca. 1999), based on this usenet thread.

"Cookies are inherently evil. Just say no to cookies." - Randal Schwartz The mechanism for 3rd party cookies has been criticized because of its implications for user privacy. With the cooperation of many websites, 3rd party cookies are used to monitor the surfing habits of users. However repugnant this may seem, it stems from the legitimate function of HTTP, namely the willingness of your browser to accept IMG tags as "instructions" of where to connect. But consider the security implications of a malicious abuse of this mechanism. While I am unwilling to go as far as Randal about cookies in general, I am beginning to conclude that "3rd party" cookies really are evil. Unfortunately, you cannot just say 'no' to 3rd party cookies. In both Netscape Communicator and MS Internet Explorer, there is no way to turn off all 3rd party cookie activity (unless you disable cookies entirely). Communicator will let you refuse to *accept* these cookies but will not control their divulgence. IMHO, the unauthorized divulgence of 3rd party cookies makes up the other half of their "evil" equation. This is particularly true when a cookie is used as a kind of weak authentication token. (At least one E-commerce site will let you charge to a user's credit card by merely presenting the correct persistent cookie. I won't give their name publicly because, hey, it's a jungle out there ;-) The active attacks presented below show that an arbitrary HTTP cookie of the attacker's choosing can literally be *demanded* from a browser any time its user surfs. Under certain circumstances, HTTPS cookies can be stolen. These secure cookies are at best, only as secure as the weakest mode of SSL *ever* used by the browser. This may be very different from the mode of SSL enabled when the user *intends* to send a secure cookie. Stealing HTTP Cookies --------------------- A single web page may make connections to several sites in order to retrieve all of its graphical hypertext media. Thus, typing a single URL http://www.acme.com/ may spawn many connections to graphics.acme.com, each resulting from IMG tags of the form <IMG src="http://graphics.acme.com/foo.jpg">. The graphics.acme.com site could make use of cookies in order to provide dynamic images tailored to the user's preferences. This example has every appearance of being legitimate, but the implicit trust placed by the browser in the HTTP response could be unwarranted. A malicious adversary could actively modify the HTML to include a false IMG tag such as <IMG src="http://e-commerce.widgetstore.com/hrule.jpg"> forcing the unsuspecting browser to send its Widget Store cookie out into the Internet. The attacker -- acting as an "intruder in the middle" -- steals the the cookie of choice from user's browser. With TARGET_URL = http://e-commerce.widgetstore.com/hrule.jpg, and server = any legitimate server (e.g. home.netscape.com), the main stages of this attack are depicted below: GET ... browser --------------------------------------> intruder GET ... intruder --------------------------------------> server <html>...</html> server --------------------------------------> intruder <html>...<img src=TARGET_URL></html> intruder --------------------------------------> browser Cookie: foo=bar; ... browser --------------------------------------> intruder (intended for TARGET_URL) forged TARGET_URL resource intruder --------------------------------------> browser Note that it is not necessary for the intruder to stand in between the browser and the server corresponding to TARGET_URL. That is just the easiest way for the intruder to go undetected. Stealing HTTPS Cookies ---------------------- By definition, HTTPS cookies are never sent without SSL protection. However, variants of our attack to steal HTTP cookies could be designed to exploit SSL weaknesses. Suppose your Widget Store E-Commerce cookie is secure and its server supports 128-bit encryption. On the other hand, suppose that Al's Shitty Mortgage Company supports only 40-bit encryption and only SSL version 2. You don't like 40-bit SSLv2, but you are willing to drop your guard temporarily in order to connect to Shitty Mortgage and get Al's latest interest rate. Throughout this section, the target cookie is the Widget Store E-Commerce cookie with SSL URL TARGET_URL = https://e-commerce.widgetstore.com/hrule.jpg Also take, server = any http server (e.g. Netscape home) target = e-commerce.widgetstore.com We assume that the small horizontal rule image (common to many servers) is available from Widget Store and can be added to any HTML without being noticed. The following attack combines our HTTP cookie stealing with the well-known ciphersuite rollback attack (see [WS96]) in which an SSLv2 session is forced into 40-bit mode. The attacker actively acquires the desired cookie encrypted with an unknown 40-bit key. After a couple hours of exhaustive search, the plaintext cookie is recovered. intruder: Wait for browser to drop to 40-bit SSLv2 and connect to server (listen to Al's traffic). GET ... browser --------------------------------------> intruder GET ... intruder --------------------------------------> server <html>...</html> server --------------------------------------> intruder <html>...<img src=TARGET_URL></html> intruder --------------------------------------> browser Ciphersuite rollback attack: browser & target establish 40-bit session key, k. browser <-------------> intruder <------------> target {Cookie: foo=bar; ...}_k browser --------------------------------------> intruder {Cookie: foo=bar; ...}_k intruder --------------------------------------> target {hrule.jpg}_k target --------------------------------------> intruder {hrule.jpg}_k intruder --------------------------------------> browser Note that because the intruder cannot easily determine the 40-bit session key in real time, she must remain in the loop and wait to conduct a brute-force search off-line. References ---------- [CKY1] Persistent State HTTP Cookies, Netscape Communications, URL: http://www.netscape.com/newsref/std/cookie_spec.html [CKY2] D. Kristol, L. Montulli, HTTP State Management Mechanism, RFC 2109, 1997. [W3C] World Wide Web Consortium Security FAQ, URL: http://www.w3.org/Security/Faq/. [WS96] D. Wagner, B. Schneier, "Analysis of the SSL 3.0 Protocol", 1996, URL: http://www.counterpane.com/ssl.html. -------------------------------------------------------------------- John Pliam last modified: Tue Aug 13 09:40:48 EDT 2013 (removed stale links from archive.org version)