@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: 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.