On Wednesday January 3, 2018 a series of vulnerabilities were disclosed which impacted nearly every Intel, AMD, and ARM-based processor of the previous 20 years. Awareness of these vulnerabilities, Spectre and Meltdown, have been quickly spread by both the technical and popular media. Many of the media reports have been overblown and based on conjecture rather than fact. We’re not going to add to that noise and hyperbole here. Rather, let’s focus on some bottom-line facts and what organizations can do to mitigate the impact and risk imposed by these two vulnerabilities.
SANS conducted an excellent webcast to cover the technical details of the vulnerabilities and specifically how they may be exploited. We’ve posted that to our YouTube channel. We’re not going to cover these technical specifics apart from a few key facts below:
Every Intel, AMD, and ARM Microprocessor is Impacted
The vulnerabilities are not just in hardware but exist in how Operating Systems store and access kernel memory
Exploitation of these vulnerabilities permit rogue processes to access sensitive information from other processes running on the same physical computer. This includes both innocuous information – like what color font you’re using in a word processor – to very sensitive data like passwords or the decrypted contents of otherwise encrypted communications – like that from a banking website.
As of the time of publication no in-the-wild exploitation of these vulnerabilities are known
All major operating system vendors have released patches for currently supported software products.
Widespread significant adverse impacts from these patches have been reported.
Understanding the impact and taking action:
What is Impacted?
Meltdown and Spectre are different vulnerabilities that security researchers have discovered that circumvent the protection – or separation – of information stored by computer processes as they are being executed by the computer’s CPU. Ordinarily, this information is protected and kept separate so things like Passwords aren’t in the same memory space as an Internet browser as an example. These vulnerabilities circumvent those protections, exposing nearly any data the computer processes, such as passwords, proprietary information, or encrypted communications to a rogue process.
Meltdown affects Intel processors, and works by breaking through the barrier that prevents applications from accessing arbitrary locations in the Operating System’s most fundamental area of memory, its Kernel. Segregating and protecting memory spaces prevents applications from accidentally interfering with one another’s data, or malicious software from being able to see and modify it at will. Meltdown makes these separations fundamentally unreliable.
Spectre affects Intel, AMD, and ARM processors, broadening its reach to include mobile phones, embedded devices, and pretty much anything with a chip in it. Which, of course, is everything from baby monitors, to laptops, to servers today.
Spectre is different than Meltdown. Spectre essentially tricks applications into accidentally providing information to a rogue process that would normally be inaccessible from within a protected area of a computer’s memory. The technique is different but the result is the same.
What’s impacted? Just about everything made with an Intel, ARM, and/or AMD-based CPU in the last 20 years. So, pretty much everything.
Mitigating the threats
In the 24 hours following the release of these vulnerabilities, nearly every software vendor that was loosely related to Information Security began marketing how their specific tool would save their customers from the certain doom caused by Spectre and Meltdown. As of the time of publication, 5 days after the initial disclosure of these vulnerabilities, there continue to be no in-the-wild exploits of this vulnerability. Please don’t misunderstand, there absolutely will be. This is a very real thread and every organization needs to take this seriously.
Microsoft, Apple, and Redhat all have released operating system patches to mitigate these vulnerabilities. These patches however fundamentally change several very foundational ways in which the Operating System accesses and stores memory in its kernel. Changing this has resulted in many organizations, including major cloud service providers, reporting serious instability and a major slowdown for some applications. Other application vendors have reported wholesale incompatibility with the changes introduced by the Operating System patches. This is truly a situation in which thoroughly testing these patches in a development or test environment is critical. Apart from “just patch it”, we’ve been asked what “else can organizations do to protect themselves from this risk?”
First, begin testing the key applications and operating systems within your environment using the new patches. They will most likely have to be applied eventually unless you’re able to seriously isolate vulnerable systems. As your applications and systems clear testing, we advise applying the patches out-of-cycle to production systems. Simply, get production systems patched using in risk-based impact-weighted manner as quickly as possible.
With that out of the way, here are steps that you can take to better protect yourself from Meltdown and Spectre:
Data Accessibility Footprint: Evaluate (and possibly reconsider) the security and protection requirements of data which is stored/accessed/retrieved on the same physical servers.
- Are there differing data security requirements between virtual machines running on the same hardware?
- Will the compromise of a virtual machine seriously impact the security posture of the organization because of information processed on an adjacent virtual machine?
Detection Capabilities: While neither Meltdown or Spectre are themselves an means to gain access or exfiltrate data from a target. Meltdown will permit process escalation and then an attacker could begin making lateral movements using other tools. Simply, it gives them a foothold from which to establish backdoors and further access to internal systems. In 2018 it is imperative that we focus on reducing not only the ability for attackers to gain a foothold but moreso on detecting them once they are there.
- Do your key systems have the ability to detect abnormal processes or abnormal process behavior?
- Are there logs which are maintained centrally that would permit the reverse-engineering of the path an attacker used to gain access into your environment?
- Do your systems have the ability to detect file modification of critical system files?
Evaluate security of hosted (cloud-delivered) applications: While attackers race to develop exploits and update toolkits to leverage these vulnerabilities, we should all evaluate and question our cloud security posture. It is most likely that serious attackers will go after cloud-delivered apps first. Afterall, compromise to a single shared virtual machine could provide an attacker access to every other virtual machine on the same physical host. It’s logical that cloud providers would be targeted purely based on the sheer number of virtual machines operating in their environment. Asking for an official public certification that their environment is fully patched for these vulnerabilities is the first step. Understanding that it is common for Cloud Providers to be the weakest link in an organizations security posture, this step becomes critical.
- Do you know where all of your data exists and is accessible from? What systems which are outside of your immediate control comprise your data footprint?
- What are the proactive and reactive security policies of your cloud providers?
- What steps are your cloud providers taking to evaluate active exploitation attempts against their platforms?
Change Management: This vulnerability disclosure was just another example of “A big one”. We saw five such events in 2017 and numerous others in years prior. The point, this is not the first and will certainly not be the last widescale vulnerability to be announced. In the days following the public disclosure widespread reports of serious instability, outages, and disruption of public and private computing infrastructure were common. Microsoft (Azure), Google, and AWS all reported such issues. Numerous companies reported difficulties caused by IT systems being offline or impacted. All of these outages were preventable if change management practices were followed.
- We promote ‘Think before you click’ to end-users under the auspices of being security aware. As system architects / engineers / administrators, we should take the same guidance. Yes, these vulnerabilities are serious. Yes, systems must be patched. But applying patches to systems, even for critical out-of-band patches, should follow a measured and risk-based approach. With no in-the-wild exploits, the immediate risks introduced by these vulnerabilities were merely a possibility. Whereas the risk of an adverse impact shifts from a possibility to a near-certainty if patches are applied blindly to production systems.
- Does your update/change management/patch policy permit for critical patches?
- Does your policy make the consideration for critical systems testing in a time-compressed manner on dev/test systems?
Hardware Lifecycle: It is inevitable that one or more hardware vendors will ultimately use these vulnerabilities as a reason to replace hardware. After all, everything from firewalls to servers to toasters are vulnerable. While this is ideal, unless your organization has some significant security reasons or an excess of cash it is most likely not going to be a significant factor for consideration. What should be considered though is what your organization’s hardware refresh and lifecycle dictates. Many organizations subscribe to the “run it until it dies” theory. The Meltdown vulnerability underscores the invalidity of this policy in 2018.
- Does your hardware lifecycle policy factor security-related vulnerabilities into replacement timeframes?
- Does your policy consider trusted, traceable, and security-legitimized sources for hardware? It should!
The Spectre and Meltdown vulnerabilities are serious. They affect everything from phones to servers to security devices – nearly every Intel, AMD, and ARM CPU manufactured in the last 20 years. Organizations need to take patching of every operating system operating within their environment against these vulnerabilities very seriously. Those updates should however undergo significant testing and validation for not just the underlying operating system but also all applications running on them. Beyond simply patching against these vulnerabilities, IT decision makers should consider their organization’s ability to detect attackers using these and similar exploits, have the capability to reproduce and analyze system logs to determine how (and when) an attacker was able to gain a foothold, and understand all of the many places that their organization’s sensitive data exists – both internally within the organization and externally through cloud solution providers. This is not the first and will most certainly not be the last major vulnerability. Being prepared at a holistic level to quantify the impact of such a vulnerability in terms of both the risk to organization data and the required changes should be an organization imperative in 2018.
Corporate Information Technologies provides small to mid-market organizations with expert I.T. services including compliance assessment, cybersecurity penetration tests, and comprehensive business continuity planning services. Corporate Information Technologies can help organizations, quantify, create, refine, and mitigate the risks presented by business threatening disasters in whatever form they may be disguised.
Contact us to learn more and let us show you how good I.T. can be!