We're getting a whole lot of bad advice regarding the latest crop of vulnerabilities.  Folks are saying things like "disable Java", or "Migrate away from IE6/7/8", or even "Migrate to IE10 or Firefox".

While these will certainly mitigate the current vulnerability, it's often not a practical way to go.  If you pick the right week, almost anything could be your target "disable that" component - everyone has a zero day at one time or another.   Specific to this week's issues, there are lots of business applications that are tied to older browsers - I've got a number of clients who have business critical applications that are tied to a specific version of IE (often IE6), or to a specific, old version of Java.  Or if you still have a few thousand XP workstations, you're going to top out at IE8.

In the several fields, there are applications that *must* be used, that can only be run from within older browsers.  For instance, some common K-12 education applications require an older version of the browser.  More commonly, some healthcare and pharmaceutical manufacturing applications are only "certified" on specific - and often older - versions of the browser.

The worst situation is on embedded devices.  It's not uncommon to see embedded OS's running on any number of things: SCADA components, hospital gear (IV pumps, heart monitors and the like), barcode scanners, price guns, elevator controls, ABM Banking Machines almost anything really.  These are sometimes running old Linux versions, but just as frequently these days you'll see an embedded Windows OS on these units.

Even today, you'll find manufacturers who will void your warantee if you upgrade an embedded OS - this is often the case when you are dealing with obsolete product (where the vendor wants to sell you the new version), but in lots of cases it costs big money / effort for the manufacturer to re-certify the product on a different OS.  Or the upgrade may require different hardware (another way to spell this is "no budget" or sometimes "next years budget", neither of which helps you today).  Even if you can upgrade, these embedded units might not be centrally managed or remotely upgradable.  In that case you need to go find these units, which might be squirreled away all over a manufacturing facility, hospital or university that might be multiple buildings and millions of square feet. 

So, in a lot of cases we're just stuck with these old browsers and/or old java versions - what to do?

What we normally recommend is - first of all, stop finger pointing and making blanket recommendations that can't be followed (like "disable Java").  At a practical level, almost always you can limit your exposure.  In the case of barcode scanners for instanced, we'll often put them on their own SSID (and matching subnet) that only has access to the host that they're scanning to, and the management server if there is one.  This is also a good recommendation for manufacturing gear or healthcare appliances - they're usually well-known devices that can be segragated by subnet.

But in more mobile situations, you might have healthcare appliances on wheels, conference call units or video projectors, which might be plugged into any handy ethernet port.  Because of this, it's also advisable to start filtering outbound browser traffic by looking at the user agent string.  In this way, you can user the required older version of a browser or Java on a specific subnet, but when the traffic leaves that network, likely to get to the public internet, you can enforce a minimum version of your browser (IE in this case), or Java.

The user agent strings for various versions of Java are simple, it's just the version of Java.  So for Java 6.0 Update 26, the User Agent String is "Java/1.6.0_26".  This same standardized format is followed for all versions.

So it's simple enough to block by version, or if you want to block all outbound Java to a network (for instance, the internet or part of it), using the expression "Java/" is a decent way to go.

IE has various user agent strings, but using expression matching you can simplify the criteria tremendously.  For instance, depending on the version of the browser and OS, IE6 can have any one of dozens of strings, but for the purposes of blocking or permitting traffic, you can usually simplify to a match on "MSIE 6."

Similarly, you can permit or block based on user agent strings of Firefox, Safari, Opera or any other browser.  Note that these in particular may have different strings on different OS's - you'll find these on tablets, phones, and various desktop/laptop OS's.

This method is easily implemented on most firewalls, and given the current state of Browsers and Java, this is something that should be set up on your at your internet perimter.  The blocking policy is likely something that will change with the security landscape, but if you still have IE6 or 7 for business reasons, blocking those outbound is a good idea.  Watching the agent strings that are logged going outbound can be a good way to find those mouldy-oldy computers that got installed 6 (or 10) years back and haven't been updated in a while, if ever.

As in most "least privilege" configurations, we'd recommend a list of permitted browsers, with a default deny for all other versions.  This does mean that you'll need to be quick when new browser versions come out though.  It might be prudent to permit newer versions that do not yet exist (for instance, as of today IE 9.1 and 11 do not exist), so that when one thing or another auto-updates at 1am one evening, you've at least got a shot that you won't be disrupting service for your user community.  Using regular expressions to winnow out the good from the bad is likely a better way to go here as well.

It's important to note that you can modify your user agent strings, either in the browser configuration or in the registry (for IE), but the goal here is to protect yourself from the folks who don't know any better.  Hopefully anyone who's savvy enough to change their identifiers like this will be running a brand-new browser, and will want it to masquerade as something older or from a different vendor, so that one app or another will run for them.

As a side note, Microsoft has a few articles on how they construct their user agent strings, one is here http://msdn.microsoft.com/en-us/library/ms537503%28v=vs.85%29.aspx
and another:
http://blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the-user-agent-string-problems-and-alternatives.aspx

There are a bunch of sites that describe how exactly to filter on user agent strings at your firewall or IPS, I'm not covering the details in this article.  Some decent starting points (though not actual how-to type documentation) for Snort and Bluecoat are here:
http://vrt-blog.snort.org/2012/11/web-proxies-user-agent-strings-and.html
and here:
www.bluecoat.com/doc/457

The SANS Reading Room is also a good place to start for material of this type - for instance Dan Manners has a good paper here that starts towards the detection aspect (not blocking) using Snort and tcpdump/wireshark:
http://www.sans.org/reading_room/whitepapers/hackers/user-agent-field-analyzing-detecting-abnormal-malicious-organization_33874.

There are a ton of sites out there dedicated to listing user agent strings for various browsers, languages and apps out there - if you've got a particular favourite reference site, please share on our comment form.  Or if you've had a situation where filtering of this type has saved your bacon (or caused a problem), we'd love to hear about that as well!

===============
Rob VandenBrink
Metafore