Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: How bad is the SCHANNEL vulnerability (CVE-2014-6321) patched in MS14-066? - SANS Internet Storm Center SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
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

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

I will be teaching next: Intrusion Detection In-Depth - SANS London July 2019

Johannes

3562 Posts
ISC Handler
How do you know it was found through an internal audit? The bulletin says it was "privately reported".
Larry Seltzer

25 Posts
Quoting Larry Seltzer:How do you know it was found through an internal audit? The bulletin says it was "privately reported".


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.
Larry Seltzer
1 Posts
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.
Joey

18 Posts
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...)
Joey
5 Posts
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!
UpYourAPT

2 Posts
And the well established testers are all having a giggle all over the web at this "internal discovery"!
UpYourAPT

2 Posts
Quoting Anonymous: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...)


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.
UpYourAPT
2 Posts
Time to go to PATCH NOW for MS14-066? https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6321
UpYourAPT
1 Posts
Well, not just windows systems are vulnerable to attackers, (Bash vulnerability comes to mind). No system is safe.
jmeetze

3 Posts
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;
jmeetze
12 Posts
Juniper published an IPS signature for CVE-2014-6321.
https://services.netscreen.com/restricted/sigupdates/nsm-updates/2439.html
The detection pattern is protected, but some of the other signature configuration is visible. The signature is only monitoring the server response on 4433/UDP. I know too little about SSL or SCHANNEL traffic. Does this make sense?
jmeetze
1 Posts
POC?
https://twitter.com/daveaitel/status/533064909387747328/photo/1
https://lists.immunityinc.com/pipermail/dailydave/2014-November/000794.html
jmeetze
12 Posts
"MS14-066: Known issues ..." - Anyone else here?
- https://support.microsoft.com/kb/2992611
Last Review: Nov 14, 2014 - Rev: 3.0 <<
See: Known issues with this security update:
" We are aware of an issue in certain configurations in which TLS 1.2 is enabled by default, and TLS negotiations may fail. When this problem occurs, TLS 1.2 connections are dropped, processes hang (stop responding), or services become intermittently unresponsive..."

Security Update MS14-066 causes major performance problems in Microsoft Access / SQL Server applications
- http://darrenmyher.wordpress.com/2014/11/13/security-update-ms14-066-causes-major-performance-in-microsoft-access-sql-server-applications/
Nov 13, 2014
___

- https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6321 - 10.0 (HIGH)
Last revised: 11/12/2014
> http://technet.microsoft.com/security/bulletin/MS14-066
.
PC.Tech

34 Posts
Quoting Anonymous:Juniper published an IPS signature for CVE-2014-6321.
https://services.netscreen.com/restricted/sigupdates/nsm-updates/2439.html
The detection pattern is protected, but some of the other signature configuration is visible. The signature is only monitoring the server response on 4433/UDP. I know too little about SSL or SCHANNEL traffic. Does this make sense?
Yes, in http://emergingthreats.net/daily-ruleset-update-summary-11132014/ you can see that the following Snort rules for "ETPRO EXPLOITs" were added:

2809176 – DTLS Pre 1.0 HelloVerifyRequest CookieSize Heap Overflow
2809177 – DTLS 1.0 HelloVerifyRequest CookieSize Heap Overflow
2809178 – DTLS 1.2 HelloVerifyRequest CookieSize Heap Overflow
2809179 – DTLS Pre 1.0 HelloVerifyRequest Schannel OOB Read
2809180 – DTLS 1.0 HelloVerifyRequest Schannel OOB Read
2809181 – DTLS 1.2 HelloVerifyRequest Schannel OOB Read
2809192 – SChannel Possible Heap Overflow DSAWithSHA1
2809193 – SChannel Possible Heap Overflow DSAWithSHA224
2809194 – SChannel Possible Heap Overflow DSAWithSHA256
2809195 – SChannel Possible Heap Overflow ECDSAWithSHA1
2809196 – SChannel Possible Heap Overflow ECDSAWithSHA224
2809197 – SChannel Possible Heap Overflow ECDSAWithSHA256
2809198 – SChannel Possible Heap Overflow ECDSAWithSHA384
2809199 – SChannel Possible Heap Overflow ECDSAWithSHA512

From https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-network-access-11-4-0/3.print.html :
DTLS uses UDP instead of TCP, to provides better throughput for high-demand applications like VoIP or streaming video, especially with lossy connections.
DTLS Port: Specifies the port number that the network access resource uses for secure UDP traffic with DTLS. The default is 4433.
See also: https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security


With respect to the problems with MS14-066/KB2992611: Susan Bradley has provided relevant information and links in http://blog.gmane.org/gmane.comp.security.patch-managment
Erik van Straten

122 Posts
I've not been able to find details on the certificate validation bypass aspect. Is there a write-up somewhere explaining what would be required to exploit this?
JeffSoh

31 Posts
I have 2 questions concerning this:

1. Is the ica protocol (Citrix) affected by this issue?
2. Is Citrix affected by the problems introduced in the update ms14-066?
Polloxx

2 Posts

Sign Up for Free or Log In to start participating in the conversation!