freshidea - Fotolia
SSL/TLS security: Addressing WinShock, the Schannel vulnerability
Schannel is the latest cryptographic library to encounter SSL/TLS security issues. Expert Michael Cobb discusses the WinShock vulnerability and how to mitigate enterprise risks.
The SSL/TLS protocol has been in the headlines over the past year for all the wrong reasons.
Vulnerabilities and implementation issues in cryptographic software libraries -- such as Apple's SecureTransport, OpenSSL, GnuTLS and Mozilla's NSS -- have had vendors and administrators rushing to mitigate potentially serious flaws that threaten networks, users and their data.
Microsoft's Secure Channel, or Schannel, is the latest cryptographic library found to be vulnerable to attack.
In this tip, I discuss the details of the WinShock flaw in Schannel, how it stacks up against other SSL/TLS vulnerabilities, and the best ways to mitigate the threat.
Schannel and the WinShock flaw
Schannel is Microsoft's implementation of the SSL/TLS protocol, similar to how OpenSSL is used by Linux systems. It's a component found on all Microsoft Windows platforms, and is used by most Windows software that requires SSL/TLS encryption and authentication services, such as IIS, Active Directory, OWA, Exchange, Internet Explorer and Windows Update.
In November, Microsoft released Security Bulletin MS14-066 to address a vulnerability found in Schannel, dubbed WinShock (it appears every serious vulnerability now needs a catchy and alarming name).
By sending specially crafted network traffic, a remote attacker could exploit the WinShock flaw and execute arbitrary code on a server or client, allowing the attacker to infect the target with malware. It may be possible to stage an attack without authentication and via unsolicited network traffic, which is why the vulnerability is so serious.
WinShock should be patched as soon as possible. According to Microsoft, there are no known mitigations or workarounds; it even bypasses the Enhanced Mitigation Experience Toolkit (EMET) mitigations.
An enterprise's most vulnerable Windows devices are those reachable from the Internet -- like Web and mail servers -- so these should be top priority. Next, enterprises should focus on patching internal servers, then mobile devices, and finally internal clients.
Administrators should assume all devices running Windows are vulnerable and use the asset registry to ensure none are overlooked, as forgotten VPN, instant messenger and other software may be listening for inbound SSL connections. Be sure to update network defenses to detect and block attempted exploits of this vulnerability; Cisco has already published a number of Snort rules for MS14-066.
How WinShock stacks up
There is some confusion over the true nature of the WinShock vulnerability, how it was found and by whom, and whether CVE-2014-6321 actually covers more than one vulnerability in Schannel.
While the update addresses the vulnerability by correcting how Schannel sanitizes specially crafted packets, Microsoft also included changes to available TLS cipher suites. Though offering more robust encryption, the ciphers caused problems for some systems running Server 2008 R2 and Windows Server 2012, as TLS 1.2 connections were dropped and services became intermittently unresponsive.
Microsoft subsequently rereleased the MS14-066 update so the new TLS ciphers aren't enabled by default. This update, number 3018238, will install automatically with the security update for MS14-066. If systems already have the MS14-066 update installed, it will be reoffered to make sure the new cipher update is installed. Applying these new updates will require a reboot.
Any remote code execution vulnerability affecting all versions of Windows servers has the potential to be worse than Heartbleed due to the large number of affected systems. However, WinShock appears to be harder to exploit and simpler to patch than Heartbleed, so it should be easier to contain.
Despite assigning WinShock an exploitability of "1" -- which indicates that an exploit is likely to be developed soon -- Microsoft's assessment is that it will be difficult to create a reliable exploit. (Microsoft's patches don't include source code, but hackers will reverse engineer them to learn more about a vulnerability to develop viable attacks.)
Exploit code for the Heartbleed and POODLE vulnerabilities already existed when they became public knowledge, and exploitation was relatively undemanding. That said, they both led to only information disclosure and not remote code execution.
A big concern now is that as things stand, WinShock is a forever-day vulnerability for Windows XP and Windows 2000, as these systems are no longer supported by Microsoft. This is another strong incentive for enterprises to upgrade from these outdated operating systems. If Microsoft doesn't relent and release security patches for these versions, administrators will have to isolate and remove any machines running them, as they are both exploitable and un-patchable.
Vulnerabilities like WinShock and Heartbleed show the importance of maintaining up-to-date asset registers so administrators know which devices or software are potentially at risk when a critical vulnerability is discovered. This makes patch prioritization faster and easier, and ensures no devices or systems are left exposed.
About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with over 20 years of experience in the IT industry. He co-authored the book IIS Securityand has written numerous technical articles for leading IT publications. He was also formerly a Microsoft Certified Database Manager and a registered consultant with the CESG Listed Advisor Scheme (CLAS). Mike has a passion for making IT security best practices easier to understand and achievable. His website www.hairyitdog.com offers free security posters to raise employee awareness of the importance of safeguarding company and client data and of following good practices.
Get the latest on SSL/TLS security from SearchSecurity
Learn more about POODLE's effect on SSL/TLS security
Check out Heartbleed and the current state of open source security