Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
Please let me know if there are any other questions - otherwise I'll be resolving the issue as resolved from our side. Thanks! - Jay -Original Message- From: Jay Simmons Sent: Wednesday, June 20, 2012 8:35 AM To: 'Andrew Bartlett'; Bryan Burgin Cc: 'cifs-protocol@cifs.org'; MSSolve Case Email; Tarun Chopra Subject: RE: [cifs-protocol] [REG:01553031054] SystemLibraryDTC * 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? Yes that is mostly correct. To be completely accurate: the stack buffer in question on WS08 and later is not explicitly or implicitly zero’d – it’s actually an uninitialized buffer filled with semi-random stuff from previous stack call frames. (The buffer contents might still be semi-predictable for some OS versions\architectures, so it doesn't change the discussion that much.) * 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. Yes anything is possible but this also seem likes a long shot to me. The Windows client-side code is hard-coded to always use SMB not TCP - so it would be hard to subvert a Windows client machine into using TCP in such a situation unless the client machine was already compromised.And the client still needs to be authorized to perform the operation in the first place, so a compromised client doesn't need to resort to such trickery - it could just call the DC in the normal fashion and unencrypt the results. * 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. I understand the annoyance factor and the appeal of being able to securely call these methods over TCP – but these protocols were designed and written to be used only over SMB, so calling them over TCP is basically non-tested and non-supported.“SystemLibraryDTC” really just an artifact of the local LRPC implementation that was never intended to be externally visible (and would not be except for a Windows bug).To be honest, we are not investing much time in MS-SAMR; my recommendation would be to use LDAP which is a much more modern and flexible protocol, and does not suffer from such historical MS-SAMR\SMB limitations. Do you have any other questions around this issue? Thx, Jay Simmons -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Friday, June 15, 2012 5:33 AM To: Bryan Burgin Cc: Jay Simmons; 'cifs-protocol@cifs.org'; MSSolve Case Email; Tarun Chopra Subject: RE: [cifs-protocol] [REG:01553031054] SystemLibraryDTC On Tue, 2012-06-12 at 15:56 +, 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
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
Thank you Jay for all the research on this. Go ahead and close this out. Andrew, please let us know if you need anything further. If you do, we can re-open the issue. Bryan -Original Message- From: Jay Simmons Sent: Thursday, June 28, 2012 1:12 PM To: Andrew Bartlett; Bryan Burgin Cc: 'cifs-protocol@cifs.org'; MSSolve Case Email; Tarun Chopra Subject: RE: [cifs-protocol] [REG:01553031054] SystemLibraryDTC Please let me know if there are any other questions - otherwise I'll be resolving the issue as resolved from our side. Thanks! - Jay -Original Message- From: Jay Simmons Sent: Wednesday, June 20, 2012 8:35 AM To: 'Andrew Bartlett'; Bryan Burgin Cc: 'cifs-protocol@cifs.org'; MSSolve Case Email; Tarun Chopra Subject: RE: [cifs-protocol] [REG:01553031054] SystemLibraryDTC * 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? Yes that is mostly correct. To be completely accurate: the stack buffer in question on WS08 and later is not explicitly or implicitly zero’d – it’s actually an uninitialized buffer filled with semi-random stuff from previous stack call frames. (The buffer contents might still be semi-predictable for some OS versions\architectures, so it doesn't change the discussion that much.) * 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. Yes anything is possible but this also seem likes a long shot to me. The Windows client-side code is hard-coded to always use SMB not TCP - so it would be hard to subvert a Windows client machine into using TCP in such a situation unless the client machine was already compromised.And the client still needs to be authorized to perform the operation in the first place, so a compromised client doesn't need to resort to such trickery - it could just call the DC in the normal fashion and unencrypt the results. * 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. I understand the annoyance factor and the appeal of being able to securely call these methods over TCP – but these protocols were designed and written to be used only over SMB, so calling them over TCP is basically non-tested and non-supported.“SystemLibraryDTC” really just an artifact of the local LRPC implementation that was never intended to be externally visible (and would not be except for a Windows bug).To be honest, we are not investing much time in MS-SAMR; my recommendation would be to use LDAP which is a much more modern and flexible protocol, and does not suffer from such historical MS-SAMR\SMB limitations. Do you have any other questions around this issue? Thx, Jay Simmons -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Friday, June 15, 2012 5:33 AM To: Bryan Burgin Cc: Jay Simmons; 'cifs-protocol@cifs.org'; MSSolve Case Email; Tarun Chopra Subject: RE: [cifs-protocol] [REG:01553031054] SystemLibraryDTC On Tue, 2012-06-12 at 15:56 +, 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
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
* 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? Yes that is mostly correct. To be completely accurate: the stack buffer in question on WS08 and later is not explicitly or implicitly zero’d – it’s actually an uninitialized buffer filled with semi-random stuff from previous stack call frames. (The buffer contents might still be semi-predictable for some OS versions\architectures, so it doesn't change the discussion that much.) * 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. Yes anything is possible but this also seem likes a long shot to me. The Windows client-side code is hard-coded to always use SMB not TCP - so it would be hard to subvert a Windows client machine into using TCP in such a situation unless the client machine was already compromised.And the client still needs to be authorized to perform the operation in the first place, so a compromised client doesn't need to resort to such trickery - it could just call the DC in the normal fashion and unencrypt the results. * 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. I understand the annoyance factor and the appeal of being able to securely call these methods over TCP – but these protocols were designed and written to be used only over SMB, so calling them over TCP is basically non-tested and non-supported.“SystemLibraryDTC” really just an artifact of the local LRPC implementation that was never intended to be externally visible (and would not be except for a Windows bug).To be honest, we are not investing much time in MS-SAMR; my recommendation would be to use LDAP which is a much more modern and flexible protocol, and does not suffer from such historical MS-SAMR\SMB limitations. Do you have any other questions around this issue? Thx, Jay Simmons -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Friday, June 15, 2012 5:33 AM To: Bryan Burgin Cc: Jay Simmons; 'cifs-protocol@cifs.org'; MSSolve Case Email; Tarun Chopra Subject: RE: [cifs-protocol] [REG:01553031054] SystemLibraryDTC On Tue, 2012-06-12 at 15:56 +, 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
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
On Tue, 2012-06-12 at 15:56 +, 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 Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
[+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. Please let us know your feedback. Bryan -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Sunday, February 12, 2012 10:36 PM To: Bryan Burgin Cc: 'cifs-protocol@cifs.org'; MSSolve Case Email; Tarun Chopra Subject: RE: [cifs-protocol] [REG:01553031054] SystemLibraryDTC On Mon, 2012-02-13 at 06:21 +, Bryan Burgin wrote: Andrew, I'm touching base to see if you can provide the exact smbtorture steps to reproduce your issue. bin/smbtorture ncacn_np:win2003r2-2[seal] rpc.lsa.secrets -Uadministrator%penguin win2003r2-2 is naturally a win2003r2 server, currently not a DC. I note with interest that this test fails with NO_USER_SESSION_KEY in win2k8r2, so I would like to know when this was changed and any important details, so we on the Samba Team can assess removing SystemLibraryDTC eventually. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
Andrew, I'm touching base to see if you can provide the exact smbtorture steps to reproduce your issue. Bryan -Original Message- From: Bryan Burgin Sent: Tuesday, February 07, 2012 10:00 AM To: Andrew Bartlett Cc: cifs-protocol@cifs.org; MSSolve Case Email; Tarun Chopra Subject: RE: [cifs-protocol] [REG:01553031054] SystemLibraryDTC Also adding Tarun. Neil is working with smbtorture to repro this issue. Can you explain more about the exact setup. Anything special required (a special build of smbtorture? Samba 3 or 4?)? What are the exact parameters required? B. -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Thursday, February 02, 2012 1:10 AM To: Bryan Burgin Cc: cifs-protocol@cifs.org; MSSolve Case Email Subject: Re: [cifs-protocol] [REG:01553031054] SystemLibraryDTC On Mon, 2012-01-30 at 22:05 +, Bryan Burgin wrote: Andrew, I'm working with Neil and others here. Can you tell us how to repro this issue in-house? Wasn't that what we started this thread with? https://lists.samba.org/archive/cifs-protocol/2011-November/002213.html -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
On Mon, 2012-02-13 at 06:21 +, Bryan Burgin wrote: Andrew, I'm touching base to see if you can provide the exact smbtorture steps to reproduce your issue. bin/smbtorture ncacn_np:win2003r2-2[seal] rpc.lsa.secrets -Uadministrator%penguin win2003r2-2 is naturally a win2003r2 server, currently not a DC. I note with interest that this test fails with NO_USER_SESSION_KEY in win2k8r2, so I would like to know when this was changed and any important details, so we on the Samba Team can assess removing SystemLibraryDTC eventually. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
Also adding Tarun. Neil is working with smbtorture to repro this issue. Can you explain more about the exact setup. Anything special required (a special build of smbtorture? Samba 3 or 4?)? What are the exact parameters required? B. -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Thursday, February 02, 2012 1:10 AM To: Bryan Burgin Cc: cifs-protocol@cifs.org; MSSolve Case Email Subject: Re: [cifs-protocol] [REG:01553031054] SystemLibraryDTC On Mon, 2012-01-30 at 22:05 +, Bryan Burgin wrote: Andrew, I'm working with Neil and others here. Can you tell us how to repro this issue in-house? Wasn't that what we started this thread with? https://lists.samba.org/archive/cifs-protocol/2011-November/002213.html -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
Andrew, I'm working with Neil and others here. Can you tell us how to repro this issue in-house? Bryan -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Friday, January 27, 2012 12:45 PM To: Bryan Burgin Cc: cifs-protocol@cifs.org; MSSolve Case Email Subject: RE: [REG:01553031054] [cifs-protocol] SystemLibraryDTC On Fri, 2012-01-27 at 17:20 +, Bryan Burgin wrote: Andrew, We completed our investigation to this issue and propose the following changes to [MS-DTYP], [MS-LSAD], [MS-SAMR] and [MS-WKST]. The text below contains yellow highlighting to identify changed text. If the highlighting causes a problem for you, please let me know. The proposed text keeps referring to an Anonymous session key, but this happens when the user is authenticated at the DCE/RPC pipe level. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
Andrew,
We completed our investigation to this issue and propose the following changes
to [MS-DTYP], [MS-LSAD], [MS-SAMR] and [MS-WKST]. The text below contains
yellow highlighting to identify changed text. If the highlighting causes a
problem for you, please let me know.
Thank you for your patience.
Bryan
[MS-DTYP]
Added new section:
2.3.14 Anonymous Session Key
The Anonymous Session Key is comprised of 16 bytes of UTF-8 characters:
UCHAR AnonymousSessionKey[] = {“SystemLibraryDTC”};
[MS-LSAD]
Added:
2.1 Transport
[…]
Cryptographic operations (as specified in section 5.1) MUST utilize a session
key obtained from the SMB session on the client or server, or the Anonymous
Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.
Added:
5 Security
5.1 Security Considerations for Implementers
[…]
The session key for sections 5.1.1 and 5.1.2 is obtained from the SMB
transport, as specified in section 2.1. The session key is obtained from the
SMB transport every time a message that needs encryption is to be sent or a
message that needs decryption is to be received. Clients should avoid using
the Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) to encrypt
sensitive data since this does not protect the data.
[MS-SAMR]
Added:
2.2.7.6 SAMPR_USER_ALL_INFORMATION
[…]
LmOwfPassword: An RPC_SHORT_BLOB structure where Length and MaximumLength MUST
be 16, and the Buffer MUST be formatted with an ENCRYPTED_LM_OWF_PASSWORD
structure with the cleartext value being an LM hash, and the encryption key
being the 16-byte SMB [MS-SMB] session key established by the underlying
authentication protocol (either Kerberos [MS-KILE] or NTLM [MS-NLMP]), or the
Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous
connection.
NtOwfPassword: An RPC_SHORT_BLOB structure where Length and MaximumLength MUST
be 16, and the Buffer MUST be formatted with an ENCRYPTED_NT_OWF_PASSWORD
structure with the cleartext value being an NT hash, and the encryption key
being the 16-byte SMB [MS-SMB] session key established by the underlying
authentication protocol (either Kerberos [MS-KILE] or NTLM [MS-NLMP]) , or the
Anonymous Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous
connection.
Added:
2.2.7.23 SAMPR_USER_INTERNAL1_INFORMATION
[…]
EncryptedNtOwfPassword: An NT hash encrypted with the 16-byte SMB [MS-SMB]
session key for the connection established by the underlying authentication
protocol (either Kerberos [MS-KILE] or NTLM [MS-NLMP]) , or the Anonymous
Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.
EncryptedLmOwfPassword: An LM hash encrypted with the 16-byte SMB [MS-SMB]
session key for the connection established by the underlying authentication
protocol (either Kerberos [MS-KILE] or NTLM [MS-NLMP]), or the Anonymous
Session Key (see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.
Added:
2.2.7.26 SAMPR_USER_INTERNAL5_INFORMATION
[…]
UserPassword: A cleartext password, encrypted according to the specification
for SAMPR_ENCRYPTED_USER_PASSWORD, with the encryption key being the 16-byte
SMB [MS-SMB] session key established by the underlying authentication protocol
(either Kerberos [MS-KILE] or NTLM [MS-NLMP]) , or the Anonymous Session Key
(see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.
Added:
2.2.7.27 SAMPR_USER_INTERNAL5_INFORMATION_NEW
[…]
UserPassword: A password, encrypted according to the specification for
SAMPR_ENCRYPTED_USER_PASSWORD_NEW, with the encryption key being the 16-byte
SMB [MS-SMB] session key established by the underlying authentication protocol
(either Kerberos [MS-KILE] or NTLM [MS-NLMP]) , or the Anonymous Session Key
(see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.
Added:
3.1.5.6.4.4 UserInternal4Information
[…]
3.If the USER_ALL_NTPASSWORDPRESENT or USER_ALL_LMPASSWORDPRESENT
flag is present in the WhichFields field, the server MUST update the
clearTextPassword attribute with the (decrypted) value of
SAMPR_USER_INTERNAL4_INFORMATION.UserPassword, using the decryption key of the
16-byte SMB [MS-SMB] session key established by the underlying authentication
protocol (Kerberos or NTLM) , or the Anonymous Session Key (see section 2.3.14
of [MS-DTYP]) if using an anonymous connection.
Added:
3.2.2.2 MD5 Usage
[…]
- user-session-key is a 16-byte value obtained from the 16-byte
SMB [MS-SMB] session key established by the underlying authentication protocol
(either Kerberos [MS-KILE] or NTLM [MS-NLMP]) , or the Anonymous Session Key
(see section 2.3.14 of [MS-DTYP]) if using an anonymous connection.
Added:
5 Security
5.1 Security Considerations for Implementers
Sensitive information, such as the cleartext password for accounts, is
communicated through this protocol; therefore, implementers must pay special
attention to the secrecy of this
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
On Fri, 2012-01-27 at 17:20 +, Bryan Burgin wrote: Andrew, We completed our investigation to this issue and propose the following changes to [MS-DTYP], [MS-LSAD], [MS-SAMR] and [MS-WKST]. The text below contains yellow highlighting to identify changed text. If the highlighting causes a problem for you, please let me know. The proposed text keeps referring to an Anonymous session key, but this happens when the user is authenticated at the DCE/RPC pipe level. Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG:111101553031054] SystemLibraryDTC
[Hongwei to bcc] Andrew, I'm filling in for Hongwei on this issue. I am engaged with several document groups here to sort this issue out. Presently I'm working with Neil Martin, who you know, and the current thinking is that this might be addressed in an update to [MS-DTYP]. I'll let you know the outcome or ping you if we need any further information. Going forward, I'll be your primary contact for this issue. Bryan -Original Message- From: Bryan Burgin Sent: Wednesday, January 04, 2012 2:18 PM To: Hongwei Sun hongw...@microsoft.com Cc: cifs-protocol@cifs.org cifs-protocol@cifs.org; MSSolve Case Email casem...@microsoft.com Subject: [REG:01553031054] [cifs-protocol] SystemLibraryDTC On Tue, 2011-11-15 at 03:56 +, Hongwei Sun wrote: Andrew, After reviewing code, we confirmed that this fixed session key are used by some SAMR/LSAD RPC functions. We are working on updating all the related documents. When they are available , I will let you know. Thanks! Now would also be a good time to work out a way to remove them :-). I would be very happy to work with your developers on a secure way we can indicate to a server that these keys should not be used, or that they should only be available over encrypted transports. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [cifs-protocol] [REG: 111101553031054] SystemLibraryDTC
Andrew, I am looking into this request. I understand your request and I found where it is used. I also confirmed that it is not mentioned in any documents such as MS-NLMP.I will give an update soon. Thanks! Hongwei -Original Message- From: cifs-protocol-boun...@cifs.org [mailto:cifs-protocol-boun...@cifs.org] On Behalf Of Edgar Olougouna Sent: Saturday, October 15, 2011 9:47 AM To: Andrew Bartlett Cc: cifs-protocol@cifs.org Subject: [cifs-protocol] [REG: 01553031054] SystemLibraryDTC [Dochelp to bcc] [Case number in subject] Andrew, One of our teammates will follow-up on this issue. The case number is 01553031054. Thanks, Edgar -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: Saturday, October 15, 2011 12:51 AM To: Interoperability Documentation Help Cc: cifs-protocol@cifs.org Subject: SystemLibraryDTC Tridge and I out of curiosity looked up SystemLibraryDTC in the documentation, and couldn't find it. For those unaware of the history here, this is the fixed-value key used for encryption of passwords and other sensitive data over RPC pipes, when RPC-level authentication is used (ie, not inherited named pipe authentication). (The exception is DRSUAPI, which uses the real session key from the authentication context). Did our grep simply miss it, or did this never get documented? Recent work we did with calls needing this key (CreateTrustedDomainEx2) returning NT_STATUS_NO_SESSION_KEY, which suggests a possible windows behaviour change. I hope what I've written above gives enough detail to start looking into the problem. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
