Double Kill, a Prodigy of Zero-days, and what We Can Learn from It

In late April, a Windows zero-day attack was discovered in the wild that affected all supported versions of Windows. Microsoft released a patch on May 8th to address the issue. This zero-day, dubbed Double Kill, exploits a VB script vulnerability, and potentially affects any system from Windows 7 onwards, including servers.

What does this allow attackers to do?

The bad news is that it allows attackers to execute code remotely. The good news is that it requires user input. The even badder news is that attackers will find a way to convince your users to execute this code.

Once run, the attacker has execution capability within the context of the VBScript engine. If your users are administrators, you are in a bad spot. If you have locked-down end-user permissions, without local permission-escalation, you are, theoretically, going to live through this.

What is it?

The vulnerability is the result of a use-after-free bug. If an object exists in heap memory as part of an array, before deletion of the array – which frees the memory associated with the objects within it– an attacker can create a reference to one of the array objects. Calling a deprecated method to delete the array object before initiating deletion of the array allows the attacker to take advantage of an inconsistency between the deprecated method and expected method of freeing memory. The deprecated method has made the array one object smaller, so the expected deletion accepts that the memory for the entire array is properly released.

The results is a dangling pointer, which is a reference to memory that has been freed (after being occupied by the object in the now-deleted array). This can be exploited by an attacker to run arbitrary code with the same level of privilege as the user.

Specific attacks encountered in the wild first deliver a document to a target. If the user opens it, Word opens a malicious web page within the document using Internet Explorer, even if it’s not the default browser. The malicious web page contains the code required to exploit the vulnerability.

Details of the vulnerability can be found here.

In the wider landscape, what should I expect?

Attackers will continue to adopt this exploit, and they’ll do it faster than most organizations can apply the patch. We saw this with EternalBlue, and we’ll see it again now, and again with the next thing.

Expect the usual mix of crypto-attacks; ransomware and crypto-jacking, because these are the clearest paths to revenue for groups behind mass, automated attacks.

Also expect a wave of opportunistic focused attacks. These are perpetrated by groups seeking to gain access via a combination of phishing and zero-day attacks. They don’t make their presence obvious because they are looking for a different path to revenue than the crypto-types.

How do I protect my systems from this, and future zero-day attacks?

This attack is a zero-day, meaning it was actively exploiting systems in the wild before security researchers discovered and reported the vulnerability. First and foremost, patch as soon as possible --very few security solutions offer robust protection against zero-day attacks.

A recent solution for tackling zero-days before a patch is available and applied is Hypervisor Introspection – which protects workloads from outside the operating system, by detecting zero-days inside raw memory, at the hypervisor level.

Here is a short video of Hypervisor Introspection defeating this attack. The first half demonstrates code execution by launching the calculator application. In the second half, the same attack is executed, and blocked.

 

 

Hypervisor Introspection (HVI) is exceptional thanks to its ability to protect kernel memory and user memory with zero VM footprint. It effectively identifies common memory-manipulation attack techniques by leveraging an API within the hypervisor and protects the in-guest code from being disabled or bypassed directly at the raw memory level, rather than relying on in-guest agents or on the operating system.This is why HVI blocked EternalBlue before the release of EternalBlue. This is also why HVI blocked this latest zero-day attack before it was discovered. It’s no surprise to the teams at Bitdefender -- HVI was built for this.

What is the bottom line?

Patch. If a security vendor tells you otherwise, politely guide them out the door.

Hypervisor Introspection is a solution for workloads running on XenServer. By looking for memory manipulation techniques using the Direct Inspect APIs in Citrix XenServer, Hypervisor Introspection has full contextual awareness of memory activity within live virtual machines, yet is isolated from those machines since no software is installed within them.

If you’re technically-minded, check-out how we can publish browsers with Citrix that are protected by HVI here: https://www.citrix.com/blogs/2017/01/11/secure-browsing-with-citrix-bitdefender/