[NT] Java Applets Can be Used to Redirect Browser Traffic

From: support@securiteam.com
Date: 03/09/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Sat,  9 Mar 2002 00:17:59 +0100 (CET)

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

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Java Applets Can be Used to Redirect Browser Traffic
------------------------------------------------------------------------

SUMMARY

The Microsoft VM is a Java virtual machine for the Win32 operating
environment. It runs atop Microsoft Windows 95, Microsoft Windows 98,
Windows XP, and Windows ME. It ships as part of Windows 98, Windows 2000,
and Windows ME and as part of Internet Explorer 5.5 and earlier.

The version of the Microsoft VM that ships with Internet Explorer version
4.x and 5.x contains a flaw affecting how Java requests for proxy
resources are handled. A malicious Java applet could exploit this flaw to
re-direct web traffic once it has left the proxy server to a destination
of the attacker's choice.

An attacker could use this flaw to send a user's Internet session to a
system of his own control, without the user being aware of this. The
attacker could then forward the information on to the intended
destination, giving the appearance that the session was behaving normally.
The attacker could then send his own malicious response, making it seem to
come from the intended destination, or could discard the session
information, creating the impression of a denial of service. Additionally,
the attacker could capture and save the user's session information. This
could enable him to execute a replay attack or to search for sensitive
information such as user names or passwords.

A system is only vulnerable if IE is used in conjunction with a proxy
server. Users whose browsers are not behind a proxy server are not
vulnerable to this vulnerability. However, those users would be vulnerable
if they changed their browser to use a proxy server later.

DETAILS

Affected software:
Versions of the Microsoft virtual machine (Microsoft VM) are identified by
build numbers, which can be determined using the JVIEW tool as discussed
in the FAQ. The following builds of the Microsoft VM are affected:
 * All builds of the Microsoft VM up to and including build 3802.

Mitigating factors:
 * The vulnerability only affects configurations that utilize a proxy
server. Customers who are not using a proxy server are not at risk from
this vulnerability.
 * Best practices strongly recommend using SSL to encrypt sensitive
information such as user names, passwords and credit card numbers. If this
has been done, sensitive information will be protected from examination
and disclosure by an attacker exploiting this vulnerability.

Patch availability:
Download locations for this patch
Upgrade to Microsoft VM build 3805 or later at
<http://www.microsoft.com/java/vm/dl_vm40.htm>
http://www.microsoft.com/java/vm/dl_vm40.htm

What's the scope of the vulnerability?
This is session hijacking vulnerability. This vulnerability could allow a
maliciously crafted Java applet to silently re-route all browser traffic
to the applet's host without the user's knowledge. Once an attacker was in
possession of the re-routed browser traffic, he could take any action or
combination of actions of his choosing. This includes handling the browser
request, recording the session information, or forwarding the request on
to the intended destination. It is important to note that this capability
could allow a malicious party to record a user's session information and
possibly search for usernames, passwords, or credit card numbers sent in
clear text.

This vulnerability could only be exploited if Internet Explorer was
configured to access Internet resources via a proxy server. Users whose
browsers are not configured to use a proxy server are not at risk from
this vulnerability. Additionally, because secure HTTP (HTTPS) is encrypted
using SSL, any HTTPS traffic that was captured by an attack that exploited
this vulnerability would not readable in plain text. This means that
usernames and passwords sent using HTTPS are much less at risk than
information sent in plain text using HTTP. A malicious applet attempting
to exploit this vulnerability would be active until the browser's process
exited by exiting all open IE sessions.

What causes the vulnerability?
This vulnerability results from the way that certain requests for proxy
service in Java are handled. In configurations where IE is configured to
use proxy services, a particularly crafted Java program, sometimes called
an applet could exploit this vulnerability to forward browser traffic.

What is a Proxy Server?
A proxy server is a server that executes web requests on behalf of
clients, rather than having the client execute the request on its own. For
example, when a user requests a page from a site and the user's browser is
configured to use a proxy server, the browser contacts the proxy server
instead of contacting the site. The proxy server then passes the request
on to the site and receives the response. The proxy server then passes the
response back to the user's browser. Usually, a proxy is used as a gateway
between a private network, such as a corporate intranet and the public
Internet.

