[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

UNIRAS Brief - 508/04 - Westpoint Security Advisory: Multiple Browser Cookie Injection Vulnerabilities



 
-----BEGIN PGP SIGNED MESSAGE-----

- ----------------------------------------------------------------------------------
   UNIRAS (UK Govt CERT) Briefing Notice - 508/04 dated 16.09.04  Time: 14:20 
  UNIRAS is part of NISCC (National Infrastructure Security Co-ordination Centre)
- ---------------------------------------------------------------------------------- 
  UNIRAS material is also available from its website at www.uniras.gov.uk and
         Information about NISCC is available from www.niscc.gov.uk
- ----------------------------------------------------------------------------------


Title
=====

Westpoint Security Advisory: Multiple Browser Cookie Injection Vulnerabilities

Detail
====== 

A design goal for cookies is to "prevent the sharing of session
information between hosts that are in different domains." It appears
current implementations are successful at allowing a domain to keep its
cookies private. However, multiple mechanisms have been discovered for one
domain to inject cookies into another. These could be used to perform
session fixation attacks against web applications.


Westpoint Security Advisory
- ---------------------------

Title:        Multiple Browser Cookie Injection Vulnerabilities
Risk Rating:  Low
Software:     Multiple Web Browsers
Platforms:    Unix and Windows
Author:       Paul Johnston <paul@xxxxxxxxxxxxxxxx>
              assisted by Richard Moore <rich@xxxxxxxxxxxxxxxx>
Date:         15 September 2004
Advisory ID#: wp-04-0001
URL:          http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt
CVE:          Multiple assigned, see main text

Overview
- --------

A design goal for cookies is to "prevent the sharing of session
information between hosts that are in different domains." It appears
current implementations are successful at allowing a domain to keep its
cookies private. However, multiple mechanisms have been discovered for one
domain to inject cookies into another. These could be used to perform
session fixation attacks against web applications.

Recommendations:
  * Affected browsers be patched for these vulnerabilities.
  * Web applications implement application layer mitigations for session
    fixation attacks, as described in [2].

Tested:
  Internet Explorer 6.0 for Windows 2000, all patches
  Konqueror 3.1.4 for SuSE 9.0
  Mozilla Firefox 0.9.2 for Windows 2000
  Opera 7.51 for Windows 2000


Cross-Domain Cookie Injection
- -----------------------------
Vulnerable:
  Konqueror             CAN-2004-0746
  Internet Explorer     CAN-2004-0866
  Mozilla               CAN-2004-0867
Not vulnerable:
  Opera

By default, cookies are only sent to the host that issued them. There is
an optional "domain" attribute that overrides this behaviour. For example,
red.example.com could set a cookie with domain=.example.com. This would
then be sent to any host in the .example.com domain.

There is potential for abuse here, consider the case where red.example.com
sets a cookie with domain=.com. In principle this would be sent to any
host in the .com domain. However [1] requires browsers to reject cookies
where:

  "The value for the Domain attribute contains no embedded dots"

This prevents a cookie being set with domain=.com. However, this does not
extend to country domains that are split into two parts. For example,
red.example.co.uk could set a cookie with domain=.co.uk and this will be
sent to all hosts in the .co.uk domain. Mozilla follows the RFC exactly
and is vulnerable to this. Konqueror and Internet Explorer have some
further protection, preventing domains of the following forms:

  * Where the 2nd level domain is two or fewer characters, i.e. xx.yy or
    x.yy
  * Domains of the form (com|net|mil|org|gov|edu|int).yy

This does prevent .co.uk cross domain cookie injection but does not
protect all domains. For example, the following .uk domains are
unprotected:

  .ltd.uk
  .plc.uk
  .sch.uk
  .nhs.uk
  .police.uk
  .mod.uk

When testing with Opera, it appeared that browser always correctly
detected the domain. It is not immediately clear how Opera does this
check.

Example exploitation:
  1) http://example.ltd.uk/ is identified for attack. It uses the "sid"
     cookie to hold the session ID.
  2) Attacker obtains attacker.ltd.uk domain
  3) User is enticed to click link to http://attacker.ltd.uk/
  4) This site sets the "sid" cookie with domain=.ltd.uk
  5) When user logs into example.ltd.uk, they are using a sesion ID known
     to the attacker.
  6) Attacker now has a logged-in session ID and has compromised the
     user's account.

