Re: NFS script

[David Fifield <david () bamsoftware com>]

On Thu, Nov 26, 2009 at 11:01:42AM +0100, Patrik Karlsson wrote:
> On 26 nov 2009, at 04.20, David Fifield wrote:
>
> > On Tue, Nov 24, 2009 at 11:11:27PM +0100, Patrik Karlsson wrote:
> > > I finished two more Nmap scripts that hopefully will be of more use than the first one.
> > > nfs-showmount.nse replicates the functionality of showmount -e in order to list remote NFS shares.
> > > citrix-published-applications.nse queries Citrix (1604/udp) for the list of published applications.
> > >
> > > Both scripts use static packets in order to trigger responses, if this
> > > is of any interest for the UDP payloads David requested earlier?
> > >
> > > I just finished the scripts so they have obviously not gone through a
> > > lot of testing. Thoughts, comments, suggestions and bug reports are
> > > most welcome.
> > >
> > > Here's some output from the citrix-published-applications script:
> > >
> > > Starting Nmap 5.00 ( http://nmap.org ) at 2009-11-24 22:09 CET
> > > Interesting ports on 192.168.56.5:
> > > PORT     STATE SERVICE
> > > 1604/udp open  unknown
> > > |  citrix-published-applications:  
> > > |  Notepad
> > > |  iexplorer
> > > |_ registry editor
> > >
> > > Here's some output from the nfs-showmount script:
> > >
> > > Interesting ports on yoda.localdomain (192.168.56.50):
> > > PORT    STATE SERVICE
> > > 111/tcp open  rpcbind
> > >
> > > Host script results:
> > > |  nfs-showmount:  
> > > |  /home/storage/backup 192.168.56.0/255.255.255.0 192.168.56.66/255.255.255.255
> > > |_ /home 192.168.56.0/255.255.255.0
> >
> > Thanks, Patrik, these look great! I don't have access to an NFS or
> > Citrix server so I want to repeat the call for people to test them. In
> > case you lost the message, they are online here:
> > http://seclists.org/nmap-dev/2009/q4/508
> >
> > I have only one concern from looking at the scripts, and that is the
> > undocumented packet contents. You need to add comments explaining what
> > all those hex digits mean, and links to references if available. This is
> > the model I try to follow with the UDP payloads. We have one for NFS,
> > which looks like this:
> >
> > /* NFS version 2, RFC 1831. XID 0x00000000, program 100003 (NFS), procedure
> >   NFSPROC_NULL (does nothing, see section 2.2.1), null authentication (see
> >   section 9.1). */
> > static const char payload_nfs[] =
> >  "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x01\x86\xA3"
> >  "\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
> >  "\x00\x00\x00\x00\x00\x00\x00\x00";
> >
> > The idea is that anyone who wants or needs to modify the packet contents
> > can look up a reference and do it. The best case, in an NSE script, is
> > to have a function build the packets algorithmically from parameters,
> > but that's overkill if you're just sending a few stereotyped packets.
> > You've already got a good explanation of the NFS export list data
> > format.
> >
> > I know we've had trouble lately finding documentation for the
> > ICA Browser protocol. We need to know at least where the packets come
> > from, whether from a packet capture, or whatever. Thomas Buchanan was
> > able to partially decipher them at
> > http://seclists.org/nmap-dev/2009/q4/520.
>
> OK, so while documenting the packets I also took the time to clean
> them up a bit. Both packets now use NULL_AUTH which made the udp
> packet somewhat smaller. The documentation is complete and based on
> Wiresharks dissesector. When I'll implement authentication in the
> future all move the packet creation to a function. David, like you
> said, at the moment it does not make much sense to do so.

I tested this with the nfsd on Mac OS X. It worked great over both TCP
and UDP. The packet documentation is good.

| nfs-showmount:
|_/Users 192.168.0.0

That's with this in /etc/exports:

/Users -network 192.168.0.0 -mask 255.255.0.0

I added your script in r16210. Well done! I made just a few minor
changes. I put the script in the safe category rather than intrusive,
because we're using the service exactly as it's designed. The comment
with the @usage needs to start with three dashes to be seen by NSEDoc,
so I added the extra dash. I removed the "copyright" field; "license" is
the only one with meaning in NSE. I removed some of the whitespace
around the packet data.

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