Closed zeroSteiner closed 4 years ago
Yeah so the change I added broke the unit tests, so I did quite a bit of refactoring work in 38a0c1f to fix them up and get them back running smoothly.
One major thing I did was move the attribute assignments into parse_negotiate_response
. This mean that parse_smb3_capabilities
had to be moved into there and because the request
wasn't available, that was moved higher up into negotiate
which has access to both the request and response. This then meant I had a bunch of reworking to do in the specs. I hope this looks good, I wouldn't be opposed to an alternative approach.
Oh! I added this line as an improvement and turned out I introduced a bug by misreading the specs. Thanks for catching this!
Thanks for the review @cdelafuente-r7! I updated the specs per your suggestions.
Thanks @zeroSteiner! It is merged now.
I noticed a bug that was causing the
SMB::AlwaysEncrypt
setting in Metasploit to not be honored. It turns out that with the dialect is SMB 3.1.1 and the encryption algorithms are passed as part of the negotiation capabilities, the flag is not set. This is at least the behavior I observed while testing Windows 10 1809 x64. Per MS-SMB2 theSMB2_GLOBAL_CAP_ENCRYPTION
is only valid for the3.0
and3.0.2
dialects. This caused session encryption to always be disabled for 3.1.1 servers, there by ignoring theSMB::AlwaysEncrypt
setting.My proposed solution for this is to move the
@session_encrypt_data
assignment until after the SMB3 capabilities have been set (and by extension the@encryption_algorithm
attribute). We can then check if this attribute is not nil to identify that the server supports encryption and we can enable session encryption if it was requested by the user.While investigating this issue I also noticed that the
parse_smb3_encryption_data
function was parsing and processing the encryption, compression and preauth integrity capabilities so I renamed it to more accurately represent what it does.Testing
For testing: