Two weeks ago, on this very page (https://itcsecure.com/
Not ones to let those bearded types have all the fun, Microsoft has found a ladder, had a rummage in the attic of ancient code (Hello, Bob) and been attacked by couple of sleeping Meganeura Monyi (http://en.wikipedia.org/wiki/
They haven’t really got catchy names or a logo yet (the scary-internet-threats marketing department uses a Mac, after all) so we’ll refer to MS14-064/CVE-2014-6332 and MS14-066/CVE-2014-6321 as ‘The first one’ and ‘The second one’ and for now (and give up on a career in marketing).
The first one is a remote code execution bug exploitable through Internet Explorer that’s been around for a full 19 years – that’s every single version of IE since 3.0. Discovered by the IBM X-Force security researchers, it’s ultimately a weakness in the OleAut32 library which can be exploited through IE’s handling of VBScript. Technically this one is kind of interesting because the actual bug relates to data manipulation rather than your typical buffer overflow or use-after-free type errors. Don’t be surprised if we suddenly see a lot more of these kinds of vulnerabilities popping up over the next few months.
By virtue of the bug and exploit being relatively novel, Microsoft’s usually reliable Exploit Mitigation Experience Toolkit (EMET) couldn’t be relied upon to do its thing and stop the exploit in its tracks. Microsoft have since patched EMET with version 5.1 which should now work in this case, so we’d recommend updating that in quick succession to applying the actual patch. Thankfully this exploit doesn’t, as of writing, seem to be out in the wild. Normal IPS vendors have also had a chance to do their thing, so there’s a good chance to get solid protection in place whilst you test and deploy the patch, with end-user machines being the priority.
The second one then (MS14-066/CVE-2014-6321) is more of a server relevant vulnerability, and it’s another crypto one. Nobody quite knows the detail of what the bug actually *is* yet, but it affects the Secure Channel (sChannel) component of all Windows Server OS going back to 2003 and allows remote code execution from an unauthenticated attacker.
sChannel is the bit that does all the SSL crypto for Windows Server, so it’s fair to compare this to heartbleed in terms of potential severity. Cisco seem to have been in the loop on this one, their own ‘Talos’ security blog hinting (http://blogs.cisco.com/
One boringly geeky point on that potential for reverse engineering – Microsoft actually chose to back port four new SSL cipher suites into 2003 with the patch (some useful ones, too). On face value this looks a bit odd (technically it’s introducing new functionality, not a patch), until you realise that they were probably added to obfuscate the actual fixes amongst a whole lot of assembled crypto code – quite a classy fix. You probably have a couple of weeks until someone figures out how to make this one wormable and in the meantime there’s no excuse for not patching all those IIS, OWA and Lync servers – any Windows Server facing the outside world that speak SSL basically (and then do the inside facing ones). If you terminate your SSL sessions on something like an F5 or other Load Balancer you’re probably OK (as long as you patched for all the OpenSSL stuff, right?).
Given the rate these 0-days are coming out, we’re sure everyone must have a solid vulnerability management strategy in place by now. Of course if, by any chance, that’s the kind of thing you think you could do with some professional help with then feel free to drop us a line at [email protected] and we’ll help put you on the path to secure networking zen.
