Re: OS X Lion incorrectly being reported as Windows

[David Fifield <david () bamsoftware com>]

On Fri, Oct 07, 2011 at 02:41:05PM -0700, David Fifield wrote:
> On Fri, Jul 29, 2011 at 11:10:08PM +0200, Patrik Karlsson wrote:
> > On Jul 28, 2011, at 8:24 PM, Matt Selsky wrote:
> >
> > > On Jul 21, 2011, at 12:10 PM, Patrik Karlsson wrote:
> > >
> > > > Scanning Mac OS X Lion with nmap results in it being reported as Windows.
> > > > The match line responsible for this is:
> > > > match kerberos-sec m/^\0\0\0\0$/ p/Microsoft Windows kerberos-sec/ o/Windows/
> > > >
> > > > Maybe it's time to create a dedicated kerberos probe?
> > >
> > > We have "Probe UDP Kerberos".  What KDC software does Lion run?  Heimdal, MIT, or something else?  We have 
> > > matches for both Heimdal and MIT for that probe.
> > >
> > >
> > > Cheers,
> > > Matt
> >
> >
> > I should have been clearer, I was thinking of a TCP probe. I'm attaching a patch that adds a TCP probe.
> > The probe is essentially the same as the UDP except for a 4 byte block in the beginning of the probe containing the 
> > length.
> > The matches are the same to, except for the Windows 2003 one for some reason.
> > I've been able to verify both MIT v1.3-1.8 and Heimdal matches and they work well.
> > The MIT v1.2 could probably be added by simply figuring out the length of the reply and prepending it to the match 
> > (I was to lazy to do so).
> >
> > In order to avoid the crazy match above, resulting in Lion being detected as Windows, the patch also removes the 
> > mentioned 4 byte match from the SMBProgNeg probe.
> > If someone has the possibility to test this out, please do and let me know how it works.
>
> I added your new probe and matches. Thanks.

Oh, except I changed the probe lengths to ranges; the replies have one
field that can be 1, 2, or 3 bytes long, and this affects other length
bytes in other parts of the packet.

The variable-length field is a count of microseconds, so it's 3 bytes
93.45% of the time, 2 bytes 6.53%, and 1 byte 0.02%.

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