The lesson of Sandworm: patched but not protected

In the IT industry, we know how important it is to stay on top of the security updates that are issued by software vendors on a regular basis. Unpatched machines account for numerous malware infestations and attacks that can result in network down time, leaks of confidential information, and more. But just because you diligently apply each and every patch as soon as it’s released, don’t assume that you’re necessarily protected from the exploits that those patches are designed to address.

The Sandworm attack is a good case in point. This is an exploit of the Windows OLE remote code execution vulnerability, officially designated CVE-2014-4114, in Windows Vista, 7, 8/8.1 and Server 2008/2008 R2 and 2012/2012 R2 (in other words, all currently supported versions of Windows with the exception of Server 2003). It was discovered not long ago that a Russian cyber espionage group was using the exploit to infect computers with a Trojan called BlackEnergy, and this had been going on at least since last summer.

Using the vulnerability, an attacker can gain the same user rights as the user who’s logged on, and in the case of an administrative account can run code or take completely control of the machine. The Sandworm attackers take advantage of the weakness in OLE by embedding the attack in a PowerPoint file animation. Simply viewing the animation infects the machine, and the animation runs automatically when the presentation is viewed.

Microsoft issued a patch to address the OLE vulnerability as part of October’s Patch Tuesday releases, MS14-060. However, over a week later, researchers discovered that attackers were still continuing to exploit the vulnerability, bypassing the update’s supposed fix by embedding the malicious file into an OLE object directly rather than having it download from a remote location. The new vulnerability was labeled CVE-2014-6352.

On October 21, Microsoft issued a warning to users about the new attacks. The advisory warned that in addition to Microsoft Office files, many third party file types could also contain malicious OLE objects that could exploit the vulnerability.  The company created a “Fix It” solution that could be manually updated to address the new problem.

It wasn’t until this month’s Patch Tuesday, November 11 – a month after the first patch that was intended to fix the OLE problem – that a full patch was made available to (we hope) take care of CVE-2014-6352. That fix is part of MS14-064, which also patches another OLE vulnerability, CVE-2014-6332.

This is by no means a unique situation. When a serious vulnerability in a particular software component surfaces, security researchers – along with attackers – often turn their focus to that component in hopes of finding more vulnerabilities or discovering ways to devise variations that will allow them to bypass vendors’ initial attempts to plug the holes. Because patches for serious bugs are often developed and released in a rush, to attempt to head off widespread exploits, those first patches sometimes fail to completely address the problem.

Complacency is a dangerous thing, and IT pros and users need to always be aware that simply applying the patches may not offer 100% protection. Because patching is a reactive process and cyber criminals are a clever bunch, they’re frequently two steps ahead as software vendors scramble to catch up.