[NT] Cookie Data in IE Can Be Exposed or Altered Through Script Injection

From: support@securiteam.com
Date: 11/13/01


From: support@securiteam.com
To: list@securiteam.com
Subject: [NT] Cookie Data in IE Can Be Exposed or Altered Through Script Injection
Message-Id: <20011113193015.A3EBA138BF@mail.der-keiler.de>
Date: Tue, 13 Nov 2001 20:30:15 +0100 (CET)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Cookie Data in IE Can Be Exposed or Altered Through Script Injection
------------------------------------------------------------------------

SUMMARY

Many web sites use cookies as a way to store information on a user's local
system. Most often, this information is used for customizing and retaining
a site's setting for a user across multiple sessions. By design, each site
should maintain its own cookies on a user's machine and be able to access
only those cookies.

By enticing the user to click on a special URL, web sites can gain
unauthorized access to user's cookies and potentially modify the values
contained in them. Since some web sites store sensitive information in a
user's cookies, it is also possible that personal information could be
exposed.

Microsoft is preparing a patch for this issue, but in the meantime,
customers can protect their systems by disabling active scripting. (The
FAQ provides systematic instructions for doing this). This will protect
against both the web-hosted and the mail-borne variants discussed above.
When the patch is complete, Microsoft will re-release this bulletin and
provide details on obtaining and using it.

DETAILS

Affected software:
 * Microsoft Internet Explorer 5.5
 * Microsoft Internet Explorer 6.0

Mitigating factors:
 * A user must first be enticed to a malicious web site or to open an HTML
e-mail containing the malformed URL.
 * Users who have applied the Outlook Email Security Update are not
affected by the HTML mail exploit of this vulnerability.
 * Users who have set Outlook Express to use the "Restricted Sites" Zone
are not affected by the HTML mail exploit of this vulnerability because
the "Restricted Sites" zone sets Active Scripting to disabled. Note that
this is the default setting for Outlook Express 6.0. Users of Outlook
Express 6.0 should verify that Active Scripting is still disabled in the
Restricted Sites Zone.

Patch availability:
Download locations for this patch.
A patch will be posted as soon as it is available.

What is the scope of this vulnerability?
A malicious web site with a malformed URL could read the contents of a
user's cookie that might contain personal information. In addition, it is
possible to alter the contents of the cookie. This URL could be hosted on
a web page or contained in an HTML email.

What causes the vulnerability?
The vulnerability results because of an unsafe handling of cookies across
IE zones.

How would an attacker carry out an attack using this vulnerability?
An attacker could attempt to maliciously exploit this vulnerability by
hosting a page with a maliciously crafted URL. They could also send the
victim an HTML email with a similarly crafted URL.

In the case where the attacker hosted a web page, would he have any way to
compel me to visit the site?
The attacker could not force you to visit his site. Instead, he would need
to entice you into performing some action that would cause you to visit
the site. There are, however, a variety of actions that could be used to
do this, from visiting a web site that would redirect you to the
attacker's, to opening an HTML e-mail that referenced the attacker's site.

In the case where the attacker sent me an HTML e-mail, would simply
opening the mail allow me to be attacked?
Yes. It is possible for an attacker to construct an HTML email in such a
way that it would exploit this vulnerability on opening the mail.

Why does changing my IE settings help protect me against a mail-borne
attack?
As we mentioned above, HTML e-mails are just web pages sent via e-mail.
Outlook uses the IE security architecture to limit what HTML e-mails can
do when opened. By default, Outlook 2002 opens all HTML e-mails in the
Restricted Sites Zone.

Is this a permanent change?
No. Microsoft is working to develop a patch that will eliminate the
vulnerability. When it is completed, you will be able to install the patch
and then return your IE settings to their previous values.

How likely is it that I could be affected by this vulnerability?
It depends on your web browsing and e-mail habits. Customers who exercise
care in choosing the sites they visit, and who are careful not to open
obvious spam and other untrustworthy e-mails would be at less risk from
this vulnerability. However, customers can easily make a configuration
change that will provide complete protection.

What is the configuration change that will protect against this
vulnerability?
Customers who are concerned about this vulnerability should disable active
scripting. All web pages (and HTML e-mails, which are just web pages
delivered via e-mail) are categorized into one of several zones, and the
settings in each zone dictate what actions can be taken within it. By
disabling active scripting in the Internet zone a user can prevent an
attacker from exploiting either the web-borne or mail-borne versions of
this attack.

How do I disable active scripting in Internet Explorer 5.5 and 6.0?
 * On the Tools menu, click Internet Options, click the Security tab, and
then click Custom Level.
 * In the Settings box, scroll down to the Scripting section, and click
Disable under "Active scripting" and "Scripting of Java applets".
 * Click OK, and then click OK again.

I am a network administrator. How can I disable active scripting in my
enterprise?
 * With new deployments of Internet Explorer, an administrator would use
the IEAK and disable active scripting before building the package and
rolling it out to client machines.
 * For currently deployed client use Profile Manager to create an
auto-config INS file to make registry changes needed to disable active
scripting on the client machines with Internet Explorer already installed.

 * For administrators that prefer to use SMS or login scripts, the
following are the registry changes that would disable active scripting on
the client machine:
    * HKLM\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones
    * HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones

     There are five different sub keys under each "Zones" key. Each key
control a different security zone. The key names are 0-4.

     0 = Your computer
     1 = Local Intranet
     2 = Trusted Sites
     3 = Internet
     4 = Restricted Sites

     There is then a DWORD value under each zone number key that must be
modified to disable active-scripting for each zone.
     REG_DWORD value is "1400" to be modified.
     Setting this value to "3" (from "0") will disable active scripting.
     HKCU setting changes take effect immediately. However, the HKLM
settings would most likely require a reboot.

ADDITIONAL INFORMATION

The information has been provided by <mailto:secnotif@MICROSOFT.COM>
Microsoft Product Security.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.



Relevant Pages

  • [UNIX] Path Disclosure and Cross Site Scripting Vulnerability in MyABraCaDaWeb
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... A security vulnerability found in this product allows full path disclosure ... and Cross Site Scripting attacks. ... A vulnerability in MyABraCaDaWeb allow attackers to determine the physical ...
    (Securiteam)
  • [NT] Intellisol XPede Exposes Passwords
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Intellisol XPede ... For vulnerability #1: ... Clear all cookies via MSIE "Tools/Internet Options/General/Delete Cookies" ...
    (Securiteam)
  • Re: Html injection/hacking, but what does it do? Any advice?
    ... I'm not very good on security, but from what I read, if you write scripts ... cross-site scripting, which is more serious than a bit of spam. ... someone enters a comment with the characters, ... I can't say for sure if you do have the vulnerability. ...
    (alt.html)
  • [Full-Disclosure] Re: MS Security Response is a bunch of half-witted morons
    ... More and more web sites don't work without scripting ... I guess cookies are a lesser evil. ... Your job is to improve security. ... >requires their readers to set their browsers to a configuration that is ...
    (Full-Disclosure)
  • [SCSA-013] Cross Site Scripting vulnerability in testcgi.exe
    ... Security Corporation Security Advisory ... "Ceilidh is a Web-based threaded discussion engine that features ... This kind of attack known as "Cross-Site Scripting Vulnerability" is ...
    (Bugtraq)