Message-ID: <optid.17669e8b65.58DB1B68E62B9F448DF1A276B0886DF11C6CF19D@EX2010.hammerofgod.com>
Date: Sun, 30 May 2010 20:48:21 +0000
From: "Thor (Hammer of God)" <Thor@...merofgod.com>
To: "dink@...inkydink.com" <dink@...inkydink.com>,
	"full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Websense Enterprise 6.3.3 Policy Bypass

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@...ts.grok.org.uk [mailto:full-disclosure-
>bounces@...ts.grok.org.uk] On Behalf Of dink@...inkydink.com
>Sent: Sunday, May 30, 2010 1:33 PM
>To: full-disclosure@...ts.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@...merofgod.com>
>Date: Sun, May 30, 2010 2:19 pm
>To: "dink@...inkydink.com" <dink@...inkydink.com>
>Cc: "full-disclosure@...ts.grok.org.uk"
><full-disclosure@...ts.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@...inkydink.com [mailto:dink@...inkydink.com]
>>Sent: Sunday, May 30, 2010 10:47 AM
>>To: Thor (Hammer of God)
>>Cc: full-disclosure@...ts.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@...inkydink.com" , "full-
>>disclosure@...ts.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@...ts.grok.org.uk
>>>[mailto:full-disclosure- bounces@...ts.grok.org.uk] On Behalf Of
>>>dink@...inkydink.com
>>>Sent: Saturday, May 29, 2010 8:25 PM
>>>To: full-disclosure@...ts.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/

Powered by blists - more mailing lists