Password Snatchers!

May 6, 1997 - 3pm CST \[NTSD\] - On the heals of April"s RedButton exploit comes yet another demonstration of attacking NT networks. A new program has just been released, complete with source code, that will downgrade a Server Message Block (SMB) negotiation - the standard handshake that occurs when a client attempts to connect to an NT Server. Downgrading the authentication causes the client to send its password in clear text, unencrypted - Ouch. This has been a known possibility for quite some time, however no one has released a working program along with source code up until now.

The program (located HERE) actually runs on a Windows based system loaded with Novell ODI style drivers running in promiscuous mode. Once active, the software listens for SMB negotiations, and upon detecting one, the software sends a single packet to the client instructing it to downgrade its connection attempt to a clear text level - at which point the client silently obeys by sending its password in clear readable text. Once this happens this little piece of software actually grabs the password as it travels over the wire and displays it on the screen. The client is successfully connected to the NT Server, and the user remains none-the-wiser that its password has just been grabbed.

Under Windows networking, when a client creates a new connection to an NT Server, the clients can be instructed to use a particular authentication mechanism: clear-text or challenge/response. As a result, clients can be instructed to transmit their password in clear text form very easily.

Furthermore, if an NT Server requested an encrypted login from the client, NT will authenticate the client, even if the client submits the password in clear text after being told to send an encrypted challenge/response answer. To make matters worse, there is no indication that this is taking place, and there is no way to provide an audit trail on the NT Server that indicates the clients are using clear-text passwords - even though the server has requested encrypted authentication. Perhaps NT should in fact be capable of logging an audit trail on this type of activity (hint hint).

A result of this design characteristic, a rogue client could sit on your network silently listening for username and password pairs traveling across the network during authentication. No physical access or user rights and permissions are required for this attack to work! All that"s need is a connection to your network between the clients and servers.

As I said, this type of SMB downgrade attack has been a known possibility for quite some time - as noted in the Common Internet File System (CIFS) specification (section 8.5.2) - and similar, although not quite the same types of exploits have been demonstrated recently by various college students attempting to show vulnerabilities in Internet Explorer and Windows NT. Previously, NT LAN Manager negotiation and hostile SMB servers were shown to effectively initiate, intercept, or intervene in certain aspects of the client/server authentication process.

The person bringing this new program to our attention, David Loudon, has suggested that, "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. 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, or Windows NT clients, users 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."

Microsoft is definitely aware of this issue, and it appears that this type of functionality was knowingly put in place in order to remain backward compatible with older Microsoft clients like DOS. As a result, don"t expect to see a fix for this until Service Pack 3 comes out, and maybe even later.

The new CIFS Authentication proposal seems to address this issue and a few other potential nasty security problems, but there is no guarantee the new CIFS specs will make it into SP3 yet. The probable outcome is that the new CIFS Authentication specification, which is being hashed out in a public forum on the Internet, will contain newfound configuration switches that can force the client and/or servers to require either clear text or encrypted negotiations.

You can monitor the progress of the CIFS Authentication proposal on Microsoft"s FTP site located HERE. This page also has instructions on joining the highly technical CIFS online forum if you want to take part in the ongoing proposal discussions.

Further Reading:
A Weakness in CIFS Authentication, by Dominique Brezinski
CIFS: Common Insecurities Fail Scrutiny, by Hobbit

Microsoft"s Response