Exploitation is dependent on the user clicking an untrusted link. However,
it is fundamental to the use of the web that we do sometimes click
untrusted links. This attack can happen regardless of the use of SSL.


Cross Security Boundary Cookie Injection
- ----------------------------------------
Vulnerable:
  Internet Explorer     CAN-2004-0869
  Konqueror             CAN-2004-0870
  Mozilla               CAN-2004-0871
  Opera                 CAN-2004-0872

By default cookies are sent to all ports on the host that issued them,
regardless of whether SSL is in use. There is an optional "secure"
attribute that restricts sending to secure channels. This prevents secure
cookies leaking out over insecure channels. However, there is no
protection to prevent cookies set over a non-secure channel being
presented on a secure channel. In general to maintain proper boundaries
between security levels, it is necessary to defend against both attacks -
protecting both confidentiality and integrity.

Example exploitation:
  1) https://example.com/ identified for attack, which uses "sid" cookie
     as session ID.
  2) User is enticed to click link to http://example.com/
  3) By some mechanism the attacker intercepts this request and sets the
     "sid" cookie
  4) When user logs into https://example.com/ they are using a sesion ID
     known to the attacker.
  5) Attacker now has a logged-in session ID and has compromised the
     user's account.

In addition to the user clicking an untrusted link, exploitation is
dependent on the attacker tampering with non-SSL network traffic. This is
a reasonable assumption as the purpose of SSL is to provide security over
an insecure network.


References
- ----------

[1] RFC2965 - HTTP State Management Mechanism
    http://www.ietf.org/rfc/rfc2965.txt

[2] Session Fixation Vulnerability in Web-based Applications
    http://www.acros.si/papers/session_fixation.pdf

[3] Persistent Client State - HTTP Cookies
    http://www.netscape.com/newsref/std/cookie_spec.html

[4] Cookies and Cookie Handling in Opera 7 Explained
    http://o.bulport.com/index.php?item=55


History
- -------

16 July 2004      Vulnerabilities discovered

20 July 2004      Vendors informed

20 July 2004      Mozilla bug opened

  http://bugzilla.mozilla.org/show_bug.cgi?id=252342

  The discussion shows that the cross domain problem is a long standing
  known bug. However, one contibutor claimed the exploit is being used in
  the wild. Several fixes were suggested and it appears this bug will be
  addressed soon.

  No discussion of the SSL vs non-SSL problem.

21 July 2004      Opera respond

  The response explains that they take the cross domain problem seriously,
  and that they have solved it by doing a DNS lookup on the specified
  domain. Some information is available in [4].

  They also explained that they could not solve the cross security
  boundary problem without breaking standards and existing web apps.

  This problem has previously been reported as the "Cookie Monster bug"
  http://www.securiteam.com/exploits/Cookie_Monster_vulnerability.html

23 July 2004      Konqueror respond

  Explain that they intend to fix the cross domain problem by including a
  list of ccTLDs that, like .uk, require 3 dots. The domain are:

    name,ai,au,bd,bh,ck,eg,et,fk,il,in,kh,kr,mk,mt,na,
    np,nz,pg,pk,qa,sa,sb,sg,sv,ua,ug,uk,uy,vn,za,zw

  The brief discussion of the cross security boundary suggests they do not
  consider it possible to solve at this time.

23 Aug 2004       KDE Security Advisory released

  http://www.kde.org/info/security/advisory-20040823-1.txt

  KDE issue an advisory stating the cross-domain problem is fixed in KDE
  3.3. Patches are also available for older 3.x versions.

