Re: Kerberos probes for nmap

[David Fifield <david () bamsoftware com>]

On Sat, Nov 28, 2009 at 09:20:53PM +0100, Patrik Karlsson wrote:
> I noticed that Kerberos get's detected fine when running against
> Windows but my Heimdal hosts are not detected. Running over TCP the
> RPCCheck probe seems to trigger an answer. Here's the signature:
>
> SF-Port88-TCP:V=5.10BETA1%I=7%D=11/28%Time=4B1181BB%P=i386-apple-darwin10.2.0%r(RPCCheck,55,"\0\0\0Q~O0M\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\
> SF:x11\x18\x0f20091128200203Z\xa5\x05\x02\x03\x08i@\xa6\x03\x02\x01=\xa9\x
> SF:15\x1b\x13<unspecified\x20realm>\xaa\x0b0\t\xa0\x03\x02\x01\0\xa1\x020\
> SF:0");
>
> I have put together a probe that works both against 88/tcp and 88/udp.
> The probe is a request for a TGT for the user NM in realm NM. Again,
> my matches might need some improvement. Attaching signatures for
> reference.
>
> SF-Port88-TCP:V=5.10BETA1%I=7%D=11/28%Time=4B1184BD%P=i386-apple-darwin10.2.0%r(kerberos,67,"\0\0\0c~a0_\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\
> SF:x11\x18\x0f20091128201453Z\xa5\x05\x02\x03\x0c\xd3O\xa6\x03\x02\x01\x06
> SF:\xa7\x04\x1b\x02NM\xa8\x0f0\r\xa0\x03\x02\x01\x01\xa1\x060\x04\x1b\x02N
> SF:M\xa9\x04\x1b\x02NM\xaa\x170\x15\xa0\x03\x02\x01\0\xa1\x0e0\x0c\x1b\x06
> SF:krbtgt\x1b\x02NM")%r(RPCCheck,55,"\0\0\0Q~O0M\xa0\x03\x02\x01\x05\xa1\x
> SF:03\x02\x01\x1e\xa4\x11\x18\x0f20091128201459Z\xa5\x05\x02\x03\x03\x80\x
> SF:ae\xa6\x03\x02\x01=\xa9\x15\x1b\x13<unspecified\x20realm>\xaa\x0b0\t\xa
> SF:0\x03\x02\x01\0\xa1\x020\0");
>
> SF-Port88-UDP:V=5.10BETA1%I=7%D=11/28%Time=4B118543%P=i386-apple-darwin10.2.0%r(kerberos,63,"~a0_\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e\xa4\x11\x18
> SF:\x0f20091128201702Z\xa5\x05\x02\x03\n\xf9m\xa6\x03\x02\x01\x06\xa7\x04\
> SF:x1b\x02NM\xa8\x0f0\r\xa0\x03\x02\x01\x01\xa1\x060\x04\x1b\x02NM\xa9\x04
> SF:\x1b\x02NM\xaa\x170\x15\xa0\x03\x02\x01\0\xa1\x0e0\x0c\x1b\x06krbtgt\x1
> SF:b\x02NM");

Sorry, I didn't understand before that there was no probe getting a
response from UDP. I tried the UDP probe and it worked against UDP
Kerberos on Mac OS X, the TCP counterpart of which is detected as "Mac
OS X kerberos-sec" by the RPCCheck probe. The response I get back is
this:

SF-Port88-UDP:V=5.10BETA1%I=2%D=12/15%Time=4B2816A5%P=i686-pc-linux-gnu%r(
SF:kerberos,8D,"~\x81\x8a0\x81\x87\xa0\x03\x02\x01\x05\xa1\x03\x02\x01\x1e
SF:\xa2\x11\x18\x0f19780623234544Z\xa4\x11\x18\x0f20091215230646Z\xa5\x05\
SF:x02\x03\x0e8\xfc\xa6\x03\x02\x01\x06\xa7\x04\x1b\x02NM\xa8\x0f0\r\xa0\x
SF:03\x02\x01\x01\xa1\x060\x04\x1b\x02NM\xa9\x04\x1b\x02NM\xaa\x170\x15\xa
SF:0\x03\x02\x01\0\xa1\x0e0\x0c\x1b\x06krbtgt\x1b\x02NM\xab\x13\x1b\x11CLI
SF:ENT_NOT_FOUND\0");

It's rather different than your Heimdal response, so we have an
opportunity for discrimination here. I think this could make a good UDP
payload too.

I want you to see if you can refine the probe. Here's the Wireshark
dissection of it:

User Datagram Protocol, Src Port: 57945 (57945), Dst Port: kerberos (88)
Kerberos AS-REQ
    Pvno: 5
    MSG Type: AS-REQ (10)
    KDC_REQ_BODY
        Padding: 0
        KDCOptions: 50800010 (Forwardable, Proxyable, Renewable, Renewable OK)
        Client Name (Principal): NM
        Realm: NM
        Server Name (Unknown): krbtgt/NM
        from: 2009-10-12 11:35:05 (UTC)
        till: 2009-10-12 21:35:05 (UTC)
        Nonce: 267493544
        Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 rc4-hmac des-cbc-crc 
des-cbc-md5 des-cbc-md4

It looks like this came from the packet capture of some tool. Maybe
there are parts of it that can be omitted to make the packet shorter and
less specific. I'm looking at section 5.4.1 of RFC 4120 where it says
that "Server Name" and "from" are optional. You can probably reduce the
number of encryption types offered; you probably want to keep strong,
commonly implemented ones because sometimes servers will ignore requests
for weak ciphers (in other protocols--I don't know about Kerberos). Try
omitting the "Client Name" too. I don't think that would work for
authentication purposes but we're only looking for a response, and it
reduces the chance that we'll hit a real "NM" user name.

I can imagine that having the "till" time in the past might be a problem
for some servers. The RFC says: "It is not optional, but if the
requested endtime is '19700101000000Z', the requested ticket is to have
the maximum endtime permitted according to KDC policy." That is worth a
try.

The Kerberos protocol looks pretty specific, so there's probably not
much chance another general-purpose probe will work. I just tried
--version-all and didn't get any responses. So adding a refined
Kerberos-specific probe is fine by me. Please test my suggestions above
and write back with your results. If you want help with packet crafting
then you can ask here too.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/