What's wrong with how IE handles Java requests through a proxy server?
There is a specific isolated issue with the way that Java requests are
handled when IE is configured to use a proxy server. A specially crafted
applet could cause the proxy server to send packets to a destination of
the attacker's choice rather than to the intended destination.

Is this a problem with Microsoft Proxy Server or Internet Security and
Acceleration Server 2000?
The vulnerability does not result from a problem with any proxy server.
The particular proxy server in use does not affect the scope of the
vulnerability. The issue relates to the way IE handles requests from Java
applets to use any proxy server.

How would someone exploit this vulnerability?
To successfully exploit this vulnerability, a malicious user would have to
develop a specially crafted Java applet and host it on their web site. To
exploit this vulnerability effectively, the user would have to maintain an
accessible site where he could re-direct the hijacked traffic.

What is Secure HTTP (HTTPS) and how does it protect me from this
vulnerability?
First, it is important to remember that HyperText Transfer Protocol (HTTP)
by design sends information in human-readable clear-text. This means that
if an attacker were able to examine the information sent back and forth
during your web session, he could read that information. If you included
usernames or passwords, he would be able to read that information.

Secure HTTP (HTTPS) addresses this issue by using Secure Sockets Layer
(SSL) encryption to obscure sensitive information. Information that is
sent using HTTPS is NOT in human readable form because it is encrypted.

Because this vulnerability can allow a malicious individual to redirect
web traffic to a site of his choosing, any sensitive information that is
in human-readable form would potentially be at risk. It is recommended as
a best practice that any sensitive information, such as user names,
passwords, and credit card numbers, be sent using HTTPS.

How can I know if I'm sending information using HTTP or HTTPS?
There are two ways to know for sure when you are using HTTPS rather than
HTTP. First, a small gold lock will appear in the lower right corner of
the IE window when your information is being sent using HTTPS. You can
also check to see that the URL shows HTTPS rather than HTTP.

What could someone do with this vulnerability?
This vulnerability could allow someone to redirect web traffic to a site
of his choosing. Because of this, there are several options available for
malicious use.
 * Potentially the most serious attack would be to forward traffic as
normal, giving the user no clue that his traffic was being redirected. The
malicious user could then capture the traffic and examine it for sensitive
information, such as passwords.
 * A malicious attacker could also choose to handle the redirected traffic
himself. Because the user would have no indication that their session had
been redirected, this would allow the malicious user to "spoof" the user's
intended session.
 * Finally, a malicious user could simply discard the redirected traffic,
creating a denial of service.

How long would the effect of exploiting the vulnerability last?
An attacker who exploited this vulnerability would be able to use this
vulnerability throughout a user's browsing session until the user closed
the browser. The user's full session after visiting the attacker's site
could potentially be "sniffed" by the attacker.

Could someone use this vulnerability to "sniff" other users' sessions?
No. The vulnerability only affects a user's own session. It cannot be used
to affect the session of any other user.

Could this vulnerability be exploited by accident?
No. The information required to exploit this vulnerability is very
specific and very unlikely to be used accidentally.

What does the updated Microsoft VM do?
The updated Microsoft VM eliminates the vulnerability by changing how
proxy requests from Java applets are handled. Once the updated VM is
installed and applied, malicious Java applets cannot redirect traffic.

How do I determine the build number for my version of the Microsoft VM?
 * Open a command window:
 * On Windows NT, Windows 2000, or Windows XP choose "Start", then "Run",
then type "CMD" and hit the enter key. On Windows 95,98, or ME , choose
"Start", then "Run" then type "COMMAND" and hit the enter key.
 * At the command prompt, type "JVIEW" and hit the enter key.
 * The version information will be at the right of the topmost line. It
will have a format like "5.00.xxxx", where the "xxxx" is the build number.
For example, if the version number is 5.00.1234, you have build number
1234.

ADDITIONAL INFORMATION

The information has been provided by <http://www.xs4all.nl/~harmwal/>
Harmen van der Wal.

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

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

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

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