[prev in list] [next in list] [prev in thread] [next in thread] 

List:       focus-ms
Subject:    RE: Securing Citrix NFuse and IIS 5
From:       "Ogle Ron (Rennes)" <ron.ogle () thomson ! net>
Date:       2002-10-22 9:05:43
[Download RAW message or body]

Time for a wake up call.  My comments below are strictly to shed some light
on the gray details.  Only when one knows the truth about the real security
can one understand the risk involved and make a good judgment.  Using terms
like SSL doesn't automatically grant you security.  Also, real security
doesn't happen with a single piece of code.

So understand the complete system from level 1 to 7 (speaking about the OSI
levels hear).  All of the parts must be controlled and secured as they
mostly are interdependent on providing a complete security solution.  Since
no system is perfectly secure, you'll have to make the call.  Just do it
with the best information.

My .02Euro
Ron Ogle
Rennes, France

> -----Original Message-----
> From: Henry Sieff [mailto:hsieff@orthodon.com]
> Sent: Saturday, October 19, 2002 12:28 AM
> To: 'auto300258@hushmail.com'; focus-ms@securityfocus.com
> Subject: RE: Securing Citrix NFuse and IIS 5

Most security professionals are seeing and explaining that many
vulnerabilities that are being exploited are at the application layer.  This
means that the "bunch of ASP" is probably buggy and can be exploited.  This
could include compromising the server to impersonating another authorized
user to just DOS.

As I have not done an vulnerability assessment on Citrix code, I cannot
personally say one way or another.  However, I'm betting that there are some
pretty good size holes in the code.  This is the reason that I brought up
external certification.  Let Citrix pay another company that has some
reasonable expectation and experience in finding these holes, and let that
company put it's stamp of approval on the product.  The sales guy's "trust
me" doesn't cut it.

> NFUSE 1.7 doesn't really add a whole lot of vulnerability 
> points to an IIS
> server; its really just a bunch of ASP with some citrix 
> specific stuff in
> the form of scripts and the like. So:

given

> 1) Harden the IIS server, following best practices.
> 2) Throw down for an SSL certificate and make your authentication page
> https.
> 3) Use SSL for communications between your NFUSE server and 
> Citrix Data
> Collector.

same here

> quick. I want to touch on Ron's points a little further (not 
> to pick on him,
> because they are good points):
> 


Let me illuminate.  What NFUSE is doing is authenticating you and giving you
back a Java (I believe that they have ActiveX if you wish) program with
authorization cookie that enable you to connect to a Metaframe server.  So
in the strictest sense, NFUSE doesn't itself by-pass the firewall, it
delivers content to your machine that DOES by-pass your firewall.  But if
you can trick NFUSE in to thinking that you are an authorized user, then
NFUSE will give you everything you need.

So, the hacker has 3 points of access here because you have to trust buggy
code.  The first point is the IIS server.  The second is the MS OS which is
heavily integrated with the entire solution.  The third is the NFUSE
application itself.  You must protect each one.

> Do you mean NFUSE, or citrix itself? If the former, keep in 
> mind that all
> NFUSE is is a method of presenting published applications. It is no
> different then a web page with a form. It returns nothing but 
> a static HTML
> page, with links to server side files with a particular MIME 
> type which your
> browser then hands off to a client which then acts on the parameters
> contained therein. If the latter, well, it doesn't tunnel on 
> port 80; it
> uses a separate port, and there are, in fact, products you 
> can use to proxy
> that connection (Secure Gateway, Extranet, which is a pretty 
> decent general
> VPN solution).

Secure Gateway uses the "ticket" (cookie) provided through the NFUSE
download to authenticate the user.  Again here, Secure Gateway uses only
server side authentication.  This means that any attacker can try to hack
this system without being authorized.

Just two seconds on the stealing the "ticket".  There is software out there
can will not only hide on a client's machine and steal the cookie, but can
be used to quickly send the cookie to the attacker and then DOS the client.
The attacker's software can then quickly use the authenticated cookie to
keep the session open.  Computers and software are a great combination to
automate these menial tasks.

> Goes back to locking down the IIS server itself. NFUSE 
> doesn't add a lot of
> risk here, and actually, with SG or Extranet, you can use 
> other tokens for
> authentication. The login form isn't the only means.

This is why you must put up additional countermeasures.  If you cannot trust
the system, then put a gate in front.  In this case, you can put the reverse
proxy in front of both the NFUSE server and the Secure Gateway.  The reverse
proxy must be trusted and perform user level authentication using either
basic authentication with something like a SecurID, client side
certificates, or similar.

> configuration. Yes, these devices can be attacked at 
> application layer, but
> then, just about every remote access solution is vulnerable.
[prev in list] [next in list] [prev in thread] [next in thread]