So the other day I got blindsided with a question at work: What are we doing about Winshock. Winshock, I asked? I had to go look it up, and I found that’s what they dubbed what I’ve been calling MS14-066, the vulnerability in Schannel, which is Microsoft’s implementation of SSL/TLS for Windows.
Based on that, I’d argue it has more in common with Heartbleed than Shellshock, but I guess “Winshock” is catchier than “Winbleed.”
Then the lead of another team asked me to brief his team on Winshock. I actually managed to anticipate all but three of the questions they asked, too, which was better than I expected. Some of what I shared with them is probably worth sharing further.
Perhaps the reason they didn’t call this “Winbleed” is because Windows actually uses Schannel for more than just web communications. It’s also used to encrypt communications for Active Directory and Remote Desktop, among other things. Almost any Windows machine has those two things enabled, so this is a pretty big deal.
I actually warned the Windows Server team at work that this was going to get a lot of attention back on Patch Tuesday. So they diligently started applying it, and then it had problems and got re-issued near the end of the month. Some months you just can’t buy a break, let alone catch one, and that’s the story this month. This is why we have test servers.
Heartbleed led people to investigate other implementations of SSL and TLS, because if OpenSSL got it wrong, chances are others did too. Encryption is a tough thing to get right. In this case, IBM researchers found some issues in Windows and privately reported them to Microsoft, who released a patch last month. Don’t be surprised if other problems along these lines surface in coming weeks and months–stuff like this has a tendency to come in waves, because there’s a lot of code out there that hasn’t had a lot of attention in a very long time.
This particular Schannel problem has existed since at least 1995–it’s present in Windows 95–and although I can’t prove it, I wouldn’t be surprised if it existed in Windows NT 3.1. So the problem exists both in the Windows 9x and NT families, though it’s only patched in current, supported Windows versions. Vulnerabilities like this are the reason you can’t just run a Windows server forever minus one day. I wrote a few risk acceptances in my day at previous jobs for Windows NT 4.0; for their sake I hope those old boxes are gone now.
What about Windows XP? If you’re on paid support, Microsoft did release a Windows XP patch for this. If you’re not on paid support, I hope your migration to Windows 7 or Windows 8.1 is almost done. EMET theoretically provides some protection against this, if you’re running it, and while I can’t speak for all corporate antivirus solutions, Symantec Endpoint Protection’s IPS has a signature for this so it can deflect at least some attacks as well. But it’s best not to rely solely on mitigations like these indefinitely–get on a supported operating system, get the patch down, and rely on the mitigations to protect against the unknown rather than the known, because you cannot assume your mitigations are infallible.
There are proof-of-concept exploits against this vulnerability, and there are rumored to be targeted attacks from advanced attack groups that use it as well. Right now the proof-of-concept exploits just crash the service you point them against, but a good remote code execution exploit is nothing more than a controlled crash, so remote code execution using this is almost certain to appear at some point. I’ve seen some fuzzy video of demos of an exploit, but they aren’t much to look at. If I told you they were crashing Excel, I doubt you could prove me wrong from looking at it.
The team asked me if I could tell where the patch had taken, and of course I said yes. Then they asked what they could look for if my tools are wrong and the server is actually vulnerable when I think it isn’t. That’s a smart question to ask because you always want to have multiple backup plans when your organization has valuable data.
I said to pay attention to the remote desktop service, IIS, and anything related to Active Directory–but especially remote desktop, since that’s something that everyone is going to expect to be running. Normally those services are going to be pretty solid. If they’re stopping and restarting, or just flat out stopping and staying stopped, to me that could be an indication of someone trying to exploit this–especially if they’re stopping on multiple machines.
David Farquhar is a computer security professional, entrepreneur, and author. He started his career as a part-time computer technician in 1994, worked his way up to system administrator by 1997, and has specialized in vulnerability management since 2013. He invests in real estate on the side and his hobbies include O gauge trains, baseball cards, and retro computers and video games. A University of Missouri graduate, he holds CISSP and Security+ certifications. He lives in St. Louis with his family.