Re: [RFC] Detect certain Citrix application browsing services

[David Fifield <david () bamsoftware com>]

On Mon, Nov 23, 2009 at 04:39:23PM -0600, Thomas Buchanan wrote:
> Thomas Buchanan wrote:
> > David Fifield wrote:
> >  > I would feel better if we knew exactly what this packet is doing. Is it
> >  > a harmless server ping, is it requesting a connection, is it allocating
> >  > some server resources? Maybe try different remote desktop dissectors in
> >  > Wireshark.
> >
> > Fair enough.  I'll try to get access to a test system and do some more
> > detailed research on what's going on.
>
> Sorry for the delay in following up on this.  I've done some further  
> testing, and from everything I can gather, it seems that this is a very  
> basic server detection packet.  I used the Citrix Program Neighborhood  
> client to browse for Citrix servers and applications available on a test  
> network, while monitoring the network traffic with Wireshark, as well as  
> resource utilization and event logs on the Citrix servers.
>
> Citrix Program Neighborhood is a client application that allows you to  
> view published applications on available Citrix servers.  When you first  
> load the application, it prompts you for a username and password to use  
> when connecting to any Citrix servers it might find.  It then proceeds  
> with network discovery, first by doing a DNS lookup for a host named  
> 'ica' in the local network domain, ie ica.mynetwork.tld.
>
> If DNS resolution fails, Program Neighborhood sends out a UDP packet on  
> port 1604 to the broadcast address for the local network.  The contents  
> of this packet are exactly what I proposed for payload.cc and  
> nmap-service-probes.  Any servers on the local network with the ICA  
> Browser (aka Citrix IMA) service running will observe this broadcast  
> packet and respond with a single packet, which corresponds to the match  
> line from my patch.  The response packets vary slightly from server to  
> server, but from what I've seen are always 48 bytes long, with at least  
> the first 14 bytes identical.  The client application then follows up  
> with a specific UDP packet to port 1604 to the IP address of the server  
> that responded, which appears to be a verification packet, and elicits  
> another response packet from the server, this time with some identifying  
> information.  I may try to work up a NSE script to gather more  
> information from this port in the future.
>
> After the network discovery is completed, all the communications I  
> observed between the client and the server were conducted over TCP on  
> port 1494 (ica).  I did not observe any significant resource usage on  
> the server from the UDP network packet probes, and I did not identify  
> and log entries that were created either.  Seems to be a pretty  
> transparent and straightforward process, somewhat similar to WPAD proxy  
> autodiscovery process, or the previously mentioned Microsoft SQL server  
> browsing service.
>
> Let me know if you have any further questions or concerns, or would like  
> additional details on anything.

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
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/