[Bro-Dev] Bro DCE-RPC Analyzer Questions

[Fernandez, Mark I]

Bro-Dev Group,

I am doing a little research into using Bro to log and analyze specific Microsoft DCE-RPC interfaces and methods. I notice that the Bro events for 'dce_rpc_request' and 'dce_rpc_response' provide the length of the RCP data stub (aka 'stub_len'). I found reference that these events previously provided a byte string containing the stub data itself, but at some point it was reduced to just the stub_len instead. I have a few questions that I hope you could answer:


1. What was the reason you decided to remove the stub data from the events and pass only the stub length?



1. On github, I see a BinPAC file for the RPC 'At' service (bro/src/analyzerprotocol/dce-rpc/endpoint-atsvc.pac), but there are no events generated by it. I think this would be very useful for my project. What is the reason that you have the analyzer, but no events for scriptland?



1. I have a use case, for a very few, limited number of RPC interfaces/methods, where I need to receive the stub data in scriptland for logging and analysis. How do you recommend I approach this scenario? I see a couple options:

1. I could customize the DCE-RPC analyzer to pass the sub data for *ALL* 'dce_rpc_request' and 'dce_rpc_response' events; or
2. I could customize the DCE-RPC analyzer to create new events specifically for the interfaces/methods (aka UUIDs/OpNums) that I care about.
3. Other ideas?

I think both (a) and (b) will achieve the desired result; but there are trade-offs, pros and cons. I wonder which option would have a more negative impact on Bro performance? I imagine the reason you stopped passing stub data for all events was due to the performance hit, so I want to approach this in the best way possible. I appreciate your feedback.

Cheers!
Mark

[Seth Hall]

The original idea was to get extensive parsing in place for DCE-RPC
messages by parsing the IDL files for those services. Someone in the
community had hoped to take it on, but hasn't had time yet to complete
it. If you'd be interested in discussing that, I think that could be a
huge addition to Bro (hundreds of new events!).

The At service parsing file is still there because I didn't want to lose
track of it but I think there was some slight architectural change that
needed to happen before I could pass data to it. I don't think that
data is even going to that parser, it's not just that there aren't
events. I'd have to refer back to the code to see what exactly is wrong
though.

As for an approach to this problem right now, I'd prefer to see parsing
done in the core. Architecturally we try to avoid passing unparsed data
to Bro script land because of performance concerns and we generally
don't have the intrinsic tools to be able to do parsing well in Bro
scripts.

.Seth

Post by Fernandez, Mark I
Bro-Dev Group,
I am doing a little research into using Bro to log and analyze
specific Microsoft DCE-RPC interfaces and methods. I notice that the
Bro events for 'dce_rpc_request' and 'dce_rpc_response' provide the
length of the RCP data stub (aka 'stub_len'). I found reference that
these events previously provided a byte string containing the stub
data itself, but at some point it was reduced to just the stub_len
1. What was the reason you decided to remove the stub data from the
events and pass only the stub length?
1. On github, I see a BinPAC file for the RPC 'At' service
(bro/src/analyzerprotocol/dce-rpc/endpoint-atsvc.pac), but there are
no events generated by it. I think this would be very useful for my
project. What is the reason that you have the analyzer, but no events
for scriptland?
1. I have a use case, for a very few, limited number of RPC
interfaces/methods, where I need to receive the stub data in
scriptland for logging and analysis. How do you recommend I approach
1. I could customize the DCE-RPC analyzer to pass the sub data for
*ALL* 'dce_rpc_request' and 'dce_rpc_response' events; or
2. I could customize the DCE-RPC analyzer to create new events
specifically for the interfaces/methods (aka UUIDs/OpNums) that I care
about.
3. Other ideas?
I think both (a) and (b) will achieve the desired result; but there
are trade-offs, pros and cons. I wonder which option would have a
more negative impact on Bro performance? I imagine the reason you
stopped passing stub data for all events was due to the performance
hit, so I want to approach this in the best way possible. I
appreciate your feedback.
Cheers!
Mark
_______________________________________________
bro-dev mailing list
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

--
Seth Hall * Corelight, Inc * www.corelight.com

[Fernandez, Mark I]

Seth,

If you'd be interested in discussing that, I think that could be a huge
addition to Bro (hundreds of new events!).

Yes, I am interested in parsing IDL files, but I plan to do so very selectively. For example, for the At service, I don’t care about all four opnums it exposes... I just care about NetrJobAdd (which indeed is how you designed, too), and I want to log the command and the remote host to which the command was sent. Similarly, for the Server Service, I don’t care about all fifty opnums that it exposes... I just care about a handful of them, and I want to log key pieces of information associated with the function call.

