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 _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
