Re: TCP port 7 traffic from DoubleClick

["R. DuFresne" <dufresne () sysinfo com>]

Reposted from BugtraQ and related to this thread:

On Fri, 9 Jul 1999, Peter W wrote:

> As Netscape has not acknowledged my email or bug report from last week,
> and one form of this vulnerability is currently being used, I have decided
> it best to publicize this problem.
>
> SUMMARY
>
> This post describes a flaw verified in Netscape Communicator 4.6-0 as
> distributed by Red Hat software for x86 Linux and Communicator 4.51 and
> 4.61 for Windows NT. Communicator does not enforce "originating server"
> cookie restrictions as expected when JavaScript is enabled, leading to
> privacy issues for users who may think they have taken reasonable
> precautions.
>
> BACKGROUND
>
> Communicator 4.6 has a setting to warn before accepting cookies, and
> another to "Only accept cookies originating from the same server as the
> page being viewed". That latter option is supposed to, and used to,
> completely and quietly reject "DoubleClick" style third party ad cookies,
> i.e., cookies from servers that did not produce the main HTML document.
>
> These third party ad servers use cookies to track Web users as they move
> through completely unrelated Web sites. By accepting the cookie, one
> allows the third party to compile a profile of visits to other Web sites
> that use the third party's ad service (though normally the third party
> does not know the end user's exact identity).
>
> PROBLEM
>
> Last week I noticed a warning for a cookie (for doubleclick.net) not from
> the domain of the page I was viewing (newsalert.com) -- which the cookie
> settings should have rejected outright. If I turn off the warning,
> Netscape silently accepts the doubleclick cookie, although I still have
> the "originating server" restriction enabled.
>
> MEANS OF EXPLOIT
>
> The reason? I had JavaScript enabled for Web browsing. The offending
> newsalert page used a tag something like
>  <SCRIPT language="JavaScript1.1" SRC="http://ad.doubleclick.net/...";>
> and Communicator seems to interpret this as a "page" from doubleclick when
> it's only getting a snippet of JavaScript code.
>
> INTENT ?
>
> I have been in communication with DoubleClick on this issue. They raise
> credible reasons to justify using <SCRIPT> instead of simple <A><IMG>
> tags: preventing caching, and allowing the ability to use media other than
> simple images for their ads. Nevertheless, this technique does subvert
> user preferences, regardless of whether this was the original intent.
> DoubleClick does have an "opt out" program that sets a generic cookie to
> prevent further tracking; see http://www.adchoices.com/ for details.
>
> Newsalert management and web staff have not responded.
>
> COMPETING PRODUCTS
>
> Initial tests with Microsoft Internet Explorer 5.0 for Windows NT suggest
> that it does not have any option like Netscape's "originating server"
> restriction. By explicitly categorizing *.doubleclick.net in a zone like
> "Restricted sites" where all cookies are disabled, MSIE 5 will reject
> cookies offered by doubleclick.net <SCRIPT> tags; of course this must be
> done for each third party domain individually.
>
> WORKAROUNDS
>
> Concerned Netscape users should either turn on warnings and read notices
> carefully, disable JavaScript, or completely disable cookies.
>
> SUGGESTED FIX
>
> The cookie security mechanism should not accept <SCRIPT SRC="..."> as a
> valid "page" for the purpose of the cookie settings. Nor should it allow
> any similar means of bypassing the "originating server" restriction,
> including external CSS files[1], or other documents not of type text/html.
>
> For each rendered page, the domain of the main document's URL should be
> compared against the domains of any other supplemental pieces in deciding
> if those pieces qualify as "originating server" content.
>
> VENDOR RESPONSE
>
> While there has been no response from Netscape Communications, I am
> grateful for the prompt, polite responses of DoubleClick's employees;
> although I disapprove of their willfully continuing to use this technique,
> and their advocacy of unwieldy "opt-out" procedures.
>
> -Peter
>
> [1] By specifying a style sheet from a different domain with
>   <link rel="stylesheet" type="text/css" href="...">
> you can also sneak a cookie past the "originating server" restriction, but
> only if both style sheets and javascript are enabled.[2]
>
> Even better, you can set cookies for more domains with "Location:"
> redirects. E.G. "http://example.org/"; can have a URL like
> http://example.com/redirectPlusCookie in the LINK tag that issues a
> Set-Cookie and a Location header, redirecting the user to
> http://example.net/stylesheetPlusCookie. With JavaScript and CSS enabled,
> Netscape will accept cookies from both example.com and example.net.
>
> Or, a more vicious approach is to reference a URL on the same server which
> issues the redirect for the CSS or <SCRIPT> SRC to another domain. Users
> who look at the HTML source won't see anything unusual, but such
> redirections will also bypass the "originating server" setting.
>
> Finally, if you're not convinced of the problems, consider that these
> "originating server" tricks also work if you're viewing a file:// URL,
> even with a cookie-setting intermediate redirect.
>
> [2] Sorry, Netscape, I didn't tell you this last week because only now did
> I bother to test mechanisms other than the direct <SCRIPT> tag.
>
> The Intel Pentium III chip: designed to deny your privacy
> Boycott Intel. http://www.privacy.org/bigbrotherinside/

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        admin & senior consultant:  darkstar.sysinfo.com
                  http://darkstar.sysinfo.com

"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
                -- Johnny Hart

testing, only testing, and damn good at it too!