Re: Network File Resource Vulnerability

[dleblanc () MINDSPRING COM (David LeBlanc)]

At 01:12 AM 3/10/00 -0500, Eric Hacker wrote:

> Note: This vulnerability is not an entirely new discovery. A
> variation of this attack using only IE had been discussed as far
> back as 97 on the BugTraq and NTBugTraq lists. 

I thought it was at least 3 years old.  I believe you'll also find it on
the ISS ntsecurity mailing list archives as well.

> I have found it briefly mentioned in a book. 

If it is published in a book, then why do we have an 'advisory'?  What next
- POP3 sends passwords in clear text?

> The new issues are that:
> · The file:// tag as well as UNC \\ pathnames can be used.

This is not new.  I believe if you reference the original discussions,
you'll find this has been known all along.

> · This attack can easily be sent via email.

This isn't new, either.

> · Windows 2000 is vulnerable to this type of attack.

I suppose we could say that this is new, since Windows 2000 is new, though
this seems to be an odd definition of new to me.

> · There is not any way to configure this functionality or turn it
> off.

This is not true.  First of all, the type of authentication sent is a
function of the LMCompatibilitylevel  - see Q147706 for details.  This
regulates whether LM, NTLM, or NTLMv2 authentication is used.  Level 2 or
higher prevents the weaker LM hashes from being sent.  Note that Windows NT
does not send clear-text passwords, unless the user has intentionally
downgraded security, since prior to NT 4.0 SP3.  I would also note that if
a machine is not patched at SP3, then there are a number of other things
I'd be more worried about than this.

Furthermore, disabling the workstation service disables this attack
completely, and is a viable work-around for a home user with a single
system.  In addition, one can unbind NetBios from the TCP/IP stack entirely.

Another work-around that I strongly suggest (esp. for home systems) is to
simply remove the right to log on from the network from all users.  That
way, you can swipe my password, and it won't get you anywhere.

Still yet another work-around if you don't have anything you want shared on
your system is to turn off the server service - that also prevents an
attacker from using the credentials against your personal machine.

I'd also note that enabling SMB signing (also referenced in Q147706) will
cause this type of attack, as well as the loopback attack, to fail.

So there are several ways for a home user to protect themselves, and a
corporate user ought to be behind a firewall.  If you're worried about
internal attacks, this method leaves so many tracks that I don't think an
attacker would last long before getting removed.

> This will give the untrusted.net server:
> · The username currently logged on.
> · The machine or domain name the user authenticated to.

Which you can also normally get by running nbtstat -A on the IP address of
the machine of interest.

> · The encrypted LANMAN and NTLM hashes, or if W95 possibly the
> plain-text password (See below).

Assuming that no work-around has been applied.  To be precise, the
encrypted LM and NTLM hashes are not sent, rather the challenge encrypted
with these hashes is sent.

> This attack can be delivered by:
> · A web page, as an embedded link to a graphic or other resource
> on a page visited from a browser.

All of which leave tracks that can be traced to the attacker.

> · An HTML formatted email, as an embedded link to a graphic or
> other resource.

This is especially good at leaving tracks.

> The first attack is to hide a file:// or UNC link 

Yes, we've known this for several years.

> This may result in broken graphics displayed if the file is not
> retrieved. 

I believe there are demo sites out there that demonstrate this.  IIRC, one
of them even sent a predictable challenge, and had a dictionary that it
could look up the hash against.  I've lost the URL, since it was so long ago.

> Another way to prevent any errors from appearing is to set up the
> guest account with no password to allow anonymous access to the
> server. Windows will always try the cached credentials first. When
> the cached credentials fail, a server will silently allow
> anonymous access and deliver the file.

Please note that a simple "net use" at the command line will show exactly
where your attacker is.  I would advise that doing this is a really great
way to meet your local FBI agent.  They're typically very friendly, though,
and would most likely want to visit with you for quite some time.  They may
even offer to provide room and board at their place.

> Since most major mail programs on Windows support HTLM email using
> either the Netscape or IE engine for display, this same attack can
> be delivered by email. 

In which case your victim has an archived record of your attack for
possibly months.  Most reasonable mail filters available for either UNIX or
NT would be able to find and log strings consistent with this attack.  By
neccessity, the strings point back at your server.

> Windows 95 downgrading LANMAN authentication.
>
> According to Microsoft TechNet Bulletin Q165403, Windows 95
> versions up to and including OEM SR 2.1 can be tricked into
> downgrading authentication to plaintext passwords. 

Speaking of truly ancient - this one is also at least 3 years old.  Do a
search on c2myazz.  I think I've got it archived somewhere.

> There is an
> update for W95 available; see
> http://support.microsoft.com/support/kb/articles/Q165/4/03.ASP for
> details. 

Actually, that is out of date - see Q239869 for an update.

> Upgrade to or force NTLMv2 authentication for all clients.

> NTLMv2 raises the
> bar, but does not completely protect you.

At the moment, this one does pretty well.  There are no known, widely
available crackers for NTLMv2 - L0phtcrack, for example, only does LM and
NTLM right now.  This is not to imply that one cannot be built, merely that
I am not aware of any right now.

> Block all outgoing NetBIOS traffic at the firewalls.

> This will not protect you from those inside your network, but it
> will stop outsiders from getting any information. Everyone worries
> about inbound traffic, but many places don not consider outbound.
> Block TCP ports 138 and 139 for NetBIOS.

This has been recommended for some years (you may want to search archives
of either the firewall wizards mailing list, or the Great Circle firewall
mailing list), and was the original work-around posted.  I would note that
you have forgotten to list 137 UDP, and if you have Windows 2000 machines,
port 445 TCP is also something you should block.  Also note that 138
operates on UDP as well.  Unless there is a need for it, I would extend
this list to 135 TCP and UDP.  A good catch-all is 135-139 TCP/UDP + 445
TCP.  Additionally, logging outbound connection attempts to 139 may help
locate anyone attacking you.

> Disable NetBIOS on unneeded interfaces.

> This will protect some people some of the time. 

Actually, if you've disabled it, it stops this attack cold all of the time.

> Strong passwords that do not include common words but do contain
> punctuation, upper and lowercase letters and numerals are
> extremely hard to crack. All passwords should be the full 14
> available characters on Windows.

This is inaccurate.  Windows 2000 can use passwords of up to 127
characters, and if the password is 15 characters or longer, the LM hash
isn't even stored.

> Things that do not help:
> · Disable caching of logon information. Only applies between
> reboots.

This actually has nothing to do with what you cite.  This caches for local
logons in case you cannot find your domain controller (e.g., laptops on an
airplane).

>   There should be a registry key setting and Control Panel access
>   that disables the caching of logon credentials as soon as they
>   have been used to authenticate. Thus if I log into a domain,
> then
>   log into a non-member WorkGroup server, it will not send my
> domain
>   username and password to the non-member WorkGroup server
>   automatically without my consent. Ideally, it shouldn't even
> have
>   them hidden in memory somewhere to send.

This will cause an entirely broken system if used inside of a non-trivial
corporate network.

>   This will not only prevent the current exploits of file:// and
> UNC
>   \\ links, but future unknown attacks. It will also keep
>   trojans/virii from being able to exploit this overall weakness.

It also breaks a tremendous amount of functionality.

David LeBlanc
dleblanc () mindspring com