How Important Are Important Security Updates?

I’ve seen a lot of customer environments that have a Microsoft security patching policy that could be summarized as:

• Critical patches deployed ASAP
• Everything else can wait

The idea is that the most critical vulnerabilities get rolled out as fast as quickly as possible (testing is optional, for some customers). But anything in a security bulletin rated Important or lower will get rolled out next time there’s a planned maintenance window, which could be monthly, or quarterly, or never in some cases.

There’s a problem with the idea that only Critical rated vulnerabilities are important. Because often the Important rated vulnerabilities are also… important. As an example, the MS17-015 bulletin contains information about an Exchange Server vulnerability that is rated Important. The description is:

An elevation of privilege vulnerability exists in the way that Microsoft Exchange Outlook Web Access (OWA) fails to properly handle web requests. To exploit the vulnerability, an attacker who successfully exploited this vulnerability could, perform script/content injection attacks, and attempt to trick the user into disclosing sensitive information.

In today’s security climate that is certainly a risk.

NOTE: For this vulnerability to be exploited, a user must click on a maliciously crafted link from an attacker.

Getting malicious links in front of end users is not actually all that difficult for attackers. OWA usage is quite high in many orgs these days, so a vulnerability like this certainly should be patched as quickly as possible. But it’s easily overlooked due to the Important rating.

Another example last year was MS16-079.

An email filter bypass exists in the way that Microsoft Exchange parses HTML messages that could allow information disclosure. An attacker who successfully exploited the vulnerability could identify, fingerprint, and track a user online if the user views email messages using Outlook Web Access (OWA). An attacker could also combine this vulnerability with another one, such as a Cross-Site Request Forgery (CSRF), to amplify the attack.

To exploit the vulnerability, an attacker could include specially crafted image URLs in OWA messages that could be loaded, without warning or filtering, from the attacker-controlled URL. This callback vector provides an information disclosure tactic used in web beacons and other types of tracking systems. The update corrects the way that Exchange parses HTML messages.

In plain language, the vulnerability was that remote images would be loaded automatically by OWA if they were coded as the background image of a HTML table cell. I was able to reproduce the exploit with minimum effort (it didn’t require any special coding abilities, just some basic HTML). Using it to track a user via a beacon image is nefarious enough. But it’s easy to apply such a technique to phishing and other attacks, by crafting something like a fake PayPal notice that is entirely image-based and would bypass many of the weaker spam filters on the market today. But as an Important vulnerability, it’s easily overlooked.

The takeaway here is to ensure that you’re interpreting security bulletins correctly. Arbitrary rules like “We only deploy Critical patches” or delays on other patches due to their lower rating may be leaving you exposed to what are still serious flaws in the product.

For Exchange Server in particular, the security bulletins that Microsoft issues are also often misunderstood. Customers who look at the MS17-015 bulletin see that Exchange Server 2013 SP1 (which is really CU4), Exchange Server 2013 CU14, and Exchange Server 2016 CU3 are vulnerable. So where does that leave customers who are running other versions of Exchange?

The key is to look at security bulletins in the context of Microsoft support lifecycle. Cumulative Updates are supported for about 6 months, long enough for the next two CUs to be released. Exchange Server 2013 SP1 (CU4) is a special case because it was given a different support lifecycle, but you shouldn’t be running that build in production today. But every other CU in between CU4 and CU14 should be considered vulnerable, even though they aren’t all listed. That’s because Microsoft doesn’t release security advisories for unsupported builds (not even to clarify whether they’re vulnerable or not). The same goes for Exchange Server 2016 CU2 and earlier. Those builds are vulnerable, even though they’re not listed because they’re no longer supported.

The patch cycle for Microsoft products is tough to keep up with. Exchange makes life a little easier thanks to its robust high availability features, allowing us to patch individual servers while maintaining availability of the overall service for our end users. But if it’s still too much effort, there’s always Office 365 to consider. Nobody ever tells me that they miss patching all those servers after they move to the cloud.