[REVS] Cross Site Cooking

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

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -



Cross Site Cooking
------------------------------------------------------------------------


SUMMARY

There are three fairly interesting flaws in how HTTP cookies were designed
and later implemented in various browsers; these shortcomings make it
possible (and alarmingly easy) for malicious sites to plant spoofed
cookies that will be relayed by unsuspecting visitors to legitimate,
third-party servers.

DETAILS

Many commercial websites may be attacked to overwrite or delete stored
preferences, session identifiers, authentication data, cart contents -
with results ranging from minor annoyances to a possibility of fraudulent
activity, depending on site design (bugs #1 and #2).

On sites where authentication data is tied on a server to a session ID,
the attacker may be able to acquire credentials by tricking the visitor to
authenticate within a session initiated by the attacker (bugs #1 and #2)

Some websites may be susceptible to malicious-activity-by-proxy attacks
(bug #3).

There is no immediate universal threat to life as we know it, but numerous
web scripts are an easy target of specific variants of the attacks
described below.

Discussion:
Let's begin with a quick primer on cookie parsing: when a new cookie is
issued to the browser (via "Set-Cookie" header in a HTTP response), the
server is expected to specify the domain and URI for which the cookie is
meaningful. This mechanism is present so that pages could limit the scope
of their cookies if needed, and prevent the data from being sent to
unrelated addresses in the same domain. For security purposes, the browser
will (theoretically) reject a cookie that is set for a domain that is
either defined too broadly, or does not match issuer's location at all.

(In other words, http://www.example.com/ may set a cookie that will be
sent to http://mail.example.com/, but not to http://forums.example.com/;
it cannot configure a cookie to be sent to all .com servers, nor to an
unrelated server, example.co.uk, however.)

Problem #1 - trouble with these pesky foreigners:
The mechanism for preventing overly relaxed cookie domain specification
seems to be broken in all major browsers. Some ancient documents invoke
the following flawed but <http://www.ciac.org/ciac/bulletins/i-034.shtml>
reasonable rule:

"Two dots are required if the top level domain is: .COM, .EDU, .NET, .ORG,
GOV, .MIL, or .INT. Three dots are required for any other domain. This is
to prevent the subdomain from being set to something like .COM, the
subdomain of all commercial machines."

This is repeated ad nauseam in various cookie tutorials and FAQs, but my
initial tests indicate that the rule is quite simply not true. Both MSIE
and Firefox seem to be perfectly happy with two-period ccTLDs domain
cookies (.xxx.xx).

In other words, one can set a cookie for *.com.pl or *.com.fr, and
override or corrupt credentials or other parameters on hundreds of
thousands e-commerce websites in that country. It will be also possible to
plant attacker's session ID on visitor's computer, and effectively, steal
his credentials when he decides to sign in on the target site.

Problem #2 - these cursed periods:
Another twist on the story is that there is no checking if there's
anything between periods in domain name - and extra trailing periods are
accepted by most resolvers as a way to override local domain search path.

One can set a cookie for ".com.", then bounce the visitor to
http://www.victim.com./ . This address differs from the "real" one, and
thus, unlike with #1, planted cookies would work only for this visit - but
the trailing "." is not an alarming pattern for most users. In fact,
seasoned users recognize it and sometimes purposefully append it - and as
such, they won't be tempted to be suspicious, and may interact with the
website (perhaps even authenticate within the session ID supplied by and
known to the attacker).

A surprise of sorts... I'm not the first person to spot this:
<http://www.nihongo.org/snowhare/utilities/triple_dot/>
http://www.nihongo.org/snowhare/utilities/triple_dot/ - credit goes to
Benjamin Franz... vendors were notified in 1998, and certainly are not in
a hurry to fix this.

All the verification of domain path is limited to client-side; when the
server receives a cookie ("Cookie" header in a HTTP request), there is no
information about the original issuer. It is assumed that the browser
behaves rationally, and is sending the cookie to a site or a set of sites
that previously issued it. The only other option is that the user
willingly tampered with the request, and is OK with any eventual
consequences of his actions.

This is a mistake.

Problem #3 - it's the address that counts:
The attacker may easily force random visitors to accept and relay
arbitrary cookies to a third-party site by a) setting up
http://example.com; b) issuing all visitors a cookie that mimics victim's
cookies, but is valid for *.example.com; c) setting IN A record for
evil.example.com to the IP address of its victim; d) redirecting users to
http://evil.example.com. This will cause visitor's browser to send
attacker's cookie to victim's server exactly as if it were a cookie
originally issued by the victim himself.

This trick alone does not compromise, disclose, erase, or supersede user's
settings should he later access the site through its proper address; and
since a bogus address is displayed in URL bar, the user is not tempted to
interact with the website. (There are some brain-damaged examples of
sessionID-in-URL redirects, but these have a fair share of other
problems.)

Michal does believe there is some risk, however: using this trick, a brand
new identity may be temporarily bestowed upon the user, and used to
perform certain undesirable or malicious tasks on the target site before
he has a chance to object (hiding attacker's identity or bypassing
IP-based limits). DDoS or session ID brute-forcing uses are also tempting.

That said, this alone is not a major problem for a well-designed website
and a savvy user; alas, websites should be designed with the knowledge of
this possibility; and further research on specific applications of this
technique to existing back ends might be quite valuable.

Solution:
Problem #1: There is no sane solution, other than altering HTTP cookie
format so that the server gets a chance to figure out who issued that
cookie in the first place. Workarounds by listing ccTLDs that use
xxx.xx/.xx.xx subdomains in the browser are better than nothing at all.

Problem #2: Browsers should strip "idle" periods in cookie domain data.
Browser vendors should take less than 8 years to address security
problems.

Problem #3: The immediate fix to this problem is requiring and carefully
validating HTTP/1.1 "Host" header on all requests (this ensures that the
browser's idea of who he's talking to matches the site's canonical name).


ADDITIONAL INFORMATION

The information has been provided by <mailto:lcamtuf@xxxxxxxxxxx> Michal
Zalewski.



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


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@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx


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

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