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

List:       full-disclosure
Subject:    Re: [Full-disclosure] Websense Enterprise 6.3.3 Policy Bypass
From:       "Thor (Hammer of God)" <Thor () hammerofgod ! com>
Date:       2010-05-30 20:48:21
Message-ID: optid.17669e8b65.58DB1B68E62B9F448DF1A276B0886DF11C6CF19D () EX2010 ! hammerofgod ! com
[Download RAW message or body]

The "no logging at all" bit is the clincher.   I don't see how they could go without fixing it \
in any "current" version of the software.

ISA logging will be turned on by default, but only to the local SQLE instance and only for 7 \
running days.  That's no mitigating factor at all...  People who purchase Websense are counting \
on the logging as you said.  That's a big "wow" for me.  From what I've heard we've got lots of \
.gov's using websense, and logging and reporting are critical, if not legal requirements in \
many cases. 

Very nice find - and thanks for letting us know.

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: Sunday, May 30, 2010 1:33 PM
> To: full-disclosure@lists.grok.org.uk
> Subject: Re: [Full-disclosure] Websense Enterprise 6.3.3 Policy Bypass
> 
> 
> I wouldn't call breaking proxy chaining mitigation, either.  More like a "quick
> fix", if and only if it works.  Or maybe you'd call it a "work-around", which is
> what I called it in the first place.
> 
> No, there's nothing at all in the Websense database indicating you went to
> playboy.com.  You are home free until someone decides to look at the ISA
> logs (if logging is turned on) and finds it in there.  But you spent good money
> on Websense and want pretty reports with charts and colors and your
> company logo, right?
> 
> In that way, this is much better than my 2007 User-Agent hack (now fixed).
> Your indiscretions were logged, but not blocked or categorized.
> 
> 
> Now, as far as stripping out the Via header at ISA goes, per RFC 2616...
> 
> "Multiple Via field values represents each proxy or gateway that has
> forwarded the message. Each recipient <shout> MUST </shout> append its
> information such that the end result is ordered according to the sequence of
> forwarding applications."
> 
> "MUST append..." does not mean, in my understanding of the English
> language (and RFC 2119), "delete the downstream device's Via header".
> If you do anything other than "append..." (which you MUST do), you're
> breaking the RFC.
> 
> And if you go around breaking RFCs, you're BAD, m'kay? ;-)
> 
> Link to 2007 User-Agent hack, just in case you missed it...
> 
> http://mrhinkydink.blogspot.com/2007/12/websense-policy-filtering-
> bypass.html
> 
> -------- 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 2:19 pm
> To: "dink@mrhinkydink.com" <dink@mrhinkydink.com>
> Cc: "full-disclosure@lists.grok.org.uk"
> <full-disclosure@lists.grok.org.uk>
> 
> 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)"
> > Date: Sun, May 30, 2010 12:30 pm
> > To: "dink@mrhinkydink.com" , "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/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


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