Get notifications!

Where Healthcare Management, Spectre and Meltdown Meet

It’s been a year since Spectre and Meltdown — the hardware vulnerabilities discovered collaboratively by Google’s Project Zero and others — went public. Those vulnerabilities rightly garnered great attention as they and later exploits built in their image affected almost every contemporary CPU on earth. From a handheld smartphone to user workstations, servers and cloud machines — every system running some operating system on a chip was affected. And that includes medical devices too.

Some Context

Spectre and Meltdown are the names given to two specific attack paths exploiting critical vulnerabilities in modern processors. What is so unique about these vulnerabilities is that the weakness resides at the hardware level — potentially allowing a malicious program to bypass security primitives deployed in the hardware.

The vulnerabilities underlying these attack paths are such a big deal because basic defenses like anti-virus products and EDR agents can’t get off the ground without relying on hardware primitives. With those primitives sidelined, there’s no way for devices to run safely (in a privileged mode), monitor their systems, isolate processes, apply controls to combat malicious activities, limit the effects of malware, and protect the operating system kernel.

How it Works: Hack Attack

A Spectre exploit breaks the isolation between different system applications and allows a malicious program to read other programs’ memory and leak information from it — regardless of privilege.

Similarly, Meltdown — as its name implies — melts the fundamental isolation between user applications and the operating system, opening the door for a malicious program to glance a “sneak-peak” at the memory of other processes and the kernel.  

Technically speaking, a Spectre-based attack requires a greater level of skill from the malicious party and is harder to pull off.  On the flip side, a successful Spectre attack is somewhat more difficult to effectively mitigate than a Meltdown attack.

Either way, the consequence is the same. So long as a malicious code built around these vulnerabilities manages to run on a device — no matter with what privileges — it can leak information across the system, including sensitive information and passwords.

protecting-healthcare-against-spectre-meltdown

What’s worse, the ability to read kernel memory makes it possible for a malicious process to escalate its own privileges and gain nearly full control of the system.

To put that fact in context, for other attacks to compromise a device the extent of a Meltdown attack, it would typically require a code execution followed by a privilege escalation. Meltdown, however, raises the stakes of otherwise banal attacks and lets  hackers cover more ground with fewer steps – giving anyone who can run code on a device the keys to the castle.

What Hath Man Wrought

Practically every system on earth was affected by Spectre and/or Meltdown. Any Intel processor that implements out-of-order execution offers a potential playground for those attacks to run wild. To be clear, that’s nearly every processor since 1995 (except Intel’s Itanium and Atom chips produced before 2013). Researchers have also verified that these attack paths are effective on (at least some) AMD and ARM processors.

Adding insult to injury, exploits of these vulnerabilities are unlikely to be detected let alone blocked by anti-virus services, as those technologies struggle to distinguish Spectre and Meltdown behavior patterns from those of benign applications.

While there are no known cases of Spectre or Meltdown exploits in the wild, that doesn’t mean they didn’t happen. Someone benefiting from these types of attacks, stands to continue benefiting so long as he or she can evade detection.

With anti-viruses ill-disposed to catching wind of these attacks and bad actors strongly disincentivized from boasting of their exploits, we’re unlikely to ever confirm a breach – which makes it hard to measure the impact. That said, there are a few important points to bear in mind when considering the fallout:

  1. The fact that responsible parties only discovered and disclosed these vulnerabilities now does not mean that irresponsible parties never noticed it. Chips have featured these weaknesses for over 20 years, giving bad actors looking for attack paths plenty of time to find them!
  1. It took some 6 months from the time these vulnerabilities were brought to the attention of Intel management until the time they were publicly disclosed. During this time, the company — working with its supply chain partners — scrambled to get out ahead of the crisis and develop patches. At no point in this process was government brought into the loop; at least not deliberately.

    timeline-of-spectre-meltdown-1Some of those supply chain partners were Chinese firms. It must be noted that in China, practically every company of any significant scale has to work closely with the government (at some point if not continuously). In China, the divide between the private and public sectors is much more tenuous.

    Accordingly, the manner and timeline according to which the Spectre and Meltdown discoveries and disclosures unfolded was troubling enough to raise concerns among US Senators that the Chinese government may have been aware of vulnerabilities affecting nearly all global computers — including government computers — six months before any western governments had a clue.

    Consider the current geopolitical climate and let that concern sink in for a moment. It's a frightening notion to say the least.
  1. The old phrase “the cure is worse than the disease” comes to mind. Now, given the two points made above, this may well not be the case. Still, it’s worth noting just how bad the “cure” is for Spectre and Meltdown. Even in a best case scenario — where no other damage was done — computing performance will be adversely affected by the patches. Under some high intensity conditions, reduced performance has been measured at 30%. For more standard use, most analyses put the impairment rate between 1% and 11%.

    That lost performance can quickly compound to produce and abundance of wasted CPU cycles, time, and energy — i.e. money. Of course some businesses that take cybersecurity seriously will look to get to the root of the problem and replace or upgrade their hardware deployments earlier than originally expected. Even if the same total outlay can be assumed, there’s a great deal of loss still incurred by virtue of the time value of money.

    Factoring these impact points across the entirety of the affected global economy, even a conservative estimate would put the aggregate costs of just the “cure” to Spectre and Meltdown in the billions of dollars!

Mitigation

Several patches by multiple vendors were released since these attack paths were publicized. Intel provided firmware updates to nearly all of the CPUs manufactured by the company over the last five years. The first versions of these patches were released on January, followed by improvements and corrections in February and March.

There have also been patches to protect against Meltdown vulnerabilities issued for Linux, Windows, and OS/X. Indeed, Microsoft released several different patches, many of which saw multiple versions, the last of which was issued in May 2018.

These patches attempt to block the path to exploitation from the underlying vulnerabilities. As you might expect though, the effectiveness of those patches is limited. Since the vulnerability is embedded within the hardware itself, it can only ever be truly remediated with changes to the firmware.

If that weren’t enough, all these patches lead to some degradation of system performance, as they disable or alter the operation of vulnerable in-chip mechanisms designed to speed up computation.

Cat, Meet Mouse

Several new variants of Spectre and Meltdown vulnerabilities were discovered, the most recent such disclosure, published on November 2018 notes seven additional attack routes — some of those are already covered by existing patches while others require further research and redress.

A new attack technique dubbed NetSpectre allows remote arbitrary memory to be read over the network — altogether obviating the need for local code execution. Put otherwise, if you can access a device via API or some network interface and the code handling these contain some pattern vulnerable to NetSpectre, data can be leaked remotely!

This attack was demonstrated to read a few bits per hour without any content from the device side. While this manner of exploit remains somehow impractical at the moment, it heralds the beginning of other more effective variants to come.

Spectre, Meltdown, and IoMT

Medical devices are far from immune to Spectre and Meltdown. Indeed, with long device lifespans commonplace (10 to 20 years) and infrequent patching (due to long and arduous validation processes), medical assets stand distinctly exposed. CyberMDX has found that, on average, around 8% of medical devices allow for remote and potentially unauthorized code execution.

spectre-meltdown-iomt-vulnerability-1

Whether it is a default password weakness or an unpatched n-day remote code execution, one in every twelve devices is open to malicious code. Combining this fact with Spectre and Meltdown means that once an attacker runs his or her code on a device, he or she can read its memory — including PHI and passwords — and gain full control of the system.

This threat would be frightening in any environment, but in a healthcare environment it’s downright dangerous. A cybercriminal can easily manipulate the proper functioning of a device and cause physical — potentially fatal — harm to a patient.

Over the past year, more than a dozen IoMT device manufacturers have owned up to possible knock-on vulnerabilities inherent to their products courtesy of Spectre and Meltdown — describing this in special security advisories, for example here, here, and here. Yet, in many cases no further announcements were made and devices were left without any patches available — neither for the software nor the firmware.

There are a lot of things that might be contributing to the lack of manufacturer follow through. Maybe it’s the slow-moving validation process for complex patches in healthcare. Maybe it’s the need to constantly change patches in development to match the newly released component patches that they build on. Maybe the security gaps exposed by Spectre and Meltdown are simply not so easily closed in healthcare environments. Maybe the process is being held up due to concerns over the potentially consequential system degradation that would result.

Explanations for the erstwhile inaction are not hard to conjure, but they also don’t help. In the meantime, medical centers are left unacceptably vulnerable. Concerns have even been raised by lawmakers, suggesting a reconsideration of the timely notice required for the development and testing of security patches to these types of game-changing vulnerabilities.

How to Proceed from Here

Proof of concept exploits of Meltdown have been published, and as mentioned by Nicole Perlroth, a senior cybersecurity reporter at the New-York Times, “Meltdown can be exploited by any script kiddie with attack code”.

Spectre and Meltdown are high-profile, multi-dimensional vulnerabilities with a huge potential impact radius. With so many clinical assets and Internet of Medical Things installations running on unpatched software and already susceptible to other n-day vulnerabilities, Spectre and Meltdown represent a truly unacceptable risk.

It seems the main recourse for HDOs is to lean heavily on best-in-class context-aware network access policy management and enforcement solutions. Properly (and integratively) deployed, these tools serve to reduce the attack surface and reimpose isolation across the various layers — from infrastructure to endpoint to service to app, and everywhere in between — of your network. With such controls in place, the vulnerabilities are still there, but the possibility to exploit it is dramatically limited.

Of course, even just defining your context-aware policies is no small task. A small HDO would typically have more than 100 different families of devices, spanning multiple vendors, and using different operating systems and protocols. Still, this must be your first step — and there are tools to help you with it. If you’re still waiting for the device manufacturer to come to your rescue, you’re in for a rude awakening. A year on from the official arrival of Spectre and Meltdown, with patient data and safety on the line, waiting is a luxury you can no longer afford.


Take a more proactive approach to securing your connected devices. Accelerate  and improve your micro-segmentation combining simultaneously panoramic &  granular visibility, deep industry expertise, and smart security policy  planning.
spectre-meltdown-security-automation

Comments