13 Sept 2004      Vendors notified of impending release

14 Sept 2004      CVE candidates assigned for other issues

15 Sept 2004      Microsoft respond

  Best practice for web sites to resist session fixation attacks is to
  change the session ID after authentication. They are looking at ways to
  address this in the browser. As this may cause compatibility issues and
  the issue is low risk, they have not commited to a timeline.

15 Sept 2004      Advisory published


Thanks
- ------

Many thanks to the vendors for their responses. Also, thanks to Steven
Christey for assigning CVE numbers.

NISCC Response Group Comment:
NISCC has become aware of an issue affecting several popular web browsers that affects
the handling of cookies in your domain. The issue is that some browsers do not handle
domain names which have more than two level correctly, so that good.com would be treated
correctly but good.co.uk may be treated as if "co" were the subdomain. Hence it is possible
that cookies set by good.co.uk could be read by evil.co.uk if the user visited the evil.co.uk
web site. There could be potential breaches of privacy and, if cookies were used for 
authentication, of confidentiality and integrity. A public announcement will be made by the
discoverer in the next few days we believe, but system administrators should check that all
owners of subdomains are trusted or that cookies are not used in your domain. These measures
will provide some mitigation against cookie access, but can not prevent the exploitation of 
cross-site scripting vulnerabilities in trusted subdomains from giving access to cookies
from other trusted subdomains. Domain owners are advised to check their web pages to ensure
that all scripts validate input to disallow user input being executed.


- ----------------------------------------------------------------------------------

For additional information or assistance, please contact the HELP Desk by 
telephone or Not Protectively Marked information may be sent via 
EMail to: uniras@xxxxxxxxxxxx

Office Hours:
Mon - Fri: 08:30 - 17:00 Hrs
Tel: +44 (0) 870 487 0748 Ext 4511
Fax: +44 (0) 870 487 0749

Outside of Office Hours:
On Call Duty Officer:
Tel: +44 (0) 870 487 0748 and follow the prompts

- ----------------------------------------------------------------------------------
UNIRAS wishes to acknowledge the contributions of Westpoint for the information 
contained in this Briefing. 
- ----------------------------------------------------------------------------------
This Briefing contains the information released by the original author. Some 
of the information may have changed since it was released. If the vulnerability 
affects you, it may be prudent to retrieve the advisory from the canonical site 
to ensure that you receive the most current information concerning that problem.

Reference to any specific commercial product, process, or service by trade 
name, trademark manufacturer, or otherwise, does not constitute or imply 
its endorsement, recommendation, or favouring by UNIRAS or NISCC.  The views 
and opinions of authors expressed within this notice shall not be used for 
advertising or product endorsement purposes.

Neither UNIRAS or NISCC shall also accept responsibility for any errors 
or omissions contained within this briefing notice. In particular, they shall 
not be liable for any loss or damage whatsoever, arising from or in connection 
with the usage of information contained within this notice.

UNIRAS is a member of the Forum of Incident Response and Security Teams (FIRST) 
and has contacts with other international Incident Response Teams (IRTs) in 
order to foster cooperation and coordination in incident prevention, to prompt 
rapid reaction to incidents, and to promote information sharing amongst its 
members and the community at large. 
- ----------------------------------------------------------------------------------
<End of UNIRAS Briefing>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQCVAwUBQUmRZYpao72zK539AQFnsgP7B+4cEVGc7r5i5r+7dvPTwuexnp5zQd6k
WCcOdYG3wogn4dkLsNxZ5+2r+9Vm0WYe7ZOHZHyXsqo2CAB8xGfBhNNh3MfCDmYS
DrHg8Iw5cv+r+toSgqaZrIiqpHHKT3/mFXl/G6aQmuxk+s9mFuqKwUjb2yQsr5vX
/MJd5aFjpXs=
=btQp
-----END PGP SIGNATURE-----