What is your reason for not patching MS17–010 — the main vulnerability behind WannaCry?
May 14 2017 Filed in: Cyber Technology
In April 14 2017, Shadow Brokers released information about an exploit tool written by the NSA called Eternal Blue. This tool exploited a zero day in Microsoft Windows covered by their MS17–010 update. The patch proceeded the disclosure as Microsoft issued MS17–010 on March 14, 2017. The WannaCry worm first got heavily noticed on Friday, May 12, 2017.
There were almost 60 days between the Microsoft patch and the worm. The patch was marked “Critical” and had ominous text in it such as:
Embedded Windows Systems
"The most severe of the vulnerabilities could allow remote code execution if an attacker sends specially crafted messages to a Microsoft Server Message Block 1.0 (SMBv1) server."
I asked a wide variety of operational experts why this vulnerability didn’t get patched in their organizations and have collected the reasons with commentary.
Patching In the Enterprise is a Dirty Business
There were many stories in the past few days of MRI, X-Ray and other medical equipment run by a computer being impacted by MS17–010 and targeted by WannaCry. Unlike laptops and servers, this equipment is leased and operated by technicians and not managed by the IT department. This makes patching them very slow and difficult. In some cases medical equipment is providing direct care to a patient and can’t be removed without rising harm or death to the patient themselves!
WannaCry exposes another issue with these medical and other types of embedded systems — they are not segmented. There is nothing wrong using older legacy and hard to manage devices if they are properly secured. In most of the crippling stories we are reading about, WannaCry infects a laptop and then scans the network and directly attacks an embedded device. Secure network design leveraging firewalls, VLANs, routers with access control lists or even solutions like Cryptonite, all could prevent this type of attack.
A common excuse I’ve heard for years is that previous patches from a vendor caused disruption and outages. In the case of MS17–010, earlier patches in 2017 and late 2016 had caused issues with stability and operations of their Windows environments.
It’s important to realize that when something like this happens, the public doesn’t realize it because it is self-inflicted by the organization. For example, when WebRoot or Mcafee gets a signature wrong, it makes news. When was the last time you’ve heard of Microsoft having to issue an apology for patch quality? However, many enterprise patching teams feel justified not pushing patches out right away.
Do You Run A Honeypot?
What’s happening here is that organizations add a few layers of complexity to their environments. First, they have many different flavors of Microsoft with different configurations, software and third party management tools. Second, they manage these systems with third party software such as IBM, Symantec and even Microsoft. Third, the organization has different rules in place for when patches are supposed to be deployed. And fourthly, assessing when a patch is in place is difficult. Does the machine need a reboot? Did an old DLL get rolled out with a backup restore job? All of these issues make each organization a unique configuration and makes it really difficult to get everything right and stable all the time.
Too Important to Patch — Systems And Organizations
At Tenable, one of the best examples of evidence I can offer for this is the Nessus feature that checks the state of the system being patched against the state in the patch management system itself. Think about that for a minute. Because we had enough customers complain that Nessus found a vulnerability, but the IT team’s patch management system said there was no vulnerability, Tenable did a tremendous amount of R&D to automate and discover what was really going on. This is often exaggerated in times like these when many groups not normally involved with vulnerability management or patch auditing are suddenly consumed with finding and eradicating a vulnerability.
I was surprised that more than one person suggested that these “older” versions of Windows make great targets to learn about your adversaries. If your organization has the bandwidth to support this sort of research, I’d like to think they also had the presence of mind to secure the network layer to prevent lateral movement to production systems and infect other people on the network. If honeypots and deception are your thing, I suggest Trapx.
Another example I hear is that a system cannot be patched because it is too important. The system itself is so important and fragile, that it is better to let it go unpatched than to risk patching it and not having it come back. Hopefully the system has a layer of compensating controls around it to prevent exploitation.
I Thought The Firewall Would Save Me — Misplaced Controls
Similarly, I’ve seen organizations attempt to “freeze” all IT changes to increase the reliability of the network. Reasons here include the holiday shopping season, a public company’s reporting period and company mergers. If IT changes are so bad that stopping them makes your network better, making the business recognize this should be a priority.
If this is in your organization, you are not fighting a technology issue — you have a real business risk. You should use the crisis of WannaCry and come up with a strategy to move your group into the modern age. This is no small feat and I’ve seen these types of struggles become religious battles with career limiting effects. If this seems to be where you work and you are looking for ideas, we can go back to nearly the turn of the century to the IT Process Institutes — “ Visual Ops “ guides for managing IT and arguments to get the business to transform.
It’s not often, but I do run into organizations who have an astute awareness of their defenses in depth and feel that they can run safely with unpatched systems. Auditing your defenses is a big reason why I’m a fan of Tenable’s ability to look at your defenses as prescribed by the NIST Cyber Security Framework. I’m also a fan of checking on specific security vendors with automation provided by ThreatCare. In both cases, audits can find blind spots in your sensing and controls that prevent lateral movement and attacks.
There are many reasons why systems continue to not be patched. I leave you several thought provoking questions you can use to re-assess your organization’s decisions to not patch:
- Is this a risk decision that you’ve made for your business without their consultation?
- Has your industry approached this problem differently than you have?
- If you have an existing compensating control for this patch, will your auditor continue to sign off on it after WannaCry?
- Does a WannaCry infection create any PCI or other types of compliance issues where you thought network segments were isolated?