[Bro-Dev] SMB2 - NTLM GSSAPI messages continued

[Martin van Hensbergen]

Hi all,

As you read a while back I'm trying to make the GSSAPI NTLM parsing generic enough for reuse, as it is now intertwined with the SMB parsing code. I have made some progress but before I continue, I would like some feedback from the community what is 'the bro way' on how to proceed.

What I did so far is create a separate gssapi.pac file with all the type definitions for GSSAPI*TOKEN* messages. I removed all the smb_header parameters to its parsing functions so that GSSAPI and SMB are decoupled. Yet, I get confused over what information belongs to which protocol. I display my thoughts here hoping that you can either concur my line of reasoning or correct me, before I type something that is completely 'un-brolike' :)

As far as I know, the correct protocol chain is SMB[v1/2] -> GSSAPI -> NTLM. In my opinion, all message descriptions in the pac files from type SMB_NTLM_* should be renamed to NTLM_* as NTLM is not part of SMB. This would result in a separate NTLM.pac for NTLM parsing only.

I am next wondering where and how to generate SMB-NTLM-authenticate BIFevents after the decoupling. As I understand it, the parsing of the types defined in the pac files is done recursively. So originally, the parsing would go something like:

type SMB1_session_setup_andx_request_ntlm_extended_security(header: SMB_Header)
-> security_blob: SMB_NTLM_SSP(header)
--> gssapi: GSSAP_NEG_TOKEN(header)
---> gssapi: GSSAP_NEG_TOKEN_INIT(header)
(.......) some more layers (...)
---------> SMB_NTLM_Authenticate: bool = $context.connection.proc_smb_ntlm_authenticate(header, this);
-----------> proc_smb_ntlm_authenticate function generates the BifEvent including the SMB header detaIls given down to it as a parameter of each function.

In the new situation the header does not get given down to each function, therefor, when reaching the end-of-the-line at 'proc_smb_ntlm_authenticate', it cannot generate a proper BifEvent with the SMB header as it is not available to that function.

My guess what is needed is: the ability to raise the BifEvent at the 'top layer', after the whole parsing has been done, and not at the tail of the parsing of the message. If I am not mistaken, if I add a function to the SMB1_session_setup_andx_request then this will gets executed after the complete message has been parsed. I would then be able to reach down the message to get the user/domain/workstation variables in the NTLM message. But this would give me variables like security_blob.gssapi.gssapi_token(...)...domain_name, etc which doesnt make a lot of sense and is actually an eyesore.

It is a bit long mail, but basically my two questions are

1) do we all agree that the SMB_NTLM* functions should be renamed to NTLM* or am I missing something?

2) What is the best way to generate a BifEvent with SMB header and all the parsed user/domain/workstation values that were parsed deeper inside the protocol layer?

Any help on this is much appreciated; especially if you think I am overlooking a hidden can of worms somewhere ;-)

Regards

-Martin




​