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

Published: 2014-11-12
Last Updated: 2014-11-12 16:28:20 UTC
by Johannes Ullrich (Version: 1)
16 comment(s)

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

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
16 comment(s)

Comments

How do you know it was found through an internal audit? The bulletin says it was "privately reported".
[quote=comment#32409]How do you know it was found through an internal audit? The bulletin says it was "privately reported".[/quote]

Because MS stated that it was "Internally found during a proactive security assessment."
Source Link Here: http://blogs.technet.com/b/srd/archive/2014/11/11/assessing-risk-for-the-november-2014-security-updates.aspx

I prefer to suspend disbelief when this comes straight from the horse's mouth.
The BBC is incorrectly reporting it was discovered by IBM, and other news feeds are picking the article up.

http://www.bbc.com/news/technology-30019976

They're confusing CVE-2014-6332 for CVE-2014-6321.
I think one thing to keep in mind is this is not just used for web sites/IIS. Schannel is the part that also does things like encrypt authentication connections within a network environment (and actually gets involved in the authentication itself if you're using kerberos). So, if I'm reading this correctly (details a bit sparse on the ground still), this is a game over type of thing for a domain controller if you can get this exploit onto a network.

We have a pretty fast patch cycle, but if we didn't we'd probably make this a "patch ASAP" if not quite a "patch now" just for that reason.

(Also, that last link talks about "browsing a malicious web page" for this KB which doesn't really make sense so, you know, YMMV even with Microsoft information sources...)
A commercial exploit module was available for this one since 2009.I remember seeing this in a pen-test conducted by a vendor at a Govt. agency which resulted in banning the use of Windows servers in the DMZ throughout that organization - I was involved in the team that migrated services to Linux, BSD.

It will be interesting to see if this will result in another Nimda-like worm. What an year this has been!
And the well established testers are all having a giggle all over the web at this "internal discovery"!
[quote=comment#32415]I think one thing to keep in mind is this is not just used for web sites/IIS. Schannel is the part that also does things like encrypt authentication connections within a network environment (and actually gets involved in the authentication itself if you're using kerberos). So, if I'm reading this correctly (details a bit sparse on the ground still), this is a game over type of thing for a domain controller if you can get this exploit onto a network.

We have a pretty fast patch cycle, but if we didn't we'd probably make this a "patch ASAP" if not quite a "patch now" just for that reason.

(Also, that last link talks about "browsing a malicious web page" for this KB which doesn't really make sense so, you know, YMMV even with Microsoft information sources...)[/quote]

Good points, mostly. Need to go back and reread the comment about browsing a malicious web page to see if it makes sense if interpreted as referring to a page attempting to throw an SSL connection using the exploit.

As for the point that it's not just used for web/IIS, it also seems it likely affects clients and servers equally, or could. That's just one of the many questions remaining unanswered, like whether the particular code paths involved are specific to certain circumstances that might make this less alarming and pervasive than it appears on the surface. Need to assume the worst, but it would be nice to know whether every windows desktop is now vulnerable to any website that uses https to deliver this payload. If that's the case, that last sentence in the first quoted paragraph seems trivial.
Time to go to PATCH NOW for MS14-066? https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6321
Well, not just windows systems are vulnerable to attackers, (Bash vulnerability comes to mind). No system is safe.
Saw this bindiff on reddit https://gist.github.com/hmoore-r7/01a2940edba33f19dec3
Just from a glance this check appears new

+ if ( pcbStructInfo > cbEncoded )
+ goto LABEL_15;

Diary Archives