COMMAND
Win95/98 SMB Authentication
SYSTEMS AFFECTED
Win9x
PROBLEM
Weld Pond from L0pht found following. Windows 95/98 network file
sharing reuses the cryptographic challenges used in SMB
challenge/response authentication. The reuse of the challenge
enables an attacker, who has captured a legitimate network
authentication, to replay the authentication and establish a
connection impersonating a valid user. During testing of the
L0phtCrack 2.5 SMB packet capture tool to capture SMB
challenge/response authentication, it became apparent to the
L0phtCrack development team that Windows 95/98 issues the exact
same challenge for each authentication for a period of
approximately 15 minutes. During this time an attacker can
connect to a network share as the user whose authentication was
captured. The attacker can connect to the Win95/98 share as that
user because the user name is transmitted in the clear as well as
the challenge. Although the attacker does not know the user's
password and therefore cannot generate the encrypted password
hash from it, the attacker does not have to. She merely replays
the encrypted hash that she captured. It will be correct because
the challenge hasn't changed and she is impersonating that
particular user. Reusing a challenge is a classic cryptographic
mistake. If the challenge was simply incremented this attack
would not be possible.
The following captures are in L0phtCrack 2.5 capture format
specified as:
DOMAIN\username:3:challenge:encrypted LANMAN hash:encrypted NTLM hash
The following 2 captures show an NT machine connecting to another
NT machine. The challenge is different, as it should be, for each
authentication.
DOMAIN\user:3:c21ee5e0c1a8ae89:626cc3ec9f8f1849bbd645541477be48bf261b486
9c36e7a:f9dfdb9ee9d1705a4fd45a0ed5f2c62e0c7a957860a59559
DOMAIN\user:3:ce16b6d32eee2e29:8f96e377f2b9670fa425c4e52ae4ae6ae3e23f693
d518719:d9a3180ce6e30f8a12d46703847147b70066dbaf9a5b654e
The following 2 captures show an NT machine connecting to a Win98
machine. Notice that the same challenge is issued each time.
DOMAIN\user:3:8f2eceae79b55000:43caa3ff5c793d04bbbe2332e8918bf80735b0100
89dc573:1c592e5dcf78cf658829d0cbe61c0e4c32b5ed7a87f5097e
DOMAIN\user:3:8f2eceae79b55000:43caa3ff5c793d04bbbe2332e8918bf80735b0100
89dc573:1c592e5dcf78cf658829d0cbe61c0e4c32b5ed7a87f5097e
This capture is another NT machine connecting to the same Win98
machine used above. Notice this is the same challenge as in the
previous 2 authentications.
DOMAIN\user:3:8f2eceae79b55000:43caa3ff5c793d04bbbe2332e8918bf80735b0100
89dc573:1c592e5dcf78cf658829d0cbe61c0e4c32b5ed7a87f5097e
As you can see from the last 3 captures, if the username and
challenge are the same then the encrypted hashes sent are the
same. An attacker could modify the unix Samba client to alter
the way it issues encrypted password hashes. It could be modified
to send a fixed encrypted password hash as entered by the attacker
instead of generating it based on a password and the challenge. In
this way the attacker could feed the output of an SMB packet
capture into a modified Samba client to make Win95/98 file share
connections from her machine. Once these connections are made,
interesting files could be read from or written to the Win95/98
machines. Files that could be written include those in the
Windows Startup folder which would enable programs to install
themselves to automatically execute on system startup.
SOLUTION
Nothing yet how to protect Win9x boxes. Its a pretty bad idea to
have a network of NT boxen where Win9x boxes are used as File
Servers in the first place. Since no auditing exists on the Win9x
boxes and securing them is pretty near impossible, having NT users
logging into them represents a significant threat to your NT
network. SP4 offers a method of prevent NT boxes from being able
to authenticate against Win9x resources, thereby eliminating this
threat (realize, of course, that doing this eliminates the
possibility of using Win9x as a server).