At this point, I have my eye on a few, maybe up to a dozen, specific RPC UUIDs. What is it you would be looking for? Would you want parsers for every opnum in the IDL file? Or just select functions?

...I'd prefer to see parsing done in the core. Architecturally we try to
avoid passing unparsed data to Bro script land...

Thank you. That is very important guidance, exactly what I was looking for. It gives me a definitive starting point.

The At service parsing file is still there... but I think there was some slight
architectural change that needed to happen before I could pass data to it.

An architectural change? The sound of that makes me worry. I see a couple of approaches:


1. In ‘dce_rpc-analyzer.pac’ we could customize the function ‘process_dce_rpc_request’. We could have it lookup certain UUIDs, such as At-svc, and it if matches, then call InstantiateAnalyzer and DeliverStream, just like you do for RPC authentication with GSSAPI and NTLM. Pro: Could be implemented easily and quickly. Con: Need a new analyzer for each RPC UUID.



1. In ‘dce_rpc-protocol.pac’ we could customize the record ‘DCE_RPC_Request’ to change the ‘stub’ data element to be a big case statement switching on the UUID, akin to ‘SMB_PDU’ within the SMB analyzer, where the ‘message’ data element switches based on the SMB command. Pro: This is probably the preferred long-term solution. Con: It may be a little more challenging for me to code it correctly, take me a lot longer to implement.

Am I close to the right answer for sending data to the at-svc parser?


Thanks,
Mark

From: Seth Hall [mailto:***@corelight.com]
Sent: Wednesday, January 31, 2018 11:05 AM
To: Fernandez, Mark I <***@mitre.org>
Cc: bro-***@bro.org
Subject: Re: [Bro-Dev] Bro DCE-RPC Analyzer Questions


The original idea was to get extensive parsing in place for DCE-RPC messages by parsing the IDL files for those services. Someone in the community had hoped to take it on, but hasn't had time yet to complete it. If you'd be interested in discussing that, I think that could be a huge addition to Bro (hundreds of new events!).

The At service parsing file is still there because I didn't want to lose track of it but I think there was some slight architectural change that needed to happen before I could pass data to it. I don't think that data is even going to that parser, it's not just that there aren't events. I'd have to refer back to the code to see what exactly is wrong though.

As for an approach to this problem right now, I'd prefer to see parsing done in the core. Architecturally we try to avoid passing unparsed data to Bro script land because of performance concerns and we generally don't have the intrinsic tools to be able to do parsing well in Bro scripts.

.Seth

On 25 Jan 2018, at 12:28, Fernandez, Mark I wrote:

Bro-Dev Group,



I am doing a little research into using Bro to log and analyze specific Microsoft DCE-RPC interfaces and methods. I notice that the Bro events for ‘dce_rpc_request’ and ‘dce_rpc_response’ provide the length of the RCP data stub (aka ‘stub_len’). I found reference that these events previously provided a byte string containing the stub data itself, but at some point it was reduced to just the stub_len instead. I have a few questions that I hope you could answer:



1. What was the reason you decided to remove the stub data from the events and pass only the stub length?



1. On github, I see a BinPAC file for the RPC ‘At’ service (bro/src/analyzerprotocol/dce-rpc/endpoint-atsvc.pac), but there are no events generated by it. I think this would be very useful for my project. What is the reason that you have the analyzer, but no events for scriptland?



1. I have a use case, for a very few, limited number of RPC interfaces/methods, where I need to receive the stub data in scriptland for logging and analysis. How do you recommend I approach this scenario? I see a couple options:
a. I could customize the DCE-RPC analyzer to pass the sub data for *ALL* ‘dce_rpc_request’ and ‘dce_rpc_response’ events; or
b. I could customize the DCE-RPC analyzer to create new events specifically for the interfaces/methods (aka UUIDs/OpNums) that I care about.
c. Other ideas?



I think both (a) and (b) will achieve the desired result; but there are trade-offs, pros and cons. I wonder which option would have a more negative impact on Bro performance? I imagine the reason you stopped passing stub data for all events was due to the performance hit, so I want to approach this in the best way possible. I appreciate your feedback.



Cheers!

Mark

_______________________________________________
bro-dev mailing list
bro-***@bro.org<mailto:bro-***@bro.org>
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Seth Hall]

Post by Fernandez, Mark I
Am I close to the right answer for sending data to the at-svc parser?

Yep, I don't know the "best" answer, but I think you're on the right
track with either direction that you outlined. If that code just
magically existed with either of your outlined implementations I don't
think we could resist merging it in. ;)

.Seth

--
Seth Hall * Corelight, Inc * www.corelight.com