WannaCry: how the attack happened

Last Friday, the WannaCry ransomware worm outbreak hijacked hundreds of thousands of computers across the globe.

A typical ransomware attack begins with a phishing email loaded with a malicious attachment or link, which the user is tricked into opening. But, SophosLabs has resolved that the WannaCry attack probably didn’t start this way.

Yesterday, Sophos CTO Joe Levy dissected the outbreak. He showed how it spread on the back of an NSA exploit for Microsoft Windows SMB, which was leaked last month by the Shadow Brokers hacking group. Levy gave the technical perspective on what happened, how the attack worked, the timeline of events, how this latest attack can be prevented, and what to do now. 

• You can watch the entire presentation on Sophos’ webinar page.

Timeline and methods

Levy went into detail on the timeline of events and how the outbreak was able to spread so quickly.

The investigation revealed a three-stage attack, starting with remote code execution and the malware gaining advanced user privileges. From there, the payload was unpacked and executed. Once computers were hijacked, it encrypted documents and displayed ransom notes.

As we’ve noted previously, the attack exploited a Windows vulnerability Microsoft had released a patch for in March. That flaw was in the Windows Server Message Block (SMB) service, which Windows computers use to share files and printers across local networks. Microsoft addressed the issue in its MS17-010 bulletin.

The worm generated random IP addresses. Once the IP addresses were defined, the worm sent malicious SMB packets to the remote host, spreading itself.

Lessons learned

The outbreak drives home the need for companies to keep a close watch for patch updates and deploy the fixes immediately.

Some will criticize organizations that are slow to patch or use the latest Windows versions. It can be especially easy to blame the victim. But slow patching or the use of outdated versions of Windows isn’t always the result of laziness or apathy, as Levy noted in his presentation.

It’s long been the case that IT shops hold back some patches because they need to tweak their systems for compatibility. Otherwise, they risk deploying a patch that breaks other programs. Meanwhile, some organizations have continued to use old versions of Windows because:

• They lack the financial and human resources to upgrade.
• Their legacy systems simply aren’t yet equipped to work with the likes of, say, Windows 10.

There are other reasons, but those are two big challenges.

Common-mode failure

But in a Naked Security article earlier this week, Levy said there are cases when a patch shouldn’t be viewed as optional, no matter the company’s patching policy – like when the vulnerabilities fall into the category of common-mode failure.

Security luminary Dan Geer mapped out the problem in a column he wrote after the 2014 discovery of Heartbleed (Levy notes that he often refers others to the article). Among other things, Geer wrote:

Only monocultures enable internet-scale failure; all other failures are merely local tragedies. For policymakers, the only aspect of monoculture that matters is that monocultures are the sine qua non of mass exploitation.  In the language of statistics, this is “common mode failure,” and it is caused by under-appreciated mutual dependence.

The National Institute of Standards and Technology (NIST) defines common-mode failure this way:

A common-mode failure results from a single fault (or fault set).  Computer systems are vulnerable to common-mode resource failures if they rely on a single source of power, cooling, or I/O.  A more insidious source of common-mode failures is a design fault that causes redundant copies of the same software process to fail under identical conditions.

How does this apply to what happened Friday? Levy explained:

When a failure (and its attendant patch) involves the intersection of common components like SMB (which are present on every Windows system) and remote code execution, that’s a combination that should transcend policy.

In other words, in the case of these Windows SMB vulnerabilities, the patch should not be thought of as optional, irrespective of your policy (or non-policy) on patching. The danger of holding the patches back is that attacks like WannaCry have an easier time engulfing the globe.