Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Websense Enterprise 6.3.3 Policy Bypass
From: "Thor (Hammer of God)" <Thor () hammerofgod com>
Date: Sun, 30 May 2010 18:19:40 +0000

Ah, authenticating at the web proxy *chain*.  That wasn't intuitive from the original post...  "breaking" the chain by 
requiring an auth mechanism that the downstream proxy doesn't support really isn't a "mitigation," but now I understand 
the basis of the statement.

But, if they fixed it in 7.x, then it obviously wasn't "B" below.  ISA wouldn’t work like that anyway.  It doesn't 
"send requests to the plug-in."  You either use a filter or you don't.   For instance, if I simply used the web proxy 
filter instead, I could filter for "Via:" and block it.  But then again, if I had to do that, I wouldn't have purchased 
Websense but rather handled all my blocking at ISA. 

Not that it really matters to me personally, but I am curious - is the logging of the request completely dropped, or is 
it just not logged as a "filtered request."   IOW, if I'm behind the downstream proxy, and I go to playboy.com, Web 
sense logs the request and part of the logging is that it was "filtered" or "blocked" or something.  But if I set "Via" 
in the downstream proxy (or at the client via something like firefox) and go to playboy.com, not only do I reach the 
site, but there is no record whatsoever that I went to playboy?  If it is the latter, then they would HAVE to fix it in 
6.3.3 IMO.  

t


-----Original Message-----
From: dink () mrhinkydink com [mailto:dink () mrhinkydink com]
Sent: Sunday, May 30, 2010 10:47 AM
To: Thor (Hammer of God)
Cc: full-disclosure () lists grok org uk
Subject: RE: [Full-disclosure] Websense Enterprise 6.3.3 Policy Bypass


Chaining downstream proxies to ISA and requiring Windows Integrated Auth
has been an issue for a long time (it generally breaks the chain, so that fixes
the bypass problem right there), but frankly I'm guessing.

Windows Auth brings a lot of incompatibilities with it.  I wouldn't recommend
it unless it was absolutely required, but its proxy-chain-breaking properties
are legendary.

The ISA server will continue to log, even though Websense won't, so you
do have that.  But ISA won't filter, so you're back to square one.   And
comparing the two databases for discrepancies can get ugly.  By the time you
get around to comparing the databases, the damage has already been done.
It becomes a forensics exercise at that point.

What I think is going on here is either:

A) The Websense ISA plug-in sees that the request has come in by proxy and
assumes it has already been filtered by the originating proxy

or...

B) ISA sees the request has come in by proxy and therefore doesn't send the
request to the Websense ISA plug-in for filtering.

If it's "B", then it's a Microsoft issue and it may never get fixed (and it
becomes marketing bullet point for ISA Server TMG).

If the same problem occurs in a SQUID integration of Websense 6.3.3, then it's
definitely "A".

I have a feeling Websense fixed it in the 7.x series, so they're probably not
motivated to fix it in 6.x.  Again, I don't have the resources to test that theory
(and I asked Dan Hubbard politely for a temporary license for research
purposes).

My hunch is they did fix it in 7.x because they pretty much ignored me after
the first e-mail I sent back in October 2009.

-------- Original Message --------
Subject: RE: [Full-disclosure] Websense Enterprise 6.3.3 Policy Bypass
From: "Thor (Hammer of God)" <Thor () hammerofgod com>
Date: Sun, May 30, 2010 12:30 pm
To: "dink () mrhinkydink com" <dink () mrhinkydink com>, "full-
disclosure () lists grok org uk" <full-disclosure () lists grok org uk>

Adding "Via:" completely bypasses monitoring too?? That is bad. I've never
used Websense, so pardon my ignorance, but this wouldn't apply to with ISA's
native monitoring and logging, so I'm just curious about what's going on under
the covers. "Via:" bypassing the filter is "not good" but bypassing monitoring
(and presumably logging) is really bad.
Nice find.

I am curious as to what your thoughts are regarding Windows Auth as a
mitigation. While it's nice that ISA could help solve a problem with Websense,
I'm don't see how that would work. How would requiring auth solve
Websense's inability to filter "Via:" headers?

t

-----Original Message-----
From: full-disclosure-bounces () lists grok org uk
[mailto:full-disclosure- bounces () lists grok org uk] On Behalf Of
dink () mrhinkydink com
Sent: Saturday, May 29, 2010 8:25 PM
To: full-disclosure () lists grok org uk
Subject: [Full-disclosure] Websense Enterprise 6.3.3 Policy Bypass

discovered by mrhinkydink

PRODUCT: Websense Enterprise v6.3.3

EXPOSURE: Trivial Web Policy Bypass


SYNOPSIS
========

By adding a "Via:" header to an HTTP request it is possible for a user
to completely bypass filtering and monitoring in a Websense Enterprise
6.3.3/Microsoft ISA Server (2004 or 2006) proxy integration environment.


PROOF OF CONCEPT
================

The following works in a Websense 6.3.3 Enterprise system using the ISA
Server integration product and transparent authentication. It is
assumed it will work with other proxy integration products, but this has not
been tested.

I. Install Firefox >= 3.5

II. Obtain and install the Modify Headers plug-in by Gareth Hunt

III. Configure the plug-in to add a valid "Via:" header to every
request

Example: "Via: 1.1 VIAPROXY"

IV. Browse to a filtered Web site

V. All content is allowed without monitoring


PoC VIDEO!
==========

http://www.youtube.com/watch?v=H520rQ8JOLY


PoC RESTRICTIONS
================

The Modify Headers plug-in does not work with SSL. However, in practice
a user could browse to a so-called (by Websense) "Proxy Avoidance" Web
site and use the SSL capabilities of the remote proxy.


OTHER USES
==========

Properly configured, a downstream SQUID proxy can send requests to the
upstream ISA server and all requests will pass through without blocking
or monitoring. No evidence of activity will be logged by Websense. This
was in fact how this vulnerability was originally discovered.
Considering the simplicity of the attack, the author suspects this
bypass technique is already well-known in certain circles.

Also, it is trivial to modify proxy-enabled Linux utilities to leverage this
bypass.
The author has recompiled (that is, HACKED) OpenVPN, connect-proxy,
PuTTY, stunnel, and others to take advantage of this policy bypass.

Obviously, the risk of undetected (by Websense, at least) covert
tunnels is high in a vulnerable installation of this product.

Linux platforms using this method in this specific environment will
also enjoy bypassing Websense's transparent authentication requirement.


WORK-AROUNDS
============

For this specific installation scenario (Websense 6.3.3 + ISA 2004/6 +
transparent authentication), none are known. The following may work:

* Use Windows Integrated Authentication on the ISA Server

* Upgrade to Websense 7.x

* Do not use a proxy integration product


HISTORY
=======

10/09/2009 - vendor notified

05/29/2010 - PoC published


URL
===

http://mrhinkydink.blogspot.com/2010/05/websense-633-via-bypass.html


c. MMX mrhinkydink


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]