anonymizers+java+javascript.txt

1999-08-17T00:00:00
ID PACKETSTORM:11984
Type packetstorm
Reporter Packet Storm
Modified 1999-08-17T00:00:00

Description

                                        
                                            `Date: Tue, 13 Apr 1999 20:14:49 +0200  
From: Patrick Oonk <patrick@pine.nl>  
To: BUGTRAQ@netspace.org  
Subject: Serious security holes in web anonimyzing services  
  
>From: "Richard M. Smith" <smiths@tiac.net>  
Subject: Serious security holes in Web anonymizing services  
Date: Sun, 11 Apr 1999 19:23:25 -0400  
Newsgroups: comp.security.misc  
Organization: The Internet Access Company, Inc.  
  
Hello,  
  
I found very serious security holes in all of the major  
anonymous Web surfing services (Anonymizer, Aixs, LPWA, etc.).  
These security holes allow a Web site to obtain information about  
users that the anonymizing services are suppose to be hiding. This  
message provides complete details of the problem and offers  
a simple work-around for users until the security holes are  
fixed.  
  
The April 8th issue of the New York Times has an article  
by Peter H. Lewis in the Circuits section that describes  
various types of services that allow people to anonymously  
surf the Web. The article is entitled "Internet Hide and  
Seek" and is available at the NY Times Web site:  
  
http://www.nytimes.com/library/tech/99/04/circuits/articles/08pete.html  
  
(Note, this article can only viewed if you have a free  
NY Times Web account.)  
  
The three services described in the article are:  
  
Anonymizer (http://www.anonymizer.com)  
Bell Labs (http://www.bell-labs.com/project/lpwa)  
Naval Research Laboratory (http://www.onion-router.net)  
  
In addition, I found a pointer to fourth service in a security  
newsgroup:  
  
Aixs (http://aixs.net/aixs/)  
  
The best known of these services is the Anonymizer at  
www.anonymizer.com. However all four services basically  
work in the same manner. They are intended to hide  
information from a Web site when visited by a user. The  
services prevent the Web site from seeing the IP address,  
host computer name, and cookies of a user. All the services act  
as proxies fetching pages from Web sites instead of users  
going directly to Web sites. The services make the promise  
that they don't pass private information along to  
Web sites. They also do no logging of Web sites that  
have been visited.  
  
After reading the article, I was curious to find out how well  
each of these services worked. In particular, I wanted to  
know if it would be possible for a Web site to  
defeat any of these systems. Unfortunately, with less  
than an hour's worth of work, I was able to get all four  
systems to fail when using Netscape 4.5.  
  
The most alarming failures occurred with the Anonymizer and Aixs  
systems. With the same small HTML page I was able  
to quietly turn off the anonymzing feature in both services.  
Once this page runs, it quickly redirects to a regular  
Web page of the Web site. Because the browser is no  
longer in anonymous mode, IP addresses and cookies  
are again sent from the user's browser to all Web servers.  
This security hole exists because both services fail to properly  
strip out embedded JavaScript code in all cases from HTML  
pages.  
  
With the Bell Labs and NRL systems I found a different  
failure. With a simple JavaScript expression I was  
able to query the IP address and host name of the  
browser computer. The query was done by calling the  
Java InetAddress class using the LiveConnect feature  
of Netscape Navigator. Once JavaScript has this  
information, it can easily be transmitted it back to a  
Web server as part of a URL.  
  
A demo on the use of Java InetAddress class to fetch  
the browser IP address and host name can be found at:  
  
http://www.tiac.net/users/smiths/js/livecon/index.htm  
  
If you are a user of any these services, I highly recommend  
that you turn off JavaScript, Java, and ActiveX  
controls in your browser before surfing the Web.  
This simple precaution will prevent any leaks of  
your IP address or cookies. I will be notifying all 4 vendors  
about these security holes and hopefully this same recommendation  
will be given to all users.  
  
If you have any questions or comments, please send them via Email.  
  
Richard M. Smith  
smiths@tiac.net  
  
--  
Patrick Oonk - http://patrick.mypage.org/ - patrick@pine.nl  
Pine Internet B.V. Consultancy, installatie en beheer  
Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://www.pine.nl/  
-- Pine Security Digest - http://security.pine.nl/ (Dutch) ----  
Excuse of the day: bugs in the RAID  
  
---------------------------------------------------------------------  
  
[http://www.tiac.net/users/smiths/js/livecon/index.htm]  
  
<html>  
<head>  
<title>Using Java objects in JavaScript with Netscape's LiveConnect</title>  
<h3>Using Java objects in JavaScript with Netscape's LiveConnect</h3>  
<hr>  
<!-- Copyright (C) 1999 Richard M. Smith, All rights reserved -->  
</head>  
<body>  
  
<script src=../../utils/common.js>  
  
</script>  
  
<script>JSDirectoryLine("LiveConnect and Java objects");</script>  
  
<table border=1>  
<tr><th align=center> Expression </th><th align=center> Result </th><th align=center> Comments </th></tr>  
  
<script>  
  
evalTableEntry_IENA('mydate = new java.util.Date()', "Make a Java <i>Date</i> object");  
evalTableEntry_IENA('typeof(mydate)', "The type of a Java object is <i>object</i>");  
evalTableEntry_IENA('mydate.toString()', "Convert the <i>Date</i> to a string");  
evalTableEntry_IENA('typeof(mydate.toString())', "Oops, it's <b>not</b> a JavaScript string");  
evalTableEntry_IENA('mydate + ""', "Here is another approach to do a string conversion");  
evalTableEntry_IENA('typeof(mydate + "")', "This time we get a JavaScript string");  
evalTableEntry_IENA('mydate.getMonth()', "Get the month field of the <i>Date</i> object");  
evalTableEntry_IENA('typeof(mydate.getMonth())', "The getMonth() method returns a number as it should");  
evalTableEntry_IENA('java.net.InetAddress.getLocalHost().getHostAddress()', "Get the IP address of the local machine");  
evalTableEntry_IENA('java.net.InetAddress.getLocalHost().getHostName()', "Get the local machine name");  
  
</script>  
  
</table>  
<br>  
<script>DescStart();</script>  
<b>Note 1:</b> Becuase Internet Explorer 4 does not support LiveConnect,  
Java classes cannot be call directly from JavaScript. Instead, a Java applet  
must be created which exposes the various Java classes needed by JavaScript.  
The same Java applet can be used both with Interner Explorer 4 and Netscape  
Navigator.  
<p>  
<b>Note 2:</b> Java exceptions cannot be handled by JavaScript with LiveConnect.  
Java exceptions are reported by JavaScript as errors. A Java applet is required  
to be able to trap Java exceptions.  
<script>DescEnd();</script>  
</body>  
</html>  
  
--------------------------------------------------------------------------------------------  
  
http://www.wired.com/news/print_version/technology/story/19091.html?wnpg=all  
  
Anonymous Web Surfing? Uh-Uh  
by Chris Oakes - chriso@wired.com  
  
2:25 p.m. 13.Apr.99.PDT  
People who think they're cruising the Web in a stealth vehicle may find that their license plates are still showing.   
  
"Anonymizer" services admit that their attempts to protect individual Web identities aren't bulletproof, but say that browsing technologies should share the  
blame.   
  
Programmer Richard Smith, who has a history of poking holes in supposedly secure software programs, tested four anonymizer Web services and came away  
unimpressed. On Monday, Smith said that results revealed a variety of data leaks, causing him to worry that users might browse with a false sense of security.   
  
"I was surprised that companies who are in the computer security business have systems that are so easy to break," he said. "Even more surprising is that four  
vendors had a problem, not just one."   
  
The leaks provide clues to a user's identification, such as a numerical Internet, or IP, address.   
  
"I found very serious security holes in all of the major anonymous Web surfing services," Smith said. "These security holes allow a Web site to obtain information  
about users that the anonymizing services are supposed to be hiding."   
  
Representatives of the services acknowledge that security lapses occur, but argue that the browsing software is as much to blame as they are. They're quick to add  
that they patch holes when they can.   
  
Smith tested the Anonymizer, Aixs, the Lucent Personalized Web Assistant, and a US Navy-sponsored research project called the Onion Routing service.   
http://www.anonymizer.com/  
http://aixs.net/aixs/  
http://www.bell-labs.com/project/lpwa/  
http://www.onion-router.net/  
  
Although the characteristics of each service vary, they primarily use data-stripping and proxy-masking techniques to conceal key data that browser software can  
leave behind.   
  
The Anonymizer recently announced an anonymous forwarding service to help safeguard the identity of those filing unofficial and uncensored email reports from  
the fighting in Kosovo.   
http://www.wired.com/news/news/politics/story/18765.html  
  
The main purpose of all four services, though, is to keep a user's identity safe from the prying eyes of Web-site operators by preventing them from obtaining an IP  
address, a host computer's name, or browser cookies that tip off a return visit to a site.   
  
To hide these details, most services act as a kind of Web waystation between browsers and sites. The anonymizing services retrieve Web pages and deliver them to  
users instead of users fetching them directly.   
  
An operator at one service says that the weaknesses Smith points out are not entirely the fault of the anonymizer. Flaws in the software must take some blame,  
too.   
  
Using a test HTML page containing simple JavaScript code -- which could be posted on a site seeking to sniff out a user's identity -- Smith was able to quietly  
turn off the anonymizing feature in the Anonymizer and Aixs systems.   
  
No longer anonymous, the user's browser will resume the delivery of IP addresses and cookies to a Web site. Smith says that's due to the services failing to  
consistently filter embedded JavaScript code from a site's HTML code.   
Anonymizer CEO Lance Cottrell said that the company is responding to Smith's alert. But he said that to exploit the vulnerability, a site would have to be  
actively seeking to do so.   
  
"In any case, being bounced out of the Anonymizer would only show that the person had been there, but would not allow correlation with any postings," Cottrell  
said, adding that no anonymizer system can promise perfectly sealed identity.   
  
"The systems we are working with are simply too flexible, and allow things to be done in too many ways, for security to be perfect. We try to anticipate all the  
loopholes we can, then act like lightning when a unforeseen hole is reported."   
  
Attempts to reach representatives at the Aixs service were unsuccessful.   
  
With the Lucent Personalized Web Assistant and Onion Routing service, Smith found a different type of problem. "With a simple JavaScript expression, I was  
able to query the IP address and host name of the browser computer."   
  
Once JavaScript has this information, he said it can easily be transmitted it back to a Web server as part of a URL. He said that the same tests run with Internet  
Explorer 4.0 did not produce the same vulnerabilities.   
  
Jeremey Barrett, an engineer for the Onion Routing System, said that the problem lies with the browsers, not with anonymizer services like his. Browsers, he said,  
will surrender a user's IP address to sites that request it with JavaScript or ActiveX code.   
  
Browser manufacturers have released patches periodically as issues surrounding the acknowledged risks of executing JavaScript and ActiveX code have surfaced.   
  
"The only way to prevent this, regardless of the anonymizing system used, is to filter out the JavaScript code using some form of proxy," said Barrett.   
  
He also said that Onion Routing is not simply an anonymizer meant to keep an individual site from knowing who's visiting. "Rather, it's meant to prevent anyone  
else from knowing that you are talking to a particular Web server."   
  
"For example, you might log into your bank's Web site over the Onion Routing system. You would very definitely want the bank to know who you were, but you  
might not want anyone to know you were talking to your bank."   
  
For airtight Web browsing, any feature beyond basic HTML would have to be turned off in the browser; that's the nature of the approach taken by the  
Anonymizer as it strips out such code.   
  
Smith would like to see any anonymizer service provide both the proxy and the standard anonymizing service that strips data from a user's browsing trail.   
  
Meanwhile, anonymizing services should warn their users and fix the bugs. "Netscape should fix how it handles Java so that it doesn't leak people's IP address.  
This bug does not exist in IE4," Smith said. He reported the problem to Netscape last September, but said that the company still hasn't provided a fix.  
http://www.wired.com/news/news/technology/story/15285.html  
  
--------------------------------------------------------------------------------------------  
  
Date: Tue, 13 Apr 1999 21:06:08 -0400  
From: Avi Rubin <rubin@RESEARCH.ATT.COM>  
To: BUGTRAQ@netspace.org  
Subject: Bugs in anonymity services  
  
Just a quick response. I am one of the authors of the Crowds system.  
Your attacks do not mention Crowds, although that system was described  
in the Lewis article.  
  
In our original paper, which was published over a year ago, we mentioned  
the possibility of Java or Javascript attacks to compromise anonymity.  
Our system also avoids redirect attacks by filtering out meta refresh  
tags. I don't think that Crowds is vulnerable to any of the attacks you  
mention, as users are required (requested) to turn off all active  
content, such as Java, javascript, etc. and to proxy all services  
through the crowd (although not all are supported - they won't work, but  
they won't compromise anonymity).  
  
Unfortunately, we cannot ship our code outside of the US, but it is  
available for free non-commercial use in the US. The page is  
  
http://www.research.att.com/projects/crowds  
  
Avi  
  
--------------------------------------------------------------------------------------------  
  
Date: Tue, 13 Apr 1999 17:34:28 -0700  
From: Toby Barrick <tbarri@AMEX-TRS.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: Serious security holes in web anonimyzing services-non html  
  
Sorry for the dual post, the first was html format.  
  
This is more of a browser/Java issue. This not only affects annon  
sevices but proxy/firewall services also!!!  
  
Toby Barrick  
  
--------------------------------------------------------------------------------------------  
  
Date: Tue, 13 Apr 1999 23:56:25 -0500  
From: Jeremey Barrett <jeremey@TERISA.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: Serious security holes in web anonimyzing services  
  
On Tue, Apr 13, 1999 at 08:14:49PM +0200, Patrick Oonk wrote:  
> From: "Richard M. Smith" <smiths@tiac.net>  
> Subject: Serious security holes in Web anonymizing services  
> Date: Sun, 11 Apr 1999 19:23:25 -0400  
> Newsgroups: comp.security.misc  
> Organization: The Internet Access Company, Inc.  
>  
> I found very serious security holes in all of the major  
> anonymous Web surfing services (Anonymizer, Aixs, LPWA, etc.).  
> These security holes allow a Web site to obtain information about  
> users that the anonymizing services are suppose to be hiding. This  
> message provides complete details of the problem and offers  
> a simple work-around for users until the security holes are  
> fixed.  
  
(...)  
  
>  
> With the Bell Labs and NRL systems I found a different  
> failure. With a simple JavaScript expression I was  
> able to query the IP address and host name of the  
> browser computer. The query was done by calling the  
> Java InetAddress class using the LiveConnect feature  
> of Netscape Navigator. Once JavaScript has this  
> information, it can easily be transmitted it back to a  
> Web server as part of a URL.  
>  
> A demo on the use of Java InetAddress class to fetch  
> the browser IP address and host name can be found at:  
>  
> http://www.tiac.net/users/smiths/js/livecon/index.htm  
>  
> If you are a user of any these services, I highly recommend  
> that you turn off JavaScript, Java, and ActiveX  
> controls in your browser before surfing the Web.  
> This simple precaution will prevent any leaks of  
> your IP address or cookies. I will be notifying all 4 vendors  
> about these security holes and hopefully this same recommendation  
> will be given to all users.  
>  
  
I'm sorry, but this just isn't a "hole" or "failure" in Onion Routing (which  
I work on) or any other anonymizing service. It's a problem with  
Javascript/Java and ActiveX. The fact is that browsers don't consider IP  
addresses as private information, and IMO this needs to change, or at least  
be optional.  
  
I'll speak about Onion Routing since I don't know the Bell Labs system as  
well. Onion Routing is designed to prevent traffic analysis. It is _not_  
designed to prevent the client and server from communicating in any  
particular fashion they choose. If the client wants to give its IP, name,  
phone number, height, weight, or eye color to the server, that's its  
business, it is not the business of Onion Routing. There are many cases  
where one might want to share a real identity, or some pseudo-identity, with  
a server, but not want anyone in between to know you were talking to that  
server. Often this same functionality also prevents the server from knowing  
anything about the client, but that is not a requirement of the system.  
  
Onion Routing provides a network strongly resistant to traffic analysis in  
the face of formidable attacks. It prevents anyone other than A and B from  
knowing that A and B are communicating. It has nothing to do with what  
information A shares with B.  
  
That said, the Javascript thing is pretty annoying. This problem doesn't  
affect just anonymizing-service users, it also affects anyone behind a  
firewall or any sort of "internal network structure hiding" scheme. The fact  
that it's transparent to the user is a major issue. This is one to take up  
with the browser makers.  
  
It would be possible to use an HTTP proxy to filter the Javascript, of  
course, and that could be built into the Onion Routing proxy, but that's  
only a band-aid hack, and doesn't solve the core problem.  
  
Regards,  
Jeremey.  
--  
Jeremey Barrett <jeremey@terisa.com>  
GPG fingerprint = 7BB2 E1F1 5559 3718 CE25 565A 8455 D60B 8FE8 B38F  
  
--------------------------------------------------------------------------------------------  
  
Date: Thu, 15 Apr 1999 20:47:21 +0100  
From: Ben Laurie <ben@ALGROUP.CO.UK>  
To: BUGTRAQ@netspace.org  
Subject: Re: Serious security holes in web anonimyzing services  
  
Patrick Oonk wrote:  
> With the Bell Labs and NRL systems I found a different  
> failure. With a simple JavaScript expression I was  
> able to query the IP address and host name of the  
> browser computer. The query was done by calling the  
> Java InetAddress class using the LiveConnect feature  
> of Netscape Navigator. Once JavaScript has this  
> information, it can easily be transmitted it back to a  
> Web server as part of a URL.  
  
This is not news. We (Major Malfunction and I) pointed this hole out  
years ago (in Jan '97 to be precise; seems even longer):  
  
http://www.alcrypto.com/java/  
  
to quote the page: "Even the mighty anonymizer retires after  
the first round, nose bleeding and ego bruised." Well, you know, these  
guys with weird names like the flowery prose :-)  
  
Cheers,  
  
Ben.  
  
--  
http://www.apache-ssl.org/ben.html  
  
"My grandfather once told me that there are two kinds of people: those  
who work and those who take the credit. He told me to try to be in the  
first group; there was less competition there."  
- Indira Gandhi  
  
--------------------------------------------------------------------------------------------  
  
Date: Thu, 15 Apr 1999 22:49:04 +0100  
From: Chris Wilson <cmw32@CAM.AC.UK>  
To: BUGTRAQ@netspace.org  
Subject: Re: Serious security holes in web anonimyzing services-non html  
  
Greetings,  
  
On Sun, 11 Apr 1999, DaRk[V]0c wrote:  
> Let's say you have a network and a firewall which links this network to  
> the external world. In the anonymizer service, the proxy is OPTIONAL,  
> that is, packets do not necessarily have to go trough the proxy. In a  
> network-firewall case, packets MUST go trough the firewall. It's not  
> phisically on logically possible that packets go around that. Therefore,  
> the anonymizing service keeps still.  
  
What you say about the capabilities of the firewall is true, in the sense  
that the JavaScript exploits will reveal the firewall's address instead of  
the user's address. However, the Java exploit will execute on the user's  
machine, and hence know its IP address. This information CAN be passed  
back through the firewall.  
  
Many companies which use firewalls, also use non-routable addresses for  
the machines protected by them (such as 192.168.*.*). Such information is  
not very useful to a third party unless they can identify which network  
(e.g. the firewall's address) the internal address belongs to. Firewall  
address + user address is probably enough to identify an individual user  
in this case.  
  
However, from the descriptions of the exploits, the use of JavaScript (to  
obtain the firewall address) and the use of Java (to obtain the client  
address) appear to be mutually exclusive in some cases. In other cases, or  
with other services, they are not exclusive and it would be possible to  
obtain both.  
  
In any case it is simply impossible to be completely anonymous on the  
Internet, because packets must find some way to reach the client. The fact  
that anonymising services do not keep logs of their users, makes tracing  
significantly harder, but what if an anonymiser was hacked? The hacker  
would make light work of identifying individual users. IMHO, nobody should  
ever rely on being completely anonymous on the web.  
  
I agree with the original poster that anonymising services should remove  
all Java and JavaScript from all web pages. However, the way that these  
services work, relies on certain assumptions which may not always be true.  
A better way to run an anonymiser would be as a real proxy server, to  
ensure that all web transactions were required to pass through it, but  
this would be harder to configure and use.  
  
Ciao, Chris.  
___ __ _  
/ __// / ,__(_)_ | Chris Wilson <gcc@i.am> Unix+Net+SQL+Java+RC5 |  
/ (_ / ,\/ _/ /_ \ | Phone: England 01223 477360 (until June 1999) |  
\__//_/_/_//_/___/ | Pager: England 07654 336007 (until I lose it) |  
  
--------------------------------------------------------------------------------------------  
  
Date: Fri, 16 Apr 1999 20:23:20 +0100  
From: Ben Laurie <ben@ALGROUP.CO.UK>  
To: BUGTRAQ@netspace.org  
Subject: Anonymizer holes  
  
Ahem. M'learned friend has pointed out that the correct URL is  
http://www.alcrypto.co.uk/java/.  
  
Sorry 'bout that.  
  
Cheers,  
  
Ben.  
  
--  
http://www.apache-ssl.org/ben.html  
  
"My grandfather once told me that there are two kinds of people: those  
who work and those who take the credit. He told me to try to be in the  
first group; there was less competition there."  
- Indira Gandhi  
  
--------------------------------------------------------------------------------------------  
  
Date: Mon, 19 Apr 1999 14:54:10 -0500  
From: Jeremey Barrett <jeremey@TERISA.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: Serious security holes in web anonimyzing services  
  
On Thu, Apr 15, 1999 at 10:49:04PM +0100, Chris Wilson wrote:  
>  
> In any case it is simply impossible to be completely anonymous on the  
> Internet, because packets must find some way to reach the client. The fact  
> that anonymising services do not keep logs of their users, makes tracing  
> significantly harder, but what if an anonymiser was hacked? The hacker  
> would make light work of identifying individual users. IMHO, nobody should  
> ever rely on being completely anonymous on the web.  
>  
  
The goal of Onion Routing is to prevent this. An attacker controlling an  
onion router would not be able to discern who was doing what. The anonymizer  
is a "hide the client from the server" solution. Onion Routing is a "hide  
the fact that the client and server are communicating" solution, including  
>from individual onion routers. Onion Routing is a network, it isn't one site  
with the keys to everything. Read the stuff on http://www.onion-router.net/  
for more info.  
  
Regards,  
Jeremey.  
--  
Jeremey Barrett <jeremey@terisa.com>  
GPG fingerprint = 7BB2 E1F1 5559 3718 CE25 565A 8455 D60B 8FE8 B38F  
  
--------------------------------------------------------------------------------------------  
  
  
`