[Bro] NTLM parsing in DCE RPC

[Florent Monjalet]

Le jeu. 7 juil. 2016 à 17:39, Seth Hall <seth at icir.org> a écrit :

>
> > On Jul 7, 2016, at 9:45 AM, Florent Monjalet <florent.monjalet at gmail.com>
> wrote:
> >
> > 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.
>
> >     - DCE RPC: Not easy to find an open example capture, but this one
> >       is ok
> >
> https://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=mapi.cap
> >       (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?
>

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.)


>
> >     - SMB: I tested on
> >
> https://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=smbtorture.cap.gz
>
> 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.
> :)
>
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

>
> --
> Seth Hall
> International Computer Science Institute
> (Bro) because everyone has a network
> http://www.bro.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20160707/d617a2a1/attachment-0001.html