See also:

Those contagions – ancient malware by today’s standards – spread through exposed Microsoft vulnerabilities. WannaCry spread the same way. In each case, Microsoft had already released a patch for the security holes.

And so for some, an important lesson continues to go unrecognized: that organizations must keep a close watch for patch updates and deploy the fixes immediately.

Deja vu

WannaCry – also known as Wanna Decrypter 2.0, WCry, WanaCrypt and WanaCrypt0r – exploited a Windows vulnerability that Microsoft 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.

Sophos Home

It hit organizations across the globe, including National Health Service hospitals (NHS) in the UK. Analysis seems to confirm that the attack was launched using NSA code leaked by a group of hackers known as the Shadow Brokers.

It’s likely that some were infected because they hadn’t gotten around to applying the MS17-010 patch. But others suffered because they were running older, unsupported Windows versions and, as a result, never received that security update. For that reason, Microsoft took the highly unusual step of making a security update for platforms in custom support (such as Windows XP) available to everyone. The software giant said in a statement:

We know some of our customers are running versions of Windows that no longer receive mainstream support. That means those customers will not have received the Security Update released in March. Given the potential impact to customers and their businesses, we made the decision to make the Security Update for platforms in custom support only, Windows XP, Windows 8, and Windows Server 2003, broadly available for download here.

Conficker is a widespread network worm that began to spread to millions of unpatched PCs in 2008. The first samples detected at the virus testing service Virus Total were spotted in SophosLabs on November 21 2008. It spread by exploiting a buffer overflow vulnerability in the Windows Server service. That flaw was patched by Microsoft on October 23, 2008 — 29 days before Conficker began its assault.

Slammer began its attack in early 2003, exploiting a vulnerability in Microsoft’s SQL Server database software that had been patched six months earlier. Many of the affected computers were corporate SQL servers, which allowed the worm to quickly acquire a lot of CPU juice and network connectivity. So when this headline appeared, it was no exaggeration at that point in time:

Indeed, there were some unique aspects to the WannaCry attack. Typical ransomware infections happen after the victim clicks on a malicious email attachment or link. In this attack the malware was able to exploit a remote code execution (RCE) vulnerability that allowed it to infect unpatched machines without users having to do anything. The attacker’s use of the leaked NSA code likely had something to do with that, though there’s still a lot to learn about this event.

Why some don’t ‘patch now!’

Regardless of those details, the fact remains that this was made all the worse because available patches were never applied.

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.

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 Sophos CTO Joe 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.

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.

More defensive measures

The best advice is still for organizations to keep their patching up to date and use current versions of Windows.

About the author

I work in an organization that uses the excuse of “lack the human resources to upgrade”. It’s a poor excuse. If you have the financial and human resources to launch new services and applications part of the planning has to include on-going maintenance and support after initial launch. Too often you see new service deployed and then forgotten. This is a management issue that hasn’t been acknowledged in the over 10 years I’ve been in the IT profession.

There’s also the issue with patching. As M$ suggest, patching should be done using a ringed approach. Firstly some test workstations & servers before deploying to the population.
Only this year (feb 17) did M$ screw up their monthly updates which resulted in no monthly updates for February. Most admins are mindful of this and we wait a week or so (after monitoring various media) to ensure that there are no issues with the latest patches before we start to apply them.
You also have the issue of rebooting too. No reboot equals no patch. Rebooting 100 servers is no mean feat when you run a 24/7 service. You also have the issue of mobile devices that might be away from the network for some period and do not patch when outside.
There’s all sorts of issues and it’s simply not as easy as some would like to make out.

The vast majority of home users (and many enterprise users) don’t use SMB protocols. Why would this (and many other rarely used services) be enabled by default? Or be enableable without explict, unfakeable user interaction, e.g.,
“Application WannaCry wants to enable Server Message Block. If you trust this application and initiated this action, click Yes. Otherwise click No.
|Yes|No|

Microsoft defaults make the system less secure than it could be. How about proactive messages like: “Server Message Block Protocols haven’t been used in the last 30 days. Shall we disable them, giving added security, reduced power usage, and reduced memory footprint? Click Yes to disable, No to maintain. If you disable Server Message Block and later need it, you will be prompted to re-enable it.”
|Yes|No|

Thanks god we had already installed the “March 2017 Security Monthly Quality Rollup for Windows Server” on all the servers.
It has really a big lesson to all which ignored the security concerns and have let go attitude about it.