Date:         Thu, 10 Aug 2000 09:04:32 +0200
From: "Greulich, Andreas" <Andreas.Greulich@ISB.ADMIN.CH>
Subject:      BrownOrifice can break firewalls!
To: BUGTRAQ@SECURITYFOCUS.COM

Hi all,

I am quite surprised about the low echo the newest bug in Netscapes Java
library (see http://www.brumleve.com/BrownOrifice/) receives. I am quite
worried about it because I think its impact is much higher than the
"WWW-server-applet" you find on above page. The WWW-server is a nice demo,
but for most users behind firewalls no real risk because the firewall will
usually block access from attackers to the victims browsers (ie his
"applet-server"). This can lead peopel to a dangerous feeling of security
though.

I am worried about a combination of a rogue applet and a rogue servlet (for
example CGI-script), both on the same server on the internet. The applet,
downloaded and started on a victims browser inside Intranet, assuming his
firewall allows him to receive Java applets, would build up a connection to
the rogue servlet implementing a kind of "reverse tunnel" similar to SSH.
This tunnel would principially receive a line from the rogue servlet,
interpreting this as URL by sending it through
netscape.net.URLConnection/URLInputStream. The result would be sent back to
the rogue servlet, then repeating these actions in an endless loop or until
the victim exits his browser. This way the servlet can use the tunnel to its
applet in order to read any file on teh victims machine without the firewall
being able to prevent it.

But it becomes worse... I tried these buggy Java methods and found that they
do not only work for accessing local files on the victims PC. Much worse,
they allow access to ANY URL (!) the victims browser can reach! In above
scenario, the rogue servlet would not only be able to read all files on the
victims machine, but freely surf inside the Intranet where the vicitm is
located. Regardless whether it is VPN-protected or whatever, the servlet
would see what the victims browser can see. It is easy to verify that:
Access above site, activate the rogue applet-server, conenct to it, but give
an URL instead of a filename (the Java applet actually takes care of it, it
doesn't prepend "file://" if you start the location with "http://",
"ftp://", etc - see its sourcefile BOHTTPD.java). Sor, try for example to
access "http://your.victim.browser:8080/http://www.your.intranet.server" and
you will see taht this way you can see what your victim browser sees. It is
not very useful per se, as you can usually see these machines anyway
(otherwise you could not connect to the victim browser). But if the rogue
applet initiated a tunnel as described above - and most firewalls would
allow this because it is outgoing - it DOEs become a problem. In short, it
would deactivate your firewall, the combination of rogue applet on your
Intranet victim machine plus rogue servlet on the Internet machine can work
as (reverse) proxy into your Intranet! Actually teh rogue servlet could
itself be combined with a WWW frontend allowing access to teh Intranet.

It even becomes worse than that - as if it were not bad enough. We are using
personal X.509 certificates in order to authenticate SSL connections. I'm
not speaking about standard server-authentication now; I am speaking about
client authentication, ie the scneario where your oersinal browser has a
personal certificate installed and uses this for authentication. These
certificates are still quite rare (estimated 2% of all SSL traffic), but
becoming important, for example for Internet banking. Private keys for
personal certificates are usually stored on your local disk, protected (ie
encrypted) by a passphrase. Netscape can be congigured in a way this
passphrase has only to be given once per Netscape session - it is then
cached for subsequent authentications, and Netscape performs these
automagically. Most peopel have this otpion activated. If they are very
security-concerned, they will use the option that asks again for the
passphrase after 30 minutes of not being used. Hardly anybody has it set up
in a way it is asked every time. It would be impractical to work with it
that way.

Now the problem is that, once your personal certificate is "opened" in above
way (so teh user entered it once and teh browser cached it), Netscape will
automagically use it again without informing the user - even if this request
is performed using netscape.net.URLConnetion/URLInputStream! Thsi means, the
rogue servlet does nto only see what the victims browser sees, but can also
authenticate itself in the same way teh victims browser could do on its
behalf without direct user interaction.

To try it out, make sure you have a browser with personal certificate
installed, passphrase, and set it up so that it asks only once a session for
it. Then use it to connect to a server that needs you to unlock the
certificate (ie enter passphrase), say "https://your.bank.com". Netscape now
keeps that in cache. Now get teh rogue applet mentioned above. Then go to
anotehr browser (liek starting the Explorer on your machine), and connect to
"http://your.victim.browser:8080/https://your.bank.com". And bingo, here you
are, and authenticated.

I think this problem needs more care and more pressure onto Netscape. The
only thing I can imagine is to turn off Java or replace it by anotehr
engine. I tried to disable all netscape.net.* methods in Netscapes
java40.jar file but did not succeeed (wrong digital signature then, of
course). Does anybody know an easy way how these methods could be blocked?

What can be done on the firewall? It seems Checkpoint can hardly block Java
without huge performance loss. Plus it would be quite a heavy measure...
blocking Java only for Netscape, or even block all Java applets that refer
to netscape.net.* methods would be an option - but are they feasible?

Any otehr ideas/suggestions?

             Andy