SMB Signing TODO
abartlet at samba.org
Sat May 10 00:40:58 GMT 2003
As I've noted in my previous message, we now have NTLMv2 working with
SMB signing. This is great progress, but does not help us with the next
NTLMSSP and Kerberos signing of SMB connections.
I've had a couple of offers of help on this already, however this stuff
is very complex. The assistance of somebody with a much better
knowledge of kerberos would also be very useful, as this will probably
be easier than the NTLMSSP stuff.
>From my previous mail:
> One of the features we would like to get for Samba 3.0 is SMB signing
> SMB Signing provides 2-way verification that the client and server are
> not being intercepted by a man-in-the-middle attack.
> Traditionally, this has not been a high priority for CIFS servers,
> particularly as it is thought to kill performance, and makes zero-copy
> techniques impossible.
> However, Microsoft clients and in particular Microsoft Win2003 servers
> will often require SMB signing on their connections. This is
> particularly important to them, because it has been realized that you
> can tamper with a 'group policy object' via simple SMB spoofing.
> Naturally, this has serious implications.
> So, there are very good reasons for Samba to support this, both as a
> client, and as a server. However, until now there was no good
> for what we do and don't know about SMB signing:
> Introductory Document
> Readers should read http://www.ubiqx.org/cifs/SMB.html#SMB.8 before
> NTLMSSP has a bit of documentation at:
> (this is a much earlier version, but it's a good start)
> Basic Terms
> LM authentication:
> - Authentication using the DES-based challenge-response and
> NTLM authentication:
> - Authentication using the DES-based challnege-response and the
> md4(unicode password) (the nt hash).
> NTLMv2 and LMv2 authentication:
> - Authentication using the newer MD5-base challenge-reposnse and the
> md4(unicode passsword) (the nt hash).
> - Microsoft's generalized 'blob based' encapsulation for
> - A common wrapping for this above encapsulation, which allows
> and the like to also be used.
> Session key:
> - A shared secret, based on the password that is given to the member
> server by the DC. This is used in the Signing code to prove that the
> message is authentic.
> What we do know
> SMB signing works, for authentication using the NTLM authentication
> scheme, when not using 'extended security'.
> We know how to obtain the session key from the domain controller, and
> know how to do both the client and server end. There is a client
> implementation in Samba 3.0.
Ethereal also decodes a lot of this - and the first step in any NTLMSSP
implementation would be to try and match Win2k's flags in the NTLMSSP
exchange. The problem is, we don't know how to support half the things
these flags indicate. It would also be possible to use smbfilter to
make win2k use less flags, and figure out how to go from there.
> What is just broken (we know what to do, just have not done it)
> SMB signing doesn't work for large data transfers, particularly as
> by the 'RW?' tests in smbtorture. This is due to the fact that there
> more than one outstanding packet, and we need to tie the expected
> response to the reply, not to the next packet we receive.
> Server-side 'basic' SMB signing would not be difficult,
> What is unknown
> We don't know how to do SMB signing with NTLMSSP - this means that in
> the default mode of operation, we can't sign our connection, and
> servers will reject us.
> We have had NTLMSSP code in Samba for a while, and I've tried to take
> the signing code from that older implementation and put it in
> libsmb/ntlmssp_sign.c, but I can't get it to work. Indeed, our basic
> negotation code in libsmb/ntlmssp.c won't even get a signed reply out
> Win2k. Win2003 gives us a signed reply, but not the one we expect.
> We also don't know how SMB signing works with kerberos. It has been
> noted that without a kerberos replay cache - and even with one -
> kerberos authentication and SMB are subject to very easy MITM attacks.
> Having gained the security of kerberos, it seems a pity to loose it
> again so quickly. If we knew how SMB signing was applied, we could
> solve this particular issue.
> If people have the time to attack some of this, I'll see what help I
> be. Mainly it needs time, research and a well-stocked test lab...
Andrew Bartlett abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030510/1a1a4a74/attachment.bin
More information about the samba-technical