found somewhere on the net and wanted to share it with the community
here is the description:
CODE
When a Microsoft networking client creates a new connection to an NT Server, it is possible for another computer on the same physical network to `spoof' the Microsoft client into sending a clear-text password to the NT Server, bypassing all password encryption and allowing the client's clear-text password to be discovered by any other device on the same physical network.
This security hole is the result of several oversights in the Microsoft networking architecture, namely:
1. When creating new connections to NT Servers, clients can be instructed to use a particular authentication mechanism (clear-text or challenge/response). Thus, clients can be tricked into submitting their password as clear text.
2. If an NT Server requested an encrypted login from the client, it will authenticate the client if the client submits a valid clear-text password. There is no indication or audit trail on the NT Server to indicate that clients are using clear-text passwords even though the server has requested encrypted authentication.
As a result of this design, neither the client nor the server ever exhibit any significant problems during the client authentication. If a rogue client is able to attach to the physical network, it is possible for a small utility on the rogue client to silently listen for username/password pairs during user authentication. Note that physical access to the client or server is *NEVER* required, just access to the network between the client and the server.
The following example demonstrates this security hole.
Correct SMB authentication without spoofing:
Client Server
Request Authentication -> <- Use encryption Connect with encrypted pw -> <- Connection Successful
SMB authentication with spoofing:
Client Spoofing Computer Server Request Authentication -> <- No encryption <- Use encryption Connect with clear-text pw -> (Grab password) <- Connection successful
Microsoft is well aware of this `feature' - it was implemented in Microsoft Networking for backwards compatibility with older clients and servers that use SMB networking. In fact, Microsoft is proposing the ability to use clear-text passwords as an Internet standard as part of their Common Internet File System Protocol (CIFS) found on the www.microsoft.com at http://www.microsoft.com/intdev/cifs.
8.5.2 Downgrade attack
A "man-in-the-middle" can remove the bit in the SMB_COM_NEGPROT response that says the server supports challenge/response, thus fooling a client into thinking that it should supply a plaintext password. This attack can be mitigated if clients are able to be configured to require challenge/response, either in general or for particular servers.
Actually, this attack does not require a 'man-in-the-middle', rather just a single machine physically connected to the network anywhere between the client and the server. A single packet will trick the Microsoft client into sending its password as clear text. Unfortunately, there doesn't appear to be either registry keys or policies on either Windows 95 or Windows NT that allow an administrator to require challenge/response when accessing services. Since the client's default is to allow clear text passwords, all existing DOS, Windows 3.1, Windows for Workgroups, Windows 95, and Windows NT clients are susceptible to this attack.
MICROSOFT POTENTIAL SOLUTION
Microsoft could initially create a server patch that would not allow the NT Server to accept clear-text passwords. While this does not prevent the exposure of the clear-text password, at least the administrator would be alerted that clients were sending clear-text passwords when requested to send encrypted passwords ("You've just been hacked").
To completely resolve this issue, all Microsoft Networking clients must be replaced with new code that would never send clear-text passwords during the authentication process.
As long as Microsoft networking is enabled on any DOS, Windows 3.1, Windows for Workgroups, Windows 95, and Windows NT clients, customers are susceptible to disclosing their clear-text passwords to other devices on the physical network. Resolving this issue requires an administrator to update the Microsoft networking components on all affected desktops as soon as a fix is available from Microsoft.
USING THE CODE
This utility is 'proof of concept'. There is *NO GUARANTEE* as to the functionality of this code - I have only tested on Windows 95 and Window NT Workstation connecting to a NT Server 4.0 server via TCP/IP. Since this exploits a hole in SMB networking, other protocols (NETBEUI, IPX) as well as other platforms (DOS, Windows 3.1, WfW, OS/2, etc) are also vulnerable.
This utility uses Novell's 16-bit ODI protocol stack and any promiscuous mode ODI driver, such as 3c5x9.COM. Most modern ODI drivers include promiscuous mode support. Documentation for promiscuous mode and sending RAW packets through the ODI driver can be found on Novell's SDK CD-ROM in the unsupported area.
Requirements:
1. LSL.COM - download from Novell's web site or grab from your LAN diskette 2. Promiscuous mode ODI driver - i.e., NE2000.COM, 3C5X9.COM, etc. 3. A NET.CFG that includes the following statements:
Link Support buffers 20 1514
Link Driver (your driver name, such as 3C5X9) FRAME ETHERNET_II PROTOCOL IP 0800
The 'buffers 20 1514' creates packet receive buffers for use by the utility. The 'FRAME ETHERNET_II PROTOCOL IP 0800' tells the protocol stack to setup for the rights DSAP/SSAP on the IP frames. If you don't include either of these strings the code won't work.
i hope you enjoy
Thebass
May 8 2004, 09:51 AM
You can't do downgrade attacks on xp computer. only 2k and under.
thanks anyway
MKZEUDE
May 8 2004, 10:17 AM
thx
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
