Blog
05.16.2017

Protecting Server Endpoints Against WannaCry

By now, all of us in the cyber security industry have heard of, and hopefully not been affected by, the WannaCry Ransomware attack of May 12th. As of this writing, over 230,000 endpoints across over 150 countries and counting are reputed to have been affected by this sophisticated attack that crippled hospitals in the UK, a major telecom provider in Spain and reputedly even a major multinational in the US (Fedex).

Kudos to key individuals such as the MalwareTech analyst that were critical in helping stop the spread of the outbreak (through a URL registration that activated a kill switch and became a sinkhole for the original attack). That said, it’s very likely the malicious actors as well as copy cats are creating variants of the attack as we write and like aftershocks after a major earthquake, this could continue to be an issue in the coming days and weeks.

There are very good dissections already published of how the WannaCry Ransomware Outbreak works, although we’ve found few that are fully detailed to get the full picture. We’re adding a graphical representation to the conversation (see below). From our research, here are five important takeaways we see related to this massive attack: 

1)-Memory Corruption attack on vulnerable servers, not phishing, is the key propagation vector of WannaCry. While the jury is still out on how the WannaCry outbreak started, given the multiplicative effect of the worm, there is no doubt that the memory corruption propagation vector far outnumbers the phishing propagation vector. Instead of better phishing email filters, better memory corruption detection and prevention techniques are needed.

2)-WannaCry used file-less attack techniques on public facing servers. The DOUBLEPULSAR payload in memory not only launched the ransomware attack but also created several threads that attacked other victim machines both in the internal network as well as servers accessible over the Internet. As expected, this memory based attack totally blindsided signature and heuristic approaches.

3)-Zero-day vulnerabilities in OS and third party binaries continue to be applications’ Achilles heel. We continue to treat third party binaries as black boxes. The fact that advisories are now saying servers running the SMB should not be exposed to the Internet is truly Monday morning quarterback advice. The common theme across the most impactful attacks such as glibc, Heartbleed and EternalBlue, is that they all leveraged memory based attacks. It is clear that we ignore these OS and third party binaries at our own peril.

4)-This is another example of why relying on SDLC is problematic. Ultimately, given the size and complexity of the code, it is very difficult for even Microsoft to find and remediate all vulnerabilities. Here we are talking about a leading software manufacturer to put out safe and impenetrable code. Even if the code could somehow be made fully secure, advanced techniques like Library Injection, as we saw in WannaCry, can be used to inject malicious code into any process at run time.

5)-Relying on patching is a flawed strategy. The attack leveraged the EternalBlue vector to successfully exploit a vulnerability of the SMBv1 code in Windows 7 and Windows Server 2008, both of which were released a decade ago. The extent of the damage caused demonstrates that a version of the OS released almost a decade ago still has a big deployed footprint. Furthermore, as WannaCry proves, even if Microsoft had a patch available, it is simplistic to think that enterprises will deploy the patch at all or in time to protect themselves. Many organizations simply cannot afford the downtime or are simply not disciplined enough to do so.

We believe the image below provides a nice pictorial way to summarize how WannaCry works. We’ve added the early detection and prevention points for Virsec Platform, our mainstay technology, in that process.

 

 

Illustration: Virsec Platform against WannaCry Ransomware Attack

 

Whether the initial infiltration and subsequent weaponization results in a simplistic attack such as denial of service or a highly sophisticated attack like WannaCry, Virsec Platform can detect attempts to infiltrate in real time and deterministically – without false positives.

Here are the key ways Virsec Platform could have helped prevent this attack: 

1)-Virsec Platform prevents infiltration using memory based zero-day exploits like NSA’s EternalBlue. Regardless of whether Microsoft had ever released its patch for the SMB server or not, Virsec Platform's Trusted Execution technology would have immediately detected memory based attacks such as WannaCry. It detects EternalBlue and DoublePulsar, both memory based attacks, and signals DFIR analysts within microseconds. Increasingly, we see the need for our customers to protect core OS-level processes with our memory-based protection, particularly those that have open network ports or processes running with elevated privileges.

2)-Virsec Platform also prevents infiltration through web applications. Ostermann Research has found that one out of four times, ransomware such as WannaCry spreads through vulnerabilities present in business logic of web applications. See video below for a demonstration of how a SQL injection attack at the web layer can be used to orchestrate a ransomware attack. It’s important that applications be protected full-stack, from binaries to business logic and from Web Servers to Database servers.

3)-Virsec Platform stops privilege escalation attacks. Typically, an advanced hacker will look for processes running with root privileges and utilize library injection techniques to take control of various system resources such as files, and I/O devices like webcams, keyboards etc.

4)-Virsec Platform signals when attackers attempt to erase their footprint. Any CRUD operation on the file system like clean-up activities are detected and reversed. Virsec Platform's Remediation Connector provides real time remediation response to various alerts through customized call backs.

In summary, advanced attacks follow a “kill chain”. Today, the process of analyzing kill chain events is highly manual, subjective and much too slow to respond to the rate at which the attack propagates.

Virsec takes a radically different approach for detecting advanced attacks on the full application stack (from binaries to business logic) from individual servers (including VMs and Containers) to complex multi-tier applications.