Re: match lines and serialnumberd probe

[Patrik Karlsson <patrik () cqure net>]

On 18 maj 2010, at 17.10, David Fifield wrote:

> On Sun, May 09, 2010 at 12:59:34PM +0200, Patrik Karlsson wrote:
> > I just added a few match lines to support the following to the
> > nmap-service-probes (r17520):
> > - Twisted web server (OS X 10.6.3 Server)
> > - Apple Filing Protocol (OS X 10.6.3 Server in VMware Fusion)
> > - Apple Mac OS X Password Server (OS X 10.6.3 Server)
> > - XAVi XG6546p Wireless Gateway
> > - Sun GlassFish Communications Server
> > - Comdasys, SIParator and Glassfish SIP services
> >
> > I spoke to David a while back about this and I should have submitted
> > them via this form instead which I will do next time:
> > http://insecure.org/cgi-bin/submit.cgi
> >
> > I also created a new probe, which I didn't add, based on information
> > picked up in a packet trace.
> > According to " "Well known" TCP and UDP ports used by Apple software
> > products" [1] it's used by serialnumberd.
> > If anyone has an OS X server available I would appreciate if you could
> > test the attached patch to see if it discovers the serialnumberd
> > properly.
> > I don't know if there's something of interest in the response, if
> > anyone thinks/knows if there is, let me know and I'll add that to the
> > information field.
> > There's a little info on serialnumberd here [2] and here [3].
>
> I think this probe is a good and interesting one. From what I've read at
>
> http://blog.periodiklabs.com/2005/05/the-mystery-of-serialnumberd.html
> http://discussions.apple.com/thread.jspa?messageID=11332997
> http://www.macintouch.com/readerreports/server10_4_7/topic4341.html
> http://krypted.com/mac-os-x-server/xsan-serialnumberd-troubleshooting/
> http://discussions.apple.com/thread.jspa?threadID=2128597&tstart=0
>
> serialnumberd is a DRM program that checks for other OS X Server
> instances using the same serial number. All but one of the duplicate
> serial number–using machines is disabled or has functionality reduced or
> something. But the most interesting thing is that serialnumberd will
> override your firewall settings and make a hole for itself even if you
> have an explicit rule to block it. Thus it would be great for host
> discovery of even locked-down servers.
>
> (Aside: Does anyone else think this is a bad idea? Wouldn't it be easy
> to listen for serial numbers and echo them back to the LAN, and shut
> down every OS X Server? I don't know what the responses look like, so
> maybe it's more complicated than that.)

I had the exact same thought. However, the responses are affected by the contents in the probe.
Sending the same probe twice generates the same response. Changing the W8XLcP to something else generates a different 
response.
So it might be trickier than just echoing response back.

> The probe you posted is
>
> Probe UDP serialnumberd q|\x53\x4e\x51\x55\x45\x52\x59\x3a 
> \x31\x32\x37\x2e\x30\x2e\x30\x2e\x31\x3a\x57\x38\x58\x4c\x63\x50\x3a\x78\x73\x76\x72|
> rarity 8
> ports 626
>
> That looked mysterious until I saw it was all ASCII; it's the same as
>
> Probe UDP serialnumberd q|SNQUERY: 127.0.0.1:W8XLcP:xsvr|
>
> So the only part that looks strange is the W8XLcP: that might be your
> own serial number or something. I can't test this because I don't have
> OS X Server. So I want to add this probe, and maybe add it as a UDP
> payload, once we can determine if that field varies and how. Perhaps we
> can replace it with a dummy value like AAAAAA.

I've replaced the probe with the following, and it still works:
q|SNQUERY: 127.0.0.1:AAAAAA:xsvr|

I'm sending you the complete response off-list just in case.

> So does someone else with Mac OS X Server want to do some packet
> sniffing and see if this query changes?
>
> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/


//Patrik

--
Patrik Karlsson
http://www.cqure.net
http://www.twitter.com/nevdull77





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