SMB3 Secure Dialect Negotiation
This blog talks about secure dialect negotiation, one of the new SMB3 security enhancements in Windows Server 2012.
Secure dialect negotiation is introduced in SMB3 to protect against man-in-the-middle attempt to downgrade dialect negotiation. The idea is to prevent an eavesdropper from downgrading the initially negotiated dialect and capabilities between the client and the server.
Summary
In a nutshell, upon reception of a Tree Connect response, an SMB3-capable client validates the original SMB2 Negotiate request by sending a signed IOCTL, called FSCTL_VALIDATE_NEGOTIATE_INFO as specified in [MS-SMB2]. The server needs to reply with a signed response, and this enables end-to-end validation of the Negotiate exchange.
The client sends the IOCTL only if it is implemented to request validation of an SMB2 Negotiate via the RequireSecureNegotiate abstract data element. Windows 8 clients configure this through the registry key RequireSecureNegotiate.
To change this setting, set the following LanmanWorkstation parameter using PowerShell cmdlet:
Set-SmbClientConfiguration -RequireSecureNegotiate <0|1>
0 – Disabled
1 – Required
To check the current configuration value, use the PowerShell cmdlet:
Get-SmbClientConfiguration | fl RequireSecureNegotiate
You can also edit the DWORD value through the registry editor. HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecureNegotiate.
To change the default behavior, you need to define the registry key or use the PowerShell command. If not present, its default value is “Required” in Windows 8 clients.
Note: In Windows 8/8.1 implementation, RequireSecureNegotiate = 1 means “Required” enabled. Any other value other than 1 (0, 2,3, …) means “Disabled”. Note that MS-SMB2 correctly defines RequireSecureNegotiate as a Boolean.
Secure Negotiate details
The FSCTL_VALIDATE_NEGOTIATE_INFO operation allows the client and server to repeat the Negotiate process over a signed exchange. This exchange could also be sealed if encryption is enabled, i.e. Session.EncryptData or TreeConnect.EncryptData is TRUE.
The signed request allows the server to validate the client capabilities, Guid, SecurityMode, and Dialects which could be 0x0300, 0x0210, and 0x0202 (this list includes 0x0224 if you are testing Windows 8 Beta).
The signed response (success or error) enables the client to verify the outcome. On a signed success response, the client verifies that none of these attributes of the Negotiate response have been downgraded or manipulated: server capabilities, server Guid, server SecurityMode, and the connection Dialect.
If the client receives an error response, the transport connection is terminated if any of the following conditions is met:
- The response is not signed. This is applied regardless of whether signing is required or not on the connection or session.
- The status code is STATUS_ACCESS_DENIED, meaning the server could not validate the request.
- The response values (capabilities, Guid, SecurityMode, and Dialect) do not match the server values that the client originally stored on the connection object.
Note that the server would have also terminated the transport connection if it could not validate the client capabilities, Guid, SecurityMode, and Dialects.
Because the request is signed, the response must be signed as well, otherwise the client would terminate the connection. In case of 3.0 dialect, the sender computes the signature using AES_CMAC-128. For 2.002 or 2.1 dialect, the signature is derived from an HMAC-SHA256 hash.
Down-level servers (pre-Windows 2012) will return STATUS_NOT_SUPPORTED or STATUS_INVALID_DEVICE_REQUEST since they do not allow or implement FSCTL_VALIDATE_NEGOTIATE_INFO. The client should accept the response provided it’s properly signed. For SMB3-capable server, it is recommended that the server implements FSCTL_VALIDATE_NEGOTIATE_INFO. On the other-hand, when a client establishes an SMB 3.x connection, it MUST go through the FSCTL_VALIDATE_NEGOTIATE_INFO phase, provided RequireSecureNegotiate allows it.
The protocol documents that a non-SMB3-capable (2.002 or 2.1) should respond to VALIDATE_NEGOTIATE_INFO request with a status error of STATUS_NOT_SUPPORTED or STATUS_INVALID_DEVICE_REQUEST, the same error as for any unsupported/non-allowed FSCTL. Windows Server 2008 (SMB 2.002) and Windows Server 2008 R2 (SMB 2.1) return STATUS_FILE_CLOSED, instead.
Anonymous or Guest sessions pass the mesh
As previously noted, the “secure Negotiate” relies on the correct signing of responses by all SMB 2/3 servers. This means the exchange can only occur under a user security context that is neither anonymous nor guest. Therefore, anonymous or guest sessions cannot use the secure negotiation. Keep in mind that if you enable null or guest sessions to access your shares, you leave the door open for this potential attack.
Note on downgrading to SMB1
With “secure Negotiate”, it is not required that signing is active on the connection. It is inherently designed to work with servers that support unsolicited signed requests. Since Windows-based SMB1 servers do not support unsolicited signed requests, downgrading attacks from SMB 2/3 to SMB 1 cannot be detected in Windows 8. It is recommended that SMB1 is disabled if all clients in your environments are SMB2 capable (See blog post).
NOTE: At the time of writing this blog, Windows 8 and Windows Server 2012 are Release Preview (Release Candidate) in their release cycle.
References
Windows 8 Beta: SMB connections fail with error "Invalid Signature" https://support.microsoft.com/kb/2686098
Overview of Server Message Block signing https://support.microsoft.com/kb/887429
SMB 3 Security Enhancements in Windows Server 2012 https://blogs.technet.com/b/filecab/archive/2012/05/03/smb-3-security-enhancements-in-windows-server-2012.aspx
Comments
- Anonymous
July 11, 2016
Aw, this was an incredibly nice post. Taking a few minutes and actual effort to produce a superb article… but what can I say… I put things off a lot and never manage to get nearly anything done.