Re: NFS and Citrix scripts

[David Fifield <david () bamsoftware com>]

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.

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