NTLM parsing in DCE RPC

Zeek
1

Hi,

As this is my first interaction with the bro community, first things
first: thanks a lot for working on such an awesome project.

We are currently working on IVRE (https://ivre.rocks,
https://github.com/cea-sec/ivre), an open source framework aimed at
exploring and querying results from various network related tools
(such as nmap scans, bro logs, argus or netflow files), through either
a web interface, CLI tools or a python API.

As part of this work, I was very interested in Seth’s work on SMB, so
this mail is about the topic/seth/smb branch. Here again, thanks a lot
for the huge work on these protocols.

It turns out that for DCE RPC, the NTLM decoding seems broken: the
NTLM analyzer is called, but the decoding fails to recognize the
message type, and no ntlm.log log is produced. It works very well
for SMB, though.

After debugging a bit, it turned out that the meta: ASN1EncodingMeta
field of NTLM_SSP_Token in ntlm-protocol.pac should in fact be
part of the underlying GSSAPI layer. Therefore, when directly decoding
NTLM without GSSAPI, the fields are shifted and have no meaning. Since
SMB uses GSSAPI in the examples I found and DCE RPC did not, NTLM over
GSSAPI over SMB worked great, but not NTLM over DCE RPC.

The first field of NTLM should actually be the “NTLMSSP\x00” magic
(according to:
http://davenport.sourceforge.net/ntlm.html#theNtlmMessageHeaderLayout
and wireshark dissectors). Moving the meta field to the GSSAPI
layer will allow to properlly decode NTLM over DCE RPC and maybe HTLM
NTLM Authentication later on.

I am attaching a naive (git) patch to this mail; this fixes the
problem for me but might not be the exact way you want to do this.
Also, I might just have missed something from the start, maybe the way
it is currently done was on purpose. Please tell me if you have any
comments on the patch and/or want me to submit it to the bug tracker
or on github.

Sample captures the NTLM log generation can be tested on:

Cheers,

Florent

0001-Fix-GSSAPI-mech_token-to-include-ASN1EncodingMeta.patch (3.05 KB)

2

As part of this work, I was very interested in Seth's work on SMB, so
this mail is about the topic/seth/smb branch. Here again, thanks a lot
for the huge work on these protocols.

This is a good time to reach out about that branch. We are preparing to merge it into the master branch soon once we do a bit more review.

The first field of NTLM should actually be the "NTLMSSP\x00" magic
(according to:
The NTLM Authentication Protocol and Security Support Provider
and wireshark dissectors). Moving the `meta` field to the `GSSAPI`
layer will allow to properlly decode NTLM over DCE RPC and maybe HTLM
NTLM Authentication later on.

Ugh, I'm not surprised that there is yet another case where this is done wrong. I'll review the change you proposed and the look at the pcap.

    - DCE RPC: Not easy to find an open example capture, but this one
      is ok
      SampleCaptures
      (from packet 711 in wireshark). You'll have to register DCE RPC
      on port 4997 (mapi) in bro.

Just for clarity, you're saying that this pcap should write out an ntlm log yet isn't?

    - SMB: I tested on
      SampleCaptures


So many people point to this pcap, but I tend to avoid it because it doesn't seem to represent a normal smb client and server very well. It's too hard to understand how that pcap should map into logs. Maybe someday. :slight_smile:

Thanks!
  .Seth

3

As part of this work, I was very interested in Seth’s work on SMB, so
this mail is about the topic/seth/smb branch. Here again, thanks a lot
for the huge work on these protocols.

This is a good time to reach out about that branch. We are preparing to merge it into the master branch soon once we do a bit more review.

The first field of NTLM should actually be the “NTLMSSP\x00” magic
(according to:
http://davenport.sourceforge.net/ntlm.html#theNtlmMessageHeaderLayout
and wireshark dissectors). Moving the meta field to the GSSAPI
layer will allow to properlly decode NTLM over DCE RPC and maybe HTLM
NTLM Authentication later on.

Ugh, I’m not surprised that there is yet another case where this is done wrong. I’ll review the change you proposed and the look at the pcap.

Just for clarity, you’re saying that this pcap should write out an ntlm log yet isn’t?

Exactly (provided that you enable DCE RPC decoding on port 4997). Actually, I found and debugged the issue on private captures and just looked for public pcap where I could reproduce the issue. The expected ntlm log body for this capture is:

1056991898.902392 CUwb2m3ZV4I6liX6Ba 192.168.0.173 1068 192.168.0.2 4997 ALeonard ALEONARD-XP CNAMIS - -

(Success/failure for NTLM authentication on DCE RPC is not implemented yet, but I guess it is rather non trivial to do.)

So many people point to this pcap, but I tend to avoid it because it doesn’t seem to represent a normal smb client and server very well. It’s too hard to understand how that pcap should map into logs. Maybe someday. :slight_smile:

Well, as previously mentionned, I just took the first matching public pcap in google for my issue, I was just interested in the SMB/GSSAPI/NTLM auth packets. I think your test samples are perfect for testing the issue.

Thanks!
.Seth

Thanks for the quick answer!

Florent

4

I just merged your patch into the topic/seth/smb branch. I also verified that the change doesn't impact the public tests or a private test I'm maintaining.

I also did another fix to actually load the DPD signature for DCE-RPC. It makes the port 4997/tcp stuff from that mapi.cap file show up automatically.

Thanks!
  .Seth

5

It turns out that for DCE RPC, the NTLM decoding seems broken: the
NTLM analyzer is called, but the decoding fails to recognize the
message type, and no ntlm.log log is produced. It works very well
for SMB, though.

I just merged your patch into the topic/seth/smb branch. I also verified that the change doesn’t impact the public tests or a private test I’m maintaining.

I also did another fix to actually load the DPD signature for DCE-RPC. It makes the port 4997/tcp stuff from that mapi.cap file show up automatically.

Great, thanks again for your great work and reactivity!

Florent