Ways to steal cookies in HTTP and HTTPS
pl...@ima.umn.edu
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
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
pl...@ima.umn.edu
http://www.ima.umn.edu/~pliam
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Paul Rubin
> 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.
If you don't accept them, how will the browser divulge them?
It's best to not accept them in the 1st place, which Communicator
lets you do.
The usual evil use of 3rd party cookies is to gather marketing
information: doubleclick.net runs banner ads on thousands of servers
and therefore knows (from the cookie sent to the doubleclick server)
which servers you've been browsing. If you actually buy something
from one of the sites and the site gives your name and address
to doubleclick, doubleclick now can bombard you with target ads,
phone calls, pesky salespeople, etc. (They claim that they
are not doing this, ... yet).
> 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 only charges you can make with just a cookie at that site are for
merchandise orders to the address that they have shipped your previous
orders to. If you want to send merchandise to a different address,
you have to log in to the secure server with your email address and
password.
> 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.
If you can mount an active attack, you get all the user's session
content, not just cookies. It's not that likely that any single
cookie will be more valuable than the session content over some period.
> 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.
The damage from getting the cookies stolen is almost entirely eliminated
by encrypting the cookies at the server side. Careful sites already do this.
pl...@ima.umn.edu
Paul Rubin <p...@netcom.com> wrote:
> If you don't accept them, how will the browser divulge them?
> It's best to not accept them in the 1st place, which
> Communicator lets you do.
If you configure Communicator not to accept 3rd party cookies, it
will still divulge 1st party cookies (i.e., cookies you got from
sites whose URL's you actually typed in) when an unauthorized 3rd
party puts IMG tags into HTML source ... as described in the
original post. But don't take my word for it :-), try it:
Edit => Preferences => Advanced => "Accept only cookies that
get sent back to the originating server"
then read a file with <img src="amazon.com/foo.jpg"> and snoop on
the http traffic...
The point is that you may wish the accept the cookie of amazon.com
*when* you explicitly connect to them, but you probably never want
a connection to microsoft.com to lead to a divulgence of your
amazon.com cookie. It would be nice if browser's were
configurable to disallow *all* 3rd party cookie activity.
> The only charges you can make with just a cookie at that site
> are for merchandise orders to the address that they have shipped
> your previous orders to. If you want to send merchandise to a
> different address, you have to log in to the secure server with
> your email address and password.
"That site" (by which I think we mean Amazon) doesn't use secure
cookies for 1-click purchases. I am not comfortable with any
charges to my credit card happening as a result of someone
stealing my cookie, whether through active or passive means.
What if someone wanted to force a publisher to reprint a book that
has been out of print for a while? They steal my cookie and 100
others and order the same book. They don't care that they have to
pay $39.99 for it themselves; they just don't want to wait years
for it to come into print again.
I don't think it's a good idea to have a non-HTTPS cookie used as
an authentication token of any kind.
> If you can mount an active attack, you get all the user's
> session content, not just cookies. It's not that likely that
> any single cookie will be more valuable than the session content
> over some period.
Not if the user accepted a secure cookie during a 128-bit SSLv3
session. IMHO, that kind of cookie *would* be an acceptable
authentication token (I think some banks use secure cookies in for
single sign-on purposes in this way). No active attack that I
know of will succeed to get extra session information (like your
credit card #).
As mentioned in the original post, if the user *ever* enables
40-bit SSLv2, the otherwise secure cookie is vulnerable to an
active attack when the owner least expects it -- due to this 3rd
party cookie divulgence mechanism.
> The damage from getting the cookies stolen is almost entirely
> eliminated by encrypting the cookies at the server side.
Why? If a mere presentation of the cookie can be used to buy
things, then its contents (whether encrypted data or not) are
mostly irrelevant. It seems to me that server-side encryption
buys you very little beyond user privacy. Server-side encryption
by no means forces proof of ownership by the client. Therefore
stealing such a cookie really can cause damage in an SSL
connection where the server is strongly authenticated but the user
is effectively anonymous.
John Pliam
pl...@ima.umn.edu
http://ima.umn.edu/~pliam
Thomas Reinke
> > The damage from getting the cookies stolen is almost entirely
> > eliminated by encrypting the cookies at the server side.
>
> Why? If a mere presentation of the cookie can be used to buy
> things, then its contents (whether encrypted data or not) are
> mostly irrelevant. It seems to me that server-side encryption
> buys you very little beyond user privacy. Server-side encryption
> by no means forces proof of ownership by the client. Therefore
> stealing such a cookie really can cause damage in an SSL
> connection where the server is strongly authenticated but the user
> is effectively anonymous.
Actually, encryption is effective providing you know how to do
it properly. In your previously discussed attacks, there is
the requirement to still go off-line and decrypt the session
data in captured in a 40 bit SSL session in order to decrypt the
contents. Whenever E-Soft has been involved with secure on-line
transactions where we have used cookies as authentication tokens,
we have
a) timestamped the cookie.
b) encrypted the cookie with triple-des
The time stamp allows us, on receipt of the cookie, to
check if it has expired. To successfully execute your
attack, if you were to listen to a 40 bit SSL session,
you would need to capture the contents, and decrypt
it within 20 minutes. If you don't decrypt it within
20 minutes, your cookie has expired, and the server
rejects it if and when it does receive it.
Unless 40 bit SSL can be broken into faster than 20
minutes, the attack fails.
Cheers, Thomas.
------------------------------------------------------------
Thomas Reinke Tel: (416) 460-7021
Director of Technology Fax: (416) 598-2319
E-Soft Inc. http://www.e-softinc.com
Barry Margolin
Thomas Reinke <rei...@e-softinc.com> wrote:
>The time stamp allows us, on receipt of the cookie, to
>check if it has expired. To successfully execute your
>attack, if you were to listen to a 40 bit SSL session,
>you would need to capture the contents, and decrypt
>it within 20 minutes. If you don't decrypt it within
>20 minutes, your cookie has expired, and the server
>rejects it if and when it does receive it.
This is reasonable if the cookie is being used just within a session. But
if the cookie is being used to allow One-Click style purchases weeks or
months after the last time you last signed on to the service, it would make
no sense to include a timestamp.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
nos...@pd.jaring.my
pl...@ima.umn.edu wrote:
> If you configure Communicator not to accept 3rd party cookies, it
> will still divulge 1st party cookies (i.e., cookies you got from
> sites whose URL's you actually typed in) when an unauthorized 3rd
> party puts IMG tags into HTML source ... as described in the
> original post. But don't take my word for it :-), try it:
I couldn't get it to work with Netscape 3.04. I created a test.htm with
img src="http://g.deja.com/gifs/dlogo_130_b.gif" and placed it on my own
server.
I could not get my Netscape 3.04 to send the Deja.com cookie to my own
server. Do I have to do something else? I turned on auto-load images - I
normally surf with images off - so even if it worked the attack is
unlikely to affect me.
I'll try it with communicator. If it works with communicator but not
with 3.04 then I'd say it's a security flaw in communicator, you should
then report this to Netscape.
For my own web applications I use session ids which expire after a
certain idle time period. The username and password is only entered
once. True, 40 bit crypto can possibly be cracked on the fly, however
128 bit crypto is easily available internationally (and often free too).
If one doesn't use cookies the session ids will have stored in the URL,
unless you do everything by POSTs (yuck!). Putting stuff on the URL
leaves things open to the HTTP-Referer attack. Of course that still
doesn't affect me coz I hexedited my Netscape to not send HTTP-Referer
:).
So we're still considering whether to put session ids in URLs or in
Cookies. Cookies are not supported by all browsers, nor everyone.
Link.
nos...@pd.jaring.my
> If you configure Communicator not to accept 3rd party cookies, it
> will still divulge 1st party cookies (i.e., cookies you got from
> sites whose URL's you actually typed in) when an unauthorized 3rd
> party puts IMG tags into HTML source ... as described in the
> original post. But don't take my word for it :-), try it:
OK tried it. Yes it works with Netscape 4. But it doesn't work with
Netscape 3 which I usually use (netscape 3 sends the relevant cookies to
the relevant sites). I'll take it to be another one of those security
flaws/bugs (features) in Netscape. It could be an intentional feature
(like IE5's clipboard pasting and bookmark notification to remote
sites), but just make noise about it and they'll probably fix it. Have
you tried it with IE 3/4/5 yet? I'm wondering if it'll be a case of
"Great minds think alike/fools seldom differ".
Cheerio,
Link.
Michael Ströder
>
> For my own web applications I use session ids which expire after a
> certain idle time period.
> Putting stuff on the URL
> leaves things open to the HTTP-Referer attack. Of course that still
> doesn't affect me coz I hexedited my Netscape to not send HTTP-Referer
> :).
Think about proxies logging your URL with session-id => use POST.
If you are using SSL you might wanna use strong client authentication
with client certificates. Each certificate's (subject, issuer) name has
to be unique anyway (X.509) and can be used easily as a session id.
Well, up to now this is not a solution for mass market e-commerce
servers...
Ciao, Michael.
Thomas Reinke
Barry Margolin wrote:
>
> In article <37AB9A1C...@e-softinc.com>,
> Thomas Reinke <rei...@e-softinc.com> wrote:
> >The time stamp allows us, on receipt of the cookie, to
> >check if it has expired. To successfully execute your
> >attack, if you were to listen to a 40 bit SSL session,
> >you would need to capture the contents, and decrypt
> >it within 20 minutes. If you don't decrypt it within
> >20 minutes, your cookie has expired, and the server
> >rejects it if and when it does receive it.
>
> This is reasonable if the cookie is being used just within a session. But
> if the cookie is being used to allow One-Click style purchases weeks or
> months after the last time you last signed on to the service, it would make
> no sense to include a timestamp.
That's true. On the other hand, I'd fire the consultant that recommended
that it is safe to put an encryption token on a user's browser that
can be used to authorize purchases on my behalf, weeks after I left the
browser.
I think the original discussion was with regards to secure cookies,
that aren't cached to disk, only sent over secure SSL connections,
and discussed an attack that could access the contents of the
cookie over a 40 bit SSL session, even if the user originally
connects to the site using 128 bit encryption.
Thomas
fro...@my-deja.com
pl...@ima.umn.edu wrote:
> ...
> [ lots of stuff deleted ]
> ...
>
> 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.
>
> 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.
>
Appendix E.2 of SSL 3.0 [http://home.netscape.com/eng/ssl3/4-APPN.HTM#E
] describes a procedure that is supposed to foil downgrading of SSL 3.0
connections to SSL 2.0 whereupon they can be attacked. Assuming that SSL
3.0 browsers and servers correctly implement this, it appears to me that
this attack is not possible.
BTW, interesting article.
Cheers,
F.
isoma
>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
I don't understand how this is useful. The browser sends its cookie to
e-commerce.widgetstore.com - but what has a malicious user gained?
--
mailto:is...@altavista.net - +44441089921 - Tim Bannister
http://www.jellybaby.net/~isoma/ - Spam? What spam? (pats procmail)
T. William Wells
isoma <is...@jellybaby.net> wrote:
: I don't understand how this is useful. The browser sends its cookie to
: e-commerce.widgetstore.com - but what has a malicious user gained?
I have a dating site (http://www.datingonline.com/) that uses
cookies. Each cookie is a large random string that is used as an
index into a current session database. The intercepted cookie
would allow the interceptor the same privileges as the legitimate
user.
Robert S
>
<snip>
> e-commerce.widgetstore.com - but what has a malicious user gained?
Some cookies store not only preferences, but passwords (and usernames).
However, even preferences could be dangerous in the wrong hands
depending on what those preferences are. Would you be comfortable with
your boss (or spouse) knowing that you have preferences for, say
(example only) alt.binaries.sex.hamsters.ducttape?
I have heard of, but not seen myself, that a few site do (or used to)
place credit card info in the cookies to save you from entering it
again.
isoma
>isoma wrote:
>>
><snip>
>> I don't understand how this is useful. The browser sends its cookie to
>> e-commerce.widgetstore.com - but what has a malicious user gained?
>
>Some cookies store not only preferences, but passwords (and usernames).
>However, even preferences could be dangerous in the wrong hands
>depending on what those preferences are. Would you be comfortable with
>your boss (or spouse) knowing that you have preferences for, say
>(example only) alt.binaries.sex.hamsters.ducttape?
>I have heard of, but not seen myself, that a few site do (or used to)
>place credit card info in the cookies to save you from entering it
>again.
I understand that some sites use cookies to store sensitive information,
but not the mechanism by which a malicious site owner obtains it.
Barry Margolin
isoma <is...@jellybaby.net> wrote:
>I understand that some sites use cookies to store sensitive information,
>but not the mechanism by which a malicious site owner obtains it.
I think the original post presumed that the malicious site was spoofing
traffic from the site you were connecting to, and inserting HTML tags that
would cause your browser to connect to his site for some images and send
your cookie information to him as part of that transaction. That's why
he's concerned about 3rd-party cookies.
John Pliam
> In article <slrn7ssp78...@bumper.jellybaby.net>,
> isoma <is...@jellybaby.net> wrote:
>
> > I understand that some sites use cookies to store sensitive
> > information, but not the mechanism by which a malicious site
> > owner obtains it.
>
> I think the original post presumed that the malicious site
> was spoofing traffic from the site you were connecting to, and
> inserting HTML tags that would cause your browser to connect
> to his site for some images and send your cookie information
> to him as part of that transaction. That's why he's concerned
> about 3rd-party cookies.
As the original poster, I must apologize for losing this thread
in the sea sci.crypt traffic.
Right, the *active* attacks in the original post
http://www.ima.umn.edu/~pliam/cky
aren't particularly impressive against http cookies which are
already "insecure". They require the adversary to actively
spoof traffic between Client and Server1 *while* simultaneously
passively listening to the traffic (the desired cookie) between
Client and Server2.
However for https cookies, the work factor
2^128 >> (2^40 + some active attacks),
and there is a distinct advantage gained (unless the user
*never* enables SSLv2 or 40-bit-only SSLv3 which is unlikely
in today's world).
John
Nick Kew
> browser --------------------------------------> intruder
>
> GET ...
> intruder --------------------------------------> server
You missed the point "isoma" already tried to tell you.
* Browser sends server's cookie (if any) to server. Not to intruder.
* Browser sends intruder's cookie (if any) to intruder. Not to server.
Now, what has intruder gained?
> (scheme that looks like a proxy server)
A proxy server sees all the information in transit. If the entire transaction
is going via your "intruder", then a cookie is the least of your problems.
--
Nick Kew
John Pliam
> Browser sends server's cookie (if any) to server. Not to
> intruder.
>
Not much for http cookies. But: a reduction of twenty-six orders
of magnitude in the work factor for https cookies. I have never
said that the victim's browser will send its cookie directly to
the intruder. That would be silly.
What the intruder controls is *when* the cookie is sent, and
thereby, potentially, the number of *bits* of encryption used
to protect it.
> A proxy server sees all the information in transit. If the
> entire transaction is going via your "intruder", then a cookie
> is the least of your problems.
A proxy server doesn't see the plaintext of encrypted traffic.
If a protocol claims to provide `strong authentication' what
this generally means is that there is an exchange of messages
end-to-end such that the identity of at least one party is proved
to the other party. Only a denial of service attack is feasible
no matter what's `out there'.
No self-respecting bank or e-commerce company should say to
you, "Hey, your buying power and credit card are safe with us
... unless, of course, someone happens to get access to your
ISP's gateway."
Going back to the original post, my point is simply this:
Were it not for the 3rd party cookie mechanism, SSL along
with https cookies acting as single single-on authentication
tokens *could* have provided strong authentication in the
sense described above. But unless the server uses SSLv3
exclusively (or impractically short cookie lifetimes, ~5 sec),
the authentication cannot strictly be considered strong.
3rd party cookies can thus be used to violate your surfing privacy
and subvert your shopping authenticity. Ergo, they are evil. ;-)
John