Your best bet is to do a search of 'BrownOrifice' on:
securepoint.com/bugtraq/ or
www.securityportal.com/ or
www.securityfocus.com
Robert
- -
Robert P. MacDonald, Network Engineer
e-Business Infrastructure
G o r d o n F o o d S e r v i c e
Voice: +1.616.261.7987 email: [EMAIL PROTECTED]
>>> Dinesh_Kakkar <[EMAIL PROTECTED]> 9/1/00 1:35:34 PM >>>
>
>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
================================================================================
