Microsoft IE cookies readable via about: URLS
Jouko Pynnonen
Microsoft Internet Explorer has a vulnerability which allows a malicious
website to access any cookie in the browser's memory or those stored on
disk. Cookies are used by web sites for storing preferences, statistics
and tracking users, but also for storing more sensitive information such
as session keys and even usernames and passwords. Cookies are used by
many (probably most) online banks, webmail systems, and other sites
requiring user authentication.
Access to cookies may allow an attacker to retrieve passwords or other
sensitive information, or hijack authenticated web sessions.
What makes this possible are certain features of "about:" URL handling of
IE. For some reason, an URL starting with "about:" can contain html code
that will be interpreted by the browser. For instance entering the URL
"about:<h1>hello</h1>" brings up a page with the heading "hello". The URL
may contain JavaScript as well. Going to the following location with IE
causes an alert box to be displayed:
about:<script language=JavaScript>alert('ALERT');</script>
Finally, the about URL may have a hostname placed after the colon, and IE
uses that hostname when determining the cookies to use:
about://www.anydomain.fi/<script language=JavaScript>alert(document.cookie);</script>
The above URL would result in IE displaying cookies of www.anydomain.fi
in the alert box, assuming that the site has been visited and it has set
a cookie which hasn't expired.
A malicious website can have a piece of JavaScript redirecting the
browser to an about: URL similar to the one above, and do anything with
the cookie information of any selected domain. Instead of showing an
alert box, the JavaScript code might just pass the cookie contents to a
script or a CGI program which could quietly store the information to a
file and then redirect the browser elsewhere or show some seemingly
harmless web content.
A web page for testing the vulnerability can be found at
http://www.solutions.fi/iebug/
You can type in an address of a website that uses cookies, (without
"http://") and it will tell you if your browser is vulnerable to the
problem. For a relatively harmless test case try typing the address
www.google.com in the box (assuming you've visited Google before).
At least IE versions 6 and 5.50 appear to be vulnerable, but it looks
like some older versions like 5.00 isn't, at least in the way described
above. It interprets the html and JavaScript, but doesn't have any cookie
data in document.cookie.
A vulnerability with the same impact came public in May 2000, see
http://www.peacefire.org/security/iecookies/.
Microsoft was contacted November 1st. Their response was quick and they
are producing a patch to be released soon (if not already released).
Until then, you can protect yourself from the vulnerability by disabling
cookies (at Tools -> Internet options -> Security -> Customize) or by
switching to another browser such as Opera or Netscape, which don't
appear to have the same about: URL features.
--
Jouko Pynnonen Online Solutions Ltd Secure your Linux -
jo...@solutions.fi http://www.secmod.com
Nick FitzGerald
> Microsoft Internet Explorer has a vulnerability which allows a malicious
> website to access any cookie in the browser's memory or those stored on
> disk. Cookies are used by web sites for storing preferences, statistics
> and tracking users, but also for storing more sensitive information such
> as session keys and even usernames and passwords. Cookies are used by
> many (probably most) online banks, webmail systems, and other sites
> requiring user authentication.
>
> Access to cookies may allow an attacker to retrieve passwords or other
> sensitive information, or hijack authenticated web sessions.
>
> What makes this possible are certain features of "about:" URL handling of
> IE. For some reason, an URL starting with "about:" can contain html code
> that will be interpreted by the browser. For instance entering the URL
> "about:<h1>hello</h1>" brings up a page with the heading "hello". The URL
> may contain JavaScript as well. Going to the following location with IE
> causes an alert box to be displayed:
>
> about:<script language=JavaScript>alert('ALERT');</script>
This was hinted at in Andrew Clover's message of 19 October that
pointed out the about: protocol is, by default, in the Internet
security zone *and* about: URLs can have cookies. This is a neat,
though unsurprising, extension of that. Andrew's post is in the
archives at:
http://www.securityfocus.com/archive/1/221612
That's interesting, given they seemed to think there was no problem
(despite the flaw being obvious to the rest of the world) back when
Andrew mentioned it...
> Until then, you can protect yourself from the vulnerability by disabling
> cookies (at Tools -> Internet options -> Security -> Customize) or by
> switching to another browser such as Opera or Netscape, which don't
> appear to have the same about: URL features.
A better workaround (assuming that you feel cookies are "relatively
useful" and would rather not turn them off) is to put about: URLs
into the Restricted Sites zone, as detailed in Andrew Clover's
followup to his own post:
http://www.securityfocus.com/archive/1/222552
In short, create a DWORD value named "about" under:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults
and set it to 4.
I just tested this against your test page and with the above value
set, the test tells me "No cookies found for site...".
Interestingly, this registry change seems to have almost immediate
effect -- i.e. it did not require a restart or logout/login or even
an IE exit/restart (I did this on Win2K) but occasionally, when
running the test page over and over alternating back and forward
between having the above value set and not present (the default), the
page would work as if the registry value had not yet been changed.
--
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854
Jeffrey W. Dronenburg
<snip>
> A better workaround (assuming that you feel cookies are "relatively
> useful" and would rather not turn them off) is to put about: URLs
> into the Restricted Sites zone, as detailed in Andrew Clover's
> followup to his own post:
> http://www.securityfocus.com/archive/1/222552
> In short, create a DWORD value named "about" under:
> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\ZoneMap\ProtocolDefaults
> and set it to 4.
> I just tested this against your test page and with the above value
> set, the test tells me "No cookies found for site...".
> Interestingly, this registry change seems to have almost immediate
> effect -- i.e. it did not require a restart or logout/login or even
> an IE exit/restart (I did this on Win2K) but occasionally, when
> running the test page over and over alternating back and forward
> between having the above value set and not present (the default), the
> page would work as if the registry value had not yet been changed.
<snip>
I validated your test results with Windows 98 SE (4.10.2222A) in a
multi-user environment and Internet Explorer 5.5 (5.50.4807.2300IC with SP2;
Q306121 installed), both fully patched with latest updates. I also
validated your test results with Windows Me (4.90.3000) and Internet
Explorer 5.5 (same version as above) and then again after upgrading to IE
6.0 (6.0.2600.0000).
In all cases, the registry change did not require a system reboot to take
effect.
However, when I attempted to validate your test result with IE 5.5 by
toggling the registry settings between "0" and "4", I noticed that
increasing the security setting takes effect immediately, while reducing it
requires a new instantiation of IE and will not take effect in the current
window. Changing the registry value from "0" to "4" would change the output
results on the test Web page from displaying cookies to reporting "No
cookies found for site...". Resetting the value from "4" to "0" had no
effect the current instantiation of IE, but the new registry value would
take effect upon opening a new IE window, but still not in the previous IE
window. (Isn't multi-tasking fun? <smirk>).
This wasn't the case with IE 6.0, however. Toggling the registry settings
between "0" and "4" took immediate effect in the current window when both
increasing and decreasing the setting.
Therefore, increasing the cookie security setting will take effect
immediately in both IE 5.5 and 6.0 in all open IE windows. Decreasing the
setting will only take effect in a new window in IE 5.5 regardless of
whether or not the previous windows (including the REGEDIT window) are still
open or not. Decreasing the setting in IE 6.0 will have immediate effect
and make the browser vulnerable to the exploit.
Cool stuff! Thanks, Nick, for reminding us of Andrew's post.
Cheers,
Jeff
Jeffrey W. Dronenburg, Sr.
MIS Major, Univ. of Maryland, Univ. College
Alpha Sigma Lambda
Phi Kappa Phi
"A day without learning is like apple pie without ice cream. They're both
much sweeter the other way around." -Me! :-)
Oliver Petruzel
>
> Jouko Pynnonen <jo...@solutions.fi> wrote:
>
> > Microsoft Internet Explorer has a vulnerability which allows a
> > malicious website to access any cookie in the browser's memory or
This brings to mind a question: has anyone collected a list of the most
revealing KNOWN cookies in the wild? Is there a resource (site)
available with a list for me to use in order to perhaps blacklist the
URL's personally? I often find myself studying my local cookies and
have noticed repeat offenders from very popular sites that I avoid now
because of this; and I believe such a public list would serve as a way
to prevent cookies from becoming too powerful or revealing. A cookie
reporting service possibly. Anyone with a link for this if it already
exists or with the energy to compile it yourself, go for it, and plz let
us know.
Oliver
Clover Andrew
> This was hinted at in Andrew Clover's message of 19 October
Yes. I noted that "IE incorrectly applies HTTP-style URL parsing to
'about:' URLs", from which I really should have investigated further to
find that in fact it doesn't recognise the difference between http: and
about: at all in the case of cookie access security. My bad - having
found what I considered enough of a hole to require patching, I didn't
go further and find its full potential.
> That's interesting, given they seemed to think there was no
> problem (despite the flaw being obvious to the rest of the
> world) back when Andrew mentioned it...
Well, my exploit was less serious than this, but it was indicative of
brokenness, and I would have expected the IE team to at least
investigate. Instead, Microsoft seemed more interested in arguing
Mitigating Factors. It would be easiest to simply remove the
about-unknown-page-echoing-"feature", since it is of no legitimate use
whatsoever (or at least enforce HTML-escaping on it). I do not expect
the patch for Jouko's more serious exploit to do so, when it's released,
but there's always hope.
> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
> Settings\ZoneMap\ProtocolDefaults\about = 4
Indeed, I've been using this a while with no problems, recommend it.
--
Andrew Clover
Technical Consultant
1VALUE.com AG
Thomas Reinke
are two separate monthly reports called the Cookie Report and
Web Bug report located at
http://www.securityspace.com/s_survey/data/index.html
Of the two, the Web Bug report is the more interesting - it documents
the occurance of web bugs, which by definition occurs whenever a third
party serves out content as part of a page you visit (think online
advertisers). The report provides the top 100 "beneficiaries" of
web bugs, which would give you the top 100 domains to block. Note that
this does NOT reveal actual usage of cookies, but since virtually
all advertisers use them, it's a pretty good correlation. All the
big players are immediately visible in this list (Top 5 Count:
linkexchange.com, bfast.com, extreme-dm.com, hitbox.com,
doubleclick.net).
When "weighted" by traffic, the top 5 are doubleclick.net,
akamaitech.net,
admonitor.net, gamespy.com, interstitialzone.com.
The cookie report gives a some additional statistics on the types
of cookies that are found in the wild (life time, common names, etc.)
Hope this helps,
Thomas
--
------------------------------------------------------------
Thomas Reinke Tel: (905) 331-2260
Director of Technology Fax: (905) 331-2504
E-Soft Inc. http://www.e-softinc.com
Publishers of SecuritySpace http://www.securityspace.com
Valdis.K...@vt.edu
> This brings to mind a question: has anyone collected a list of the most
> revealing KNOWN cookies in the wild? Is there a resource (site)
> available with a list for me to use in order to perhaps blacklist the
> URL's personally? I often find myself studying my local cookies and
> have noticed repeat offenders from very popular sites that I avoid now
> because of this; and I believe such a public list would serve as a way
> to prevent cookies from becoming too powerful or revealing. A cookie
> reporting service possibly. Anyone with a link for this if it already
> exists or with the energy to compile it yourself, go for it, and plz let
> us know.
A far better approach is to use software that blocks *all* cookies, and
then have an exemption list for those sites that *YOU* visit that specifically
need cookies in order to function.
Remember - cookies as data harvesting tools only work because a large
percentage of people allow cookies. If the *default* behavior of people
was to tolerate only cookies that allow (for instance) session management
of a single visit, or only retain very basic cross-session information,
then the site operators wouldn't have much reason to use cookies.
Something that's a *bigger* issue is probably the infamous "web bug", which
usually shows up as a 1x1 transparent pixel. Now *THERE* is a area where
a "black list" might be more useful (because you can have an <IMG> tag
that points off-site to a tracking service, where the user may have
said "only allow cookies from this server").
There's Unix software for all this at www.junkbuster.com. I have *NOT*
tried their Windows software. It's not a *total* solution, but it's
a start.
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
Per Arne Johansson
>-----Original Message-----
>From: Nick FitzGerald [mailto:ni...@virus-l.demon.co.uk]
>Sent: Friday, November 09, 2001 3:51 PM
>To: bug...@securityfocus.com
>Cc: Jouko Pynnonen
>Subject: Re: Microsoft IE cookies readable via about: URLS
>A better workaround (assuming that you feel cookies are "relatively
>useful" and would rather not turn them off) is to put about: URLs
>into the Restricted Sites zone, as detailed in Andrew Clover's
>followup to his own post:
> http://www.securityfocus.com/archive/1/222552
>In short, create a DWORD value named "about" under:
> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\ZoneMap\ProtocolDefaults
>and set it to 4.
>I just tested this against your test page and with the above value set,
the test tells me "No cookies found for site...".
>Interestingly, this registry change seems to have almost immediate
effect -- i.e. it did not require a restart or >>>>>logout/login or even
>an IE exit/restart (I did this on Win2K) but occasionally, when
>running the test page over and over alternating back and forward
>between having the above value set and not present (the default), the
>page would work as if the registry value had not yet been changed.
I have tried this workaround it works as described and without a reboot.
However it breaks certain applications that use the "Internet Explorer
Server Window" most notably Yahoo Instant messanger 5. I does not affect
versions 3 or 4. My version of YAIM is 5,0,0,1036.
The effect in short the "Internet Explorer Server Window" remains blank
not showing the IM texts.
This might be due to poor design om yahoos part, but I am posting it as
it may effect other applications aswell and might not be a good
workaround for all.
Best Regards,
Per Arne Johansson
Peter W
significant, and this about: bug underscores the importance
of using at least one "secure" cookie for extra protection **
On Thu, Nov 08, 2001 at 03:32:54PM +0200, Jouko Pynnonen wrote:
> Finally, the about URL may have a hostname placed after the colon, and IE
> uses that hostname when determining the cookies to use:
>
> about://www.anydomain.fi/<script language=JavaScript>alert(document.cookie);</script>
>
> The above URL would result in IE displaying cookies of www.anydomain.fi
> in the alert box, assuming that the site has been visited and it has set
> a cookie which hasn't expired.
Site admins: be sure to set the "secure" flag on cookies where possible!
A colleague who has tested this (I don't have IE 5.5 or 6.0 handy) reports
at least one nugget of good news: it seems that about: can only be used to
leak non-secure cookies. At least for our site (which uses both secure and
non-secure cookies), only those not flagged secure are visible. So sites
that run under SSL and set the secure flag are OK. But those of us using
cookies on plain old HTTP are in deep trouble. (And rumor has it that at
least one prominent online investment e-trading site, despite using SSL,
does *not* set the secure flags for their cookies, and therefore their
customers using IE 5.5 or IE 6.0 are vulnerable to some degree of account
information theft!)
Unfortunately, a quick survey of some on-line storefronts by prominent tech
companies (Red Hat, IBM, Microsoft) suggests that it's rather popular for
commerce sites to only use non-secure cookies. This despite the discussion
of the "cookie marking" bug in IIS 4 and IIS 5 that prompted patches.[0]
Microsoft: this really, really stinks.
-Peter