Patches were released and risk assessment on Microsoft Internet Explorer vulnerabilities was requested. I'm sorry to report that risk assessment of this particular type is rather simple. I can describe it in three steps.
(1) The risk of the vulnerability being exploited is real, and high.
The nature of the vulnerability itself doesn't much factor into the assessment. What matters most is how many systems do you have running the software with the vulnerability, and how important are those systems.
If history is any guide, these vulnerabilities will be exploited by dozens, hundreds, or even thousands of variants of malware, over the next days, weeks, and months.
Recently announced vulnerabilities affecting the Microsoft Internet Explorer can be used to install and execute software on the system, when that system has accessed a malicious or benevolent-but-compromised web site. Vulnerabilities like this one have been exploited by literally hundreds of bits of malware in the last year. They are very difficult to trace back to an origin, but it is likely that at least one of our "W32.spybot.worm" infections came in via one of these types of holes. Most organizations presently have no defense against MSIE holes, other than patching. Most don't filter outbound http connections, and have no protection in place against this vulnerability. Most organizations don't offer a more secure web browser to their staff, such as Mozilla FireFox, as an alternative to MSIE. Even if they did, it's not practical to remove MSIE from the system image, and therefore one must patch MSIE anyway.
(2) The potential cost of an infection on our network is very, very high.
For most organizations, the patch management strategy is not perfect. Remote exploits in Windows within the last six months have resulted at one client site in at least 1,000 total compromised machines on the network. Most of these also contacted one of several outside IRC servers (overseas), for further instructions. (That's how these infections were detected).
One of these systems was infected on October 4, 2004, several days before the Intrusion Detection System (IDS) was able to detect the infection (the ruleset to detect the new threat didn't exist on October 4). A few files left behind on the system indicate that it was able to receive instructions via the IRC channel to install other spyware and adware. Who knows what else happened on that box, and the other hundreds of boxes infected.
MSIE holes can be used to launch attacks from the compromised host to the rest of the internal network, bypassing the firewall. The software installed on a single system through one of these browser holes could be a "bot" with the ability to probe inside the network looking for one or more other security holes and using them to propagate automatically to all vulnerable systems.
Chaining unrelated security defects like this is a proven technique that has been used by malware (see "Virus, Worm, and Malware Evolution", which links to articles describing a very complex chain exploited this past spring which involved a number of compromised "trusted" web sites).
Bots like this install adware and spyware, attempt to disable antivirus software, steal passwords, steal identity information, attempt to spread via many different types of exploits to other systems both within our network, and out to other networks, and allow external operators to execute arbitrary instructions on the compromised systems. In other words, they can, and do, anything they want to do on the compromised system.
(3) In this risk assessment, there is no "step 3".
Risk assessment on individual Microsoft Internet Explorer vulnerabilties is not meaningful. This is true for any and all other software on your Windows system image as well.
Defects which appear to be low risk can be easily chained together with other system defects to result in a dramatically elevated risk. In some sense, this complicates the assessment of risk, and reduces opportunity to save operational costs by choosing which patches to deploy. Fortunately, the simple rule, "If it's on the image, we must patch it" can be used to mitigate these large, growing and very real risks due to exploit chaining.
By the way, exploit chaining receives very little attention in the anti-virus dominated trade press. You will find only 16 references to the quoted exact phrase in google, including a few "how to hack" guides, a few analysis papers, and zero articles. However, please be advised that this technique has been known and used by "black hats" for several decades. Within the last year, automated exploit chaining was demonstrated to great effect.
The Grim Reaper, the Bearer of Bad News (TM) am I. But really, I think that all is not lost. Most organizations do some stuff which helps reduce the extent of damage that they can suffer from these threats, and there is more that can be done. If you can't sell all these Windows PC things on eBay and replace them with Mac OS X systems, you have certain other options available to help with prevention of this type of browser-crawl-back exploit and the resultant, inevitable and extant exploit chaining.
I recommend:
- Apply all security patches to Microsoft Internet Explorer, and to Microsoft Windows, as soon as is feasible following their release. We have observed a few recent infections were confirmed to come through a hole in Microsoft Outlook. The client organization elected not to patch it, ostensibly because they don't use the software. Like MSIE, Outlook cannot be easily removed from the system image. If it's on our image, we must patch it.
- Deploy a web proxy architecture with an antivirus plugin which allows you to filter http connections and provide some degree of meaningful protection against these browser crawl-back exploits. There are client-side and network based options. I prefer the network based systems because it eliminates the need to maintain Yet Another Software Package on the PC.
- Deploy FireFox as an alternative web browser, and encourage staff to use it to the greatest extent possible. (Certain web sites employ proprietary techniques which work only is MSIE browsers, and sometimes only on Windows.) The design of the FireFox browser makes it much, much simpler to package and distribute than MSIE, so that on those occasions when FireFox needs to be patched, it can be patched at a much lower operational cost.
- Require all web sites developed by the organization to be web standards compliant (XHTML, CSS2, etc.) and require that they be tested and work specifically with Mozilla FireFox.
Comments