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/
