[cifs-protocol] [REG:111101553031054] SystemLibraryDTC

[Andrew Bartlett]

On Tue, 2012-06-12 at 15:56 +0000, Bryan Burgin wrote:
> [+Jay Simmons]
> 
> Hi Andrew.  We made some progress on this issue.  Below is the response from Jay Simmons who researched this for you.  Jay agreed to join this thread.
> 
> "Thanks for your extreme patience on this issue.    Your findings were correct – Windows servers up through Windows Server 2003 will attempt to use the well-known key “SystemLibraryDTC” to decrypt data, if no SMB session has been established for the incoming client (which is usually the case when invoking RPC calls over TCP).    Windows servers after WS03 behave only slightly better – for those OS versions, a “random” key will be used whose contents depend on memory\stack contents at the time the call is made.    While the server-side behavior is not ideal, the client must still first be authenticated and authorized for the operation (eg, password set) to be allowed.   Therefore the security vulnerability lies in the fact that the client chose to expose sensitive data to a potential wire-sniffing attack, by using an insecure means of making the call in the first place (this assumes that RPC-level transport security was not leveraged to protect the data).   Note that we explicitly document in MS-SAMR (see section 2.1) which calls must be made using RPC-over-SMB, at least in part for preventing exactly this problem.    No Windows client will ever invoke such a call (ie, one with SMB-session-key encrypted parameters) without an SMB session.    
> 
> "This probably goes without saying, but please do not attempt to rely on this behavior as it will likely be blocked at some point in the future.  
> 
> "Feedback welcomed, especially if you think we have misunderstood the security implications of the issue."

So, does this mean that the 'new' behaviour of
NT_STATUS_NO_USER_SESSION_KEY is due to the stack being co-incidentally
zero at this point, but that this might not always be the case?

If windows ever creates a privileged, unsigned lsa connection over TCP,
you could hijack it and use this to call querysecret to extract a secret
value from the DC 'unencrypted'. 

I guess it's a long shot (lots of other avenues for attack), but it's
one that might be possible. 

The annoying thing is that this issue *prevents* the use of RPC
transport layer security for the most sensitive operations.  I wanted to
sign certain privileged connections setting up trusts (to prevent
hijacking), but I can't as it means I have to use SystemLibraryDTC (and
expose the secret) and some servers may reject it anyway.  I also can't
seal because some servers will reject it as
NT_STATUS_NO_USER_SESSION_KEY.

It would actually be better if SystemLibraryDTC was abolished, and
replaced by the session key as used in DRSUAPI.  This would then allow
these calls to be made over secure RPC. 

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org