How bad is the SCHANNEL vulnerability (CVE-2014-6321) patched in MS14-066?

We had a number of users suggesting that we should have labeled MS14-066 as "Patch Now" instead of just critical. This particular vulnerability probably has the largest potential impact among all of the vulnerabilities patched this Tuesday, and should be considered the first patch to apply, in particular on servers.

Just like OpenSSL implements SSL on many Unix systems, SCHANNEL is the standard SSL library that ships with Windows. Expect most Windows software that takes advantage of SSL to use SCHANNEL .

Microsoft stated that this vulnerability will allow remote code execution and that it can be used to exploit servers. Microsoft also assigned this vulnerability an exploitability of "1", indicating that an exploit is likely going to be developed soon. But other then that, very little has been released publicly about the nature of the vulnerability.

There is some conflicting information if the bug was found internally or by a third party. The bulletin states: "This security update resolves a privately reported vulnerability" [1] . A blog post about the vulnerability states: "Internally found during a proactive security assessment." [2] . Finally, Microsoft's "Acknowledgement" page does not list a source for the vulnerability [3]. It is not clear how far outside of Microsoft the vulnerability was known prior to the patch release.

However, as soon as a patch was released, it can be used to learn more about the vulnerability. It is very hard these days to obfuscate a patch sufficiently to hide the nature of a vulnerability.

So what does this mean for you? 

My guess is that you probably have a week, maybe less, to patch your systems before an exploit is released. You got a good inventory of your systems? Then you are in good shape to make this work. For the rest (vast majority?): While you patch, also figure out counter measures and alternative emergency configurations.

The most likely target are SSL services that are reachable from the outside: Web and Mail Servers would be on the top of my list. But it can't hurt to check the report from your last external scan of your infrastructure to see if you got anything else. Probably a good idea to repeat this scan if you haven't scheduled it regularly.

Next move on to internal servers. They are a bit harder to reach, but remember that you only need one internal infected workstation to expose them. 

Third: Traveling laptops and the like that leave your perimeter. They should already be locked down, and are unlikely to listen for inbound SSL connections, but can't hurt to double check. Some odd SSL VPN? Maybe some instant messenger software? A quick port scan should tell you more.

You are doing great if you can get these three groups out of the way by the end of the week. Internal clients are less of an issue, but just like "traveling laptops", they may run some software that listens for inbound SSL connections. 

Stick with my old advice: Patching is only in part about speed. Don't let speed get in the way of good operations and procedures. It is at least as important to patch in a controlled, verifiable and reproducible way. Anything else will leave you open to attack due to incomplete patching. Don't forget to reboot the system or the patch may not take affect.  

Microsoft didn't mention any workarounds. But this may change as we learn more about the issue. So make sure that you know how to disable certain ciphers or certain SSL modes of operations. And please take this as an other opportunity to get your inventory of hardware and software sorted out.

Patch Now? Maybe better: Patch first / Patch soon. This vulnerability could turn into a worm like "slapper", an OpenSSL worm exploiting Apache back in the day.

I am not aware of any public IDS signatures for this problem so far, but it may make sense to check for SSL error even on non-Windows servers to spot possible exploit attempts. 

To make things more interesting (confusing?), the Cisco Talos blog states that "[w]hile it is covered by only a single CVE, there’s actually multiple vulnerabilities, ranging from buffer overflows to certificate validation bypasses". [4] It would be really odd from Microsoft to only use a single CVE number for various vulnerabilities only related by the common library they happen to be found in. But I do give Cisco some credibility here as they are working closely with Microsoft and may have gotten more details from Microsoft then what was published in the bulletin.

Cisco also published a number of Snort rules for MS14-066. If you have a VRT subscription, you should see these rules with an SID from 32404 through 32423.

PLEASE SHARE ANY ATTACK DATA / EXPLOIT SIGHTINGS YOU MAY HAVE ! ( handlers -at- sans.edu or our contact form)

[1] https://technet.microsoft.com/library/security/MS14-066
[2] http://blogs.technet.com/b/srd/archive/2014/11/11/assessing-risk-for-the-november-2014-security-updates.aspx
[3] https://technet.microsoft.com/library/security/dn820091.aspx
[4] http://blogs.cisco.com/security/talos/ms-tuesday-nov-2014