[servers/SMB] Handle NEGOEX clients for SMBv2#327
Open
SAERXCIT wants to merge 1 commit into
Open
Conversation
Owner
|
can you share here or via email the pcap of this exchange? |
Author
|
Hi, unfortunately I do not have the pcap anymore. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi!
This PR lets Responder handle SMB2 clients requiring the use of NEGOEX during SMB authentication.
I have here a W11 machine that absolutely wants NEGOEX as an available SPNEGO MechType in the Negotiate Response, and FINs the connection if it's not present. The changes to

packets.pymake Responder add it at this step*. :Then, this machine starts the SMB2 Session Setup Request with an additional step before the NTLMSSP_NEGOTIATE message : a NEGOEX message with expected parameters. At this step, it also still allows NTLMSSP as an SPNEGO MechType:

The changes in

servers/SMB.pymake Responder answer with a generic SPNEGO message requiring the use of NTLMSSP and ignoring NEGOEX completely. Pardon the use of an ugly raw hex string in the code, but as you can see there is no dynamic parameter that needs to be computed at runtime in this message, so I went with the easy solution. The raw hex string is the SMB2 Session Setup Response, highlighted in the hex dump:The regular NTLM flow then kicks off as expected. We end up capturing the NTLMv2 authentication, and it cracks as expected. Here is the complete authentication dance:

I did manage to try out this modified SMB server on multiple Windows clients (as well as in live conditions), and clients that did prefer the NTLMSSP MechType still do even with NEGOEX offered. I still managed to capture their hashes, I did not observe any regression there.
However I did not manage to find a setting to force a client to use the NEGOEX mechanism. As such my testing for NEGOEX handling was only done on the one live machine that displayed this behaviour (for reasons unknown).
* : Looking at the blame, the NEGOEX mechanism was actually enabled until commit 2f1b81b in Dec 2023. If you have more context on why it was disabled it could help make a decision on whether to merge this PR. Maybe it made some clients kick off a NEGOEX negotiation, which Responder was not equipped to handle then?
Cheers!