Dear All
I would like to have your comments on this mail.
> 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?
>
>
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
