The vulnerability defined in MS14-066 (CVE-2014-6321), or “Winshock” as the media has dubbed it, has been categorized as a critical risk due to the potential impact that includes denial-of-service, information disclosure, and unauthenticated remote code execution. Microsoft describes Winshock in KB2992611 as the “improper processing of specially crafted packets by the Secure Channel (SChannel) security package.” This package is closely linked to critical system services, and this condition creates the possibility for a remote, unauthenticated attacker to obtain SYSTEM-level access. That is, undoubtedly, the worst-case scenario which could plausibly become the precursor to worms and other widespread damage.


At its heart, the SChannel package is responsible for securing network communications with the SSL and TLS protocols. Numerous Microsoft service implementations including (but not limited to) IIS, Active Directory, Outlook Web Access, the Remote Desktop Protocol, and Internet Explorer utilize the SChannel package. However, due to the immediate lack of detailed technical information, it is currently unclear which of these services may genuinely be affected by this vulnerability.

For a detailed explanation on how to exploit the vulnerability, refer to the in-depth technical blog post by Beyond Trust that analyzes the patch and demonstrates how specially crafted SSL communications can be leveraged to target the vulnerable code and crash the operating system. The demonstration proves that not only is remote code execution theoretically possible, but that a simple denial of service condition is easily achieved by making a minor code change to the open source OpenSSL library.

It is important to note that the default IIS configuration does not accept client certificates. Additionally, other SSL/TLS-enabled services, such as Terminal Services, do not support client certificate configurations. However, new research demonstrates that (thanks to a second “bug” in Schannel) a malicious client certificate can still be utilized to trigger the vulnerability simply by configuring the attack technique to ignore the server configuration and submit the client certificate. While the service itself would ultimately ignore the client certificate in such a scenario, it will still be analyzed by the vulnerable SChannel code. In this case, any SSL/TLS service that utilizes the SChannel package, which includes all native Windows services, is conceivably vulnerable to exploitation.

At the moment, there are no publicly accessible exploits, nor have there been any reported cases of exploitation in the wild. However, Immunity Inc. has released a proof-of-concept exploit for subscribers that have access to their CANVAS Early Updates program. While the quality and reliability of this proof-of-concept are not disclosed, its existence confirms the feasibility of exploitation.

The technique demonstrated by Beyond Trust utilized client certificates to reach the vulnerable code. It is worth noting that Winshock appeared to address multiple code flaws, so client certificates should not be considered to be the only and definitive attack vector at this time. While a client certificate-based vulnerability would lack the prevalence of other recent SSL/TLS vulnerabilities, such as Heartbleed and POODLE, defending services affected by Winshock could arguably be a higher priority.


At this time there is no definitive way to determine if systems are vulnerable to Winshock. Anexia-it released a script that tests for the presence of four (4) ciphers that will exist on a system that has been patched against Winshock. This test, however, is not a guaranteed way to determine a system’s status in regards to Winshock. Microsoft includes a list of impacted Operating Systems (“OS”) in their MS14-066 advisory. If a system in your environment runs on an OS listed in the advisory, it would be safe to assume the system is vulnerable and proceed with mitigation steps to prevent system exploitation.


Patching for Winshock is a largely straightforward task, and public-facing servers should obviously be prioritized due to their increased exposure. However, there are significant concerns that should be considered before applying the Microsoft supplied patch. The most common concern is the potential for negatively impacted performance.

Various well-known vendors, such as Amazon, Blackberry and IBM, have reported noticeable application performance degradation, TLS session disconnections, and SQL server performance issues. Reports of performance problems extending to client applications, such as web browsers, have surfaced as well.

Microsoft has been largely silent on these issues, and the lack of guidance makes remediation all the more problematic. On the one hand, this is a critical system vulnerability that should ideally be patched post haste, but on the other, the patch may immediately harm the organization in an alternate manner.

Before installing the patch from Microsoft, GuidePoint highly recommends carefully examining your environment to determine if installing the patch is worth the potential risk of performance degradation, and to prepare a rollback strategy should problems arise after installation.

Intermediary security controls and alternate SSL/TLS configurations may provide an ideal, short-term solution for some organizations. GuidePoint recommends contacting your inline network and host-based security control vendors to determine whether signatures have been developed to block attacks prior to reaching the vulnerable service.

Additionally, Non-Windows SSL/TLS proxy servers and offloading appliances may prevent attacks from succeeding against the underlying Windows service, but these configurations should be thoroughly tested to ensure that malicious requests are properly dropped or modified and cannot be used to successfully exploit the service.