---------- Forwarded message ----------
Date: Wed, 13 Sep 2000 15:13:29 -0500
From: monti <monti@USHOST.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: Win2k Telnet.exe malicious server vulnerability

Microsoft was informed of this problem (with exploit) over a month ago. I
received some token responses right after emailing them, but have heard
nothing since. If they have released an advisory of their own yet, I have
not seen it. I informed them up-front that I would release a
full-disclosure advisory of my own in 3 weeks time. They have had much
more than that to take action.

Problem:
========

Windows 2000's telnet client 'telnet.exe'  supports performing NTLM
authentication using the credentials of the logged in user. If it connects
to an NTLM enabled telnet server (i.e. a Win2k server with the MS provided
telnet service) it will automatically attempt to log in with the users
credientials without prompting them for any information.

The NTLM challenge/response protocol as others have shown, is vulnerable
to brute-force cracking. L0phtCrack, with it's "sniffed NT hash cracking"
capabilities is an excellent implementation.

This behavior is seen consistently in other Microsoft written clients. IE,
Netbios Workstation (i.e. windows itself over netbios), and probably
others have and/or do automatically authenticate the user with NTLM
(and sometimes other even worse schemes) without prompting them.

NTLM challenge/response is *NOT* an iron authentication scheme, MS! Stop
trusting it so much!

Vulnerability/Exploit Description:
==================================

In short, if you can get the user or his/her machine to telnet to you with
telnet.exe, you can get ahold of enough information to
perform a brute-force/dictionary crack on their password (and find our
their Domain if they are logged into one). Even if you arent going to
crack their password, you can get entirely too much information IMO.

During my tests I discovered that IE associates the telnet:// URL with the
vulnerable telnet.exe. This opens up several possible ways to force a user
into connecting to you with a malicious HTLM web page, email message, and
so on. I would speculate that it might also be possible to force this to
happen without user intervention with javascript/activeX/java or really
creative HTLM. I try really hard not to do HTLM/web-code anymore unless
it's really necessary so I didnt test this.

Also, since NTLM relies on the server "randomly generating" an 8-byte
challenge for the authentication, we can choose our own with the code
provided and use it to pre-compute a database of encrypted passwords to
avoid even having to crack them. Also attached is a really ugly bit of
code I hobbled together a while back that can be used to do this.

Please see the exploit for technical details. I hope the ntlm structures
and functions will be useful to others in the future on their own Windows
nt/2000 projects. I have used roughly the same routines for IIS/IE-ntlm
HTTP Auth code on Unix. Please note, this code will only work on intel or
other little-endian systems right now... I didnt get any architecture
dependent byte-order logic worked in yet.

Workaround/Fix:
===============

The NTLM functionality in telnet.exe is optional, but it is enabled by
default on all W2000 installations i've seen.

To turn of NTLM in telnet, just run 'telnet.exe' without arguments which
will get you into a cli for setting/unsetting variables and so on. Then
type 'unset NTLM'. This will disable all NTLM functionality in the client,
so... if for some really ill-advised reason you want or need this
function, you're out of luck unless Microsoft comes up with something
better.

Credits:
========

I should mention that I heard at DefCON that cDc/Newhackcity had
discovered and discussed this vulnerability during one of their
presentations that I missed. I did not colaborate with them on this and
had run across it myself before vegas, but Microsoft informed me that they
had also been contacted by cDc with the same bug.
I havent seen any material from them published yet though, so as far as I
know this is the first full public disclosure.

Other credits and thanks:

DMZ, Changeling, Brent, and Nate... thanks for your help testing and
playing with this in vegas.

Ronald Tschalar for his paper at:
http://www.innovation.ch/java/ntlm.html.
As you can see in my code, I definitely made use of some of his ideas.

Paul Ashton published an material based on this same stupid behavior in IE
3.0/4.0 back in 96/97 or so and his advisories helped get me thinking
about NTLM games to play in all the new protocols it's been implemented
in.
A copy of his advisory is at:
http://www.insecure.org/sploits/winnt.automatic.authentication.html