Were 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, its 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 weeks issues, there are lots of business applications that are tied to older browsers - Ive 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, youre 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. Its not uncommon to see embedded OSs 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 youll see an embedded Windows OS on these units.
Even today, youll 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 were 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 cant be followed (like disable Java). At a practical level, almost always you can limit your exposure. In the case of barcode scanners for instanced, well often put them on their own SSID (and matching subnet) that only has access to the host that theyre scanning to, and the management server if there is one. This is also a good recommendation for manufacturing gear or healthcare appliances - theyre 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, its 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, its 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 its 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 OSs - youll find these on tablets, phones, and various desktop/laptop OSs.
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 havent been updated in a while, if ever.
As in most least privilege configurations, wed recommend a list of permitted browsers, with a default deny for all other versions. This does mean that youll 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, youve at least got a shot that you wont 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.
Its 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 dont know any better. Hopefully anyone whos 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, Im 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 youve got a particular favourite reference site, please share on our comment form. Or if youve had a situation where filtering of this type has saved your bacon (or caused a problem), wed love to hear about that as well!
===============
Rob VandenBrink
Metafore
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.