Websense 6.3.3 "Via:" 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

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




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

The Modify Header 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.


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



c. MMX mrhinkydink

New_Laptop_Boi

That's me!

For some unknown reason, The Boss decided I needed a laptop a year and a half after he decided I didn't need a laptop. So, now I have a new laptop.

I liked the old one just fine. It played UT great! I've had nothing but heartache with my own laptop and UT. At first I thought it was Vista, but all the problems remained after I upgraded it to Windows 7 (a.k.a. "Vis7a"). Then, one day I plugged a USB keyboard into it and tried playing. All the problems vanished. Turns out it's the keyboard hardware (or the driver). Still, it's not convenient to play that way.

This new laptop is nothing stellar, a run-of-the-mill HP 6530B with a dual core Centrino, two lousy gigs of RAM, 32-bit Vis7a, and an 80G hard drive (encrypted!).

meh.

I'm not impressed.

But... it runs UT like a champ! So now I can play from the comfort of my own couch. And it's small enough that I can have a cat on my lap at the same time!

It makes playing UT fun again!

So if you see New_Laptop_Boi say "Hi".

McAfee's 5958 DAT Fiasco

This week I got caught up in McAfee’s 5958 DAT mess back at the Salt Mines. Not only am I the local Network Nazi, but I also manage McAfee’s crappy AV for the entire enterprise. Luckily that day (Wednesday) I was telecommuting, so I was not in the thick of things.

I was “in the cloud”, as it were.

I was also wise enough never to have installed Service Pack 3 on my Salt Mine PC, so I was one of the lucky ones. For a variety of reasons, I never trusted it. I was almost ready to apply it once IE 7.0 came out, but then I heard there was no roll-back to IE 6 on machines with SP3, so I passed. I have it on all the XP machines here on DinkNet, but I use different AV on those boxes.

And that was an odd thing...

I have Microsoft Security Essentials (MSE) on my main box and that fateful morning it died. Very mysteriously. The little green system tray icon was just plain gone and when I went to restart it from Control Panel, Services the system told me it could not be found.

This was before the news came out that the whole thing was due to a turd dropped on the world by McAfee, so I was quietly sweating bullets. Had some bug followed me home? Or crawled through my other covert tunnel, OpenVPN? I switched boxes while I re-installed MSE on that system. Then I rebooted it and performed a full scan. Nothing.

And “nothing” doesn’t mean shit these days, with fast-mutating bugz like Zeus floating around the Interwebs. The virus definitions you get today are for crap that has been around for months.

While all this is going on I get a call from my sprog, Inky Dink, and it turns out he’s having AV problems too! And I know damn well he doesn’t run McAfee because I personally installed MSE on his system!

What the motherfucking fuck was going on here?

But it turned out Inky had been victimized by one of those scareware AV programs. I pointed him to malwarebytes.org and he took care of it himself later that evening.

Again, all this time we, the corporate IT proles, had no idea it was a McAfee problem. What was I to think? AV software was dying everywhere as far as I could tell from my small corner of the Universe. Was it cyberwar? Was the the “Digital Pearl Harbor” the trade press has been crying about for the last four months? Was Google’s January hack the warning shot?

No. It was ludicrous. It had to be a series of coincidences, so I kept my mouth shut during the Salt Mine phone conference.

Other people were not so cautious. They started spreading all sorts of FUD. All it takes is one jerk to read one unsubstantiated claim on one Internet forum and as soon as that happens he’s sending e-mail out to everyone and his brother and the next thing you know you’re in full chickens-with-their-heads-cut-off mode.

Luckily even though that particular jerk (our very own local security wannabee) made a complete idiot of himself that day, cooler heads prevailed. The only thing he damaged was his own credibility.

By about 10:30AM that morning the news finally came out and we went into Full Damage Control Mode. When the dust cleared, about 25% of our systems were down.

McAfee later stated it only affected one half of one percent of their customers. Do tell. Maybe they based that number on the phone calls they got that day (“All lines are busy, please hold!”). Maybe they thought it was just rubberneckers that took their site offline.

And WTF happened?

This event was curious in that the update that caused this mess arrived early that day. Normally, and I admit I haven’t checked in some time, we get that update between 11:30AM and 2:30PM EST. The timestamp on the files said they came in at 4:37AM. Why? Did their QA department in Bangalore (or Shanghai or whatever) take off early that day? What was the Big Rush?

If McAfee’s Legal Department gets their way – and there is no doubt in my mind it will get its way – we may never know what happened.