Re: [RFC] Detect certain Citrix application browsing services

[Thomas Buchanan <tbuchanan () thecompassgrp net>]

David Fifield wrote:
> Okay. We can document that the payload comes from a packet capture of
> Program Neighborhood's broadcast. I committed the nmap-service-probes
> patch. Please make an updated patch for payload.cc that has
> documentation on where the packet comes from (packet capture of Program
> Neighborhood) and what is expected in reply. Because we still don't know
> much about the reply packet, I want you to include it in its entirety in
> a comment, with Xs or something to mark the bytes that tend to differ.
> Or if the replies are completely different after the first 14 bytes,
> just include the first 14 bytes and say that everything else is
> different.
>
> David Fifield

Here is an updated patch as requested.  As I was putting it together, I 
noticed that a couple of the fields in the response packets are IP 
addresses, one for the Citrix server the response comes from, and a 
second field that appears to be the address of the primary system in a 
cluster farm.  However, what this means that the match line I submitted 
earlier isn't quite right.  It would match all Citrix servers that are 
in 192.168.*.* address space, but nothing else.  So the match line in 
nmap-service-probes should be shortened to the first 12 bytes, or else a 
capture could be added to extract the IP address.  I'm not sure if 
that's possible, my regex skills are very limited.

I did a bit of random scanning and found a system that responded to the 
UDP probe.  By looking at the addresses in the response packet I could 
tell the server was behind a Network Address Translation (NAT) system, 
which means this is a potential source of information disclosure.  That 
could be useful information to extract, either through match lines or 
the Citrix NSE script I saw posted yesterday.

Thanks,

Thomas

Index: payload.cc
===================================================================
--- payload.cc  (revision 16205)
+++ payload.cc  (working copy)
@@ -218,6 +218,29 @@
   "Amanda 2.6 REQ HANDLE 000-00000000 SEQ 0\n"
   "SERVICE noop\n";
 
+/* Citrix MetaFrame application browser service
+   Original idea from http://sh0dan.org/oldfiles/hackingcitrix.html  
+   Payload contents copied from Wireshark capture of Citrix Program 
+   Neighborhood client application.  The application uses this payload to
+   locate Citrix servers on the local network.  Response to this probe is 
+   a 48 byte UDP payload as shown here:
+
+   0000   30 00 02 31 02 fd a8 e3 02 00 06 44 c0 a8 80 55
+   0010   00 00 00 00 00 00 00 00 00 00 00 00 02 00 06 44
+   0020   c0 a8 80 56 00 00 00 00 00 00 00 00 00 00 00 00
+
+   The first 12 bytes appear to be the same in all responses.
+
+   Bytes 0x00 appears to be a packet length field
+   Bytes 0x0C - 0x0F are the IP address of the server
+   Bytes 0x10 - 0x13 may vary, 0x14 - 0x1F do not appear to
+   Bytes 0x20 - 0x23 are the IP address of the primary system in a server farm
+   configuration 
+   Bytes 0x24 - 0x27 can vary, 0x28 - 0x2F do not appear to  */
+static const char payload_citrix[] =
+  "\x1e\x00\x01\x30\x02\xfd\xa8\xe3\x00\x00\x00\x00\x00\x00\x00\x00"
+  "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
+
 static const char payload_null[] = "";
 
 
@@ -276,6 +299,9 @@
       SET_PAYLOAD(payload_Sqlping);
       break;
     */
+    case 1604:
+      SET_PAYLOAD(payload_citrix);
+      break;
     /* RFC 2865: "The early deployment of RADIUS was done using UDP port number
        1645, which conflicts with the "datametrics" service. The officially
        assigned port number for RADIUS is 1812. */

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