IncMan Use Case: Meltdown and Spectre Vulnerabilities

This use case demonstrates how to use IncMan’s integrations and R3 Rapid Response Runbooks to quickly respond to hosts exposed to the Meltdown and Spectre vulnerabilities, reducing the risks posed by these potentially critical issues.

Goal:

Automatically receive alerts for host which have been identified as being vulnerable to Meltdown or Spectre, create an Incident and perform automated Notification, Enrichment and Containment tasks to reduce the risk these vulnerabilities present to the organization.

Integrations Used:

Implementation

Creating an R3 Rapid Response Runbook

The first step in reducing the risk from the Meltdown and Spectre vulnerabilities is to create a runbook to handle alerts for newly detected vulnerable hosts.  In this use case, we will use integrations with Jira, McAfee ePO, McAfee Web Gateway, MSSQL Server and QRadar to perform Notification, Enrichment and Containment actions; however, this can easily be adapted to include any other technology integrations as well.

meltdown-1

 

Using a Jira Notification action, a new Jira issue is created.  This Notification action should notify the IT or Infrastructure teams and initiate the organizations normal vulnerability management process.

Next, an MSSQL Server Enrichment action is used to query an IT asset inventory for the host name of the vulnerable host, which is passed to the runbook automatically when the incident is created.  This asset information is then available to the analyst for further review.

Once the IT asset information is retrieved, a decision point is reached.  If the IT asset information indicates that the host is a server, one path (the top path) is taken.  If the IT asset information indicates that the host is not a server, another path (the bottom path) is taken.  

If the asset is determined to be a server the Jira Enrichment action is used to update the Jira issue, informing the appropriate parties that the host has been determined to be a server and should be treated as a higher priority.  Next, two McAfee ePO Enrichment actions are performed. The first Enrichment action queries McAfee ePO for the system information of the given hostname, providing the analyst with additional information. The second Enrichment action uses McAfee ePO to tag the host with the appropriate tag. Finally, a Task is added to IncMan reminding the analyst to follow up with the appropriate teams to ensure that the vulnerability has been appropriately mitigated.

If the asset is determined not to be a server, the two previously mentioned McAfee ePO Enrichment actions are immediately be run (System Info and TAG). Following these two Enrichment actions, a McAfee Web Gateway Containment action is used to block the host from communicating outside of the network. This Containment step is completely optional but is performed here on non-servers only to minimize the Containment action’s potential impact on critical systems.

Utilizing the R3 Rapid Response Runbook

Once the new runbook is created, IncMan must be told how and when to automate the use of this runbook. This is achieved by creating an Incident Template, which will be used any time an incident is generated for a Meltdown or Spectre vulnerability. Through this incident template, critical pieces of information such as Type, Summary, Category can be automatically applied to the newly created incident.

meltdown-2

 

From the Runbook tab of the Incident Template wizard, the previously created Meltdown and Spectre runbook is selected and set to autorun. Each time this template is used to generate an incident, the appropriate information such as hostname and host IP address will be used as inputs to the runbook and the runbook will be automatically executed.

meltdown-3

 

In this use case, alerts from QRadar are utilized to initiate automatic incident creation within IncMan.  However, another SIEM integration, syslog or email could also be utilized to achieve the same outcome. A new QRadar Incoming Event Automation rule is added and the defined action is to generate a new incident from the previously created Meltdown and Spectre Incident Template.

 

meltdown-4

Solution in Action

When a QRadar Alert is generated matching the criteria defined for a Meltdown or Spectre vulnerability detection, IncMan will automatically generate a new incident based on the Meltdown and Spectre Incident Template.

meltdown-5

Without requiring any action on the part of an analyst, the Meltdown and Spectre runbook is automatically initiated, performing the defined Notification, Enrichment and Containment actions (in the example shown here, the ‘server’ path is taken).

meltdown-6

 

This entire process has taken place in a matter of minutes, likely before anyone has even had time to acknowledge the alert.  As an analyst begins to manually examine the alert, many of the mundane tasks have already been completed, allowing the analyst to focus on the tasks which require human intervention and reducing the time required to remediate this issue, ultimately reducing risk to the organization.

How DFLabs IncMan Tackles Meltdown and Spectre Vulnerabilities

Following on from my recent blog post entitled “Meltdown and Spectre – What They Mean to the Enterprise” published in January, I wanted to take a closer look at how these types of hardware vulnerabilities could (and should) easily be detected, managed and mitigated using Security Orchestration, Automation and Response (SOAR) technology, for example with a platform such as IncMan from DFLabs.

Using Meltdown and Spectre as a use case, I wanted to enlighten you about the automated processes an organization can undertake.  There are many pros and cons for using automation, but if used in the correct way it can significantly improve Security Operations Center (SOC) efficiencies, saving security analyst many man hours of mundane tasks.  Alerts can also potentially be responded to and contained before an analyst has even been notified.  Using IncMan’s integrations and R3 Rapid Response Runbooks, SOCs can quickly respond to such an alert when a vulnerability is detected.  The overall goals would be as follows, in order to reduce the risk these vulnerabilities present to the organization.

1)  Automatically receive alerts for the host which have been identified as being vulnerable to Meltdown or Spectre.

2) Create an Incident and perform automated Notification, Enrichment and Containment tasks.

Implementation

Let’s move on to the implementation stages.  Where should you start? For ease I will break it down into 3 simple sections, creating a runbook, utilizing the rebook and seeing the runbook in action.  So, let’s begin…

Creating an R3 Rapid Response Runbook

The first step in reducing the risk from the Meltdown and Spectre vulnerabilities is to create a runbook to handle alerts for newly detected vulnerable hosts.  In this use case, we will use integrations with Jira, McAfee ePO, McAfee Web Gateway, MSSQL Server and QRadar to perform Notification, Enrichment and Containment actions; however, this can easily be adapted to include any other technology integrations as well.

 

Meltdown and Spectre Vulnerabilities

 

Using a Jira Notification action, a new Jira issue is created.  This Notification action should notify the IT or Infrastructure teams and initiate the organizations’ normal vulnerability management process.

Next, an MSSQL Server Enrichment action is used to query an IT asset inventory for the host name of the vulnerable host, which is passed to the runbook automatically when the incident is created.  This asset information is then available to the analyst for further review.

Once the IT asset information is retrieved, a decision point is reached.  If the IT asset information indicates that the host is a server, one path (the top path) is taken.  If the IT asset information indicates that the host is not a server, another path (the bottom path) is taken.

If the asset is determined to be a server the Jira Enrichment action is used to update the Jira issue, informing the appropriate parties that the host has been determined to be a server and should be treated as a higher priority.  Next, two McAfee ePO Enrichment actions are performed.  The first Enrichment action queries McAfee ePO for the system information of the given host name, providing the analyst with additional information.  The second Enrichment action uses McAfee ePO to tag the host with the appropriate tag.  Finally, a Task is added to IncMan reminding the analyst to follow up with the appropriate teams to ensure that the vulnerability has been appropriately mitigated.

If the asset is determined not to be a server, the two previously mentioned McAfee ePO Enrichment actions are immediately be run (System Info and TAG).  Following these two Enrichment actions, a McAfee Web Gateway Containment action is used to block the host from communicating outside of the network.  This Containment step is completely optional but is performed here on non-servers only to minimize the Containment action’s potential impact on critical systems.

Utilizing the R3 Rapid Response Runbook

Once the new runbook is created, IncMan must be told how and when to automate the use of this runbook.  This is achieved by creating an Incident Template, which will be used any time an incident is generated for a Meltdown or Spectre vulnerability.  Through this incident template, critical pieces of information such as Type, Summary, Category can be automatically applied to the newly created incident.

 

Meltdown and Spectre Vulnerabilities 1

 

From the Runbook tab of the Incident Template wizard, the previously created Meltdown and Spectre runbook is selected and set to autorun.  Each time this template is used to generate an incident, the appropriate information such as host name and host IP address will be used as inputs to the runbook and the runbook will be automatically executed.

 

Meltdown and Spectre Vulnerabilities 2

 

In this use case, alerts from QRadar are utilized to initiate automatic incident creation within IncMan.  However, another SIEM integration, syslog or email could also be utilized to achieve the same outcome.  A new QRadar Incoming Event Automation rule is added and the defined action is to generate a new incident from the previously created Meltdown and Spectre Incident Template.

 

Meltdown and Spectre Vulnerabilities

 

Solution in Action

When a QRadar Alert is generated matching the criteria defined for a Meltdown or Spectre vulnerability detection, IncMan will automatically generate a new incident based on the Meltdown and Spectre Incident Template.

 

Meltdown and Spectre Vulnerabilities

 

Without requiring any action on the part of an analyst, the Meltdown and Spectre runbook is automatically initiated, performing the defined Notification, Enrichment and Containment actions.(In the example shown here, the ‘server’ path is taken).

 

Meltdown and Spectre Vulnerabilities 5

 

Conclusion

How easy was that?  The entire process has taken place in a matter of minutes, likely before anyone has even had time to acknowledge the alert.  As an analyst begins to manually examine the alert, many of the mundane tasks have already been completed, allowing the analyst to focus on the tasks which require human intervention and reducing the time required to remediate this issue, ultimately reducing risk to the organization.

IncMan has over 100 customizable playbooks for similar use cases like this.  If you would like to see IncMan in action, please do feel free to request a demo.

Meltdown and Spectre – What They Mean to the Enterprise

Since Meltdown and Spectre were publicly disclosed earlier this month, there has been much confusion surrounding exactly how these attacks work, and what impact they may have on the enterprise. Though these vulnerabilities could pose a serious risk to the enterprise, I think we can probably hold short of a full-fledged panic, at least for now. Let’s take a look at what these two attacks really are, what solutions are available, and what they may ultimately mean for the enterprise.

Meltdown and Spectre exploit critical flaws in modern processors. Unlike most vulnerabilities, the vulnerabilities used by Meltdown and Spectre do not exist in software, but in the processors themselves. This is significant for many reasons. First, while it is possible to patch “around” these vulnerabilities, it is much more difficult to patch the vulnerabilities themselves. Second, although endpoint protection solutions may be able to detect methods used to deliver a payload which exploits the Meltdown or Spectre vulnerabilities, the execution of the exploits themselves are very hard to distinguish from normal processes and thus very difficult to detect heuristically. Finally, since these exploits are performed at the hardware level, the forensic artifacts often relied upon to investigate malware incidents are absent in these attacks.

While programs are typically not permitted to read data from memory sections outside their own address space, a malicious program can exploit Meltdown or Spectre to access regions of memory that the process should not otherwise have access to. This could include access to user credentials or hashes, private keys, sandbox escape, VM escape and access to other confidential information stored in memory.

So far, there are three specific vulnerabilities which are used in Meltdown or Spectre attacks:

• Variant 1: Bounds check bypass (CVE-2017-5753)
• Variant 2: Branch target injection (CVE-2017-5715)
• Variant 3: Rogue data cache load (CVE-2017-5754)

Spectre (Variants 1 and 2) has been shown to impact all modern chips manufactured by Intel, AMD and ARM. Meltdown (Variant 3) has been shown to impact most Intel chips since 2010, although researchers noted that with additional research and code optimization, exploitation against AMD and ARM chips may be possible.

Meltdown

A processor operates in two modes: kernel mode and user mode. Kernel mode is where the operating system executes, and processes running in kernel mode have access to hardware and all regions of memory. User mode is where most user processes execute. Each user mode process has a restricted view of memory, allowing access only to the process’s own virtual address space, and must use system calls to access hardware. Under normal conditions, if a user mode process attempts to directly access a memory section outside its own virtual address space, an exception will be generated which will cause the process’s thread to terminate.

While kernel memory cannot be read directly from user space without utilizing a system call, most modern operating systems still map kernel addresses into userspace processes to optimize performance. Although this sounds like a vulnerability on its own, a userspace process attempting to access kernel space outside of a normal system call will generate an exception and cause the process’s thread to terminate. This means that although kernel space is mapped into the user process address space, it is effectively inaccessible to the user space process outside of normal system calls.

Meltdown exploits the fact that kernel space memory is mapped into the user space process’s address space and the fact that, to optimize performance, most modern processors execute instructions out of order, to bypass the normal protection mechanisms and allow unprivileged user space processes to access kernel space memory. By executing specially crafted out of order instructions, kernel space memory address can be written to the process’s address space, which can then be retrieved via an address reference in the processor’s cache. Although this unprivileged memory access ultimately causes an exception which causes the rest of the out of order instructions to be discarded, the retrieved memory sections continue to reside in the user process’s unmapped memory space, and the reference still remains in the processors’ cache.

Although Address Space Layout Randomization (ASLR) means that an attacker will not know the location of kernel space memory beforehand, this presents more of a stumbling block than a barrier for this attack. The researchers who discovered Meltdown found that the location of kernel memory can be determined in about 128 guesses on a system containing 8GBs of memory, making ALSR trivial in preventing this attack.

Spectre

Spectre exploits another set of processor features, branch prediction, and speculative execution, to access protected memory locations. Most processes contain a vast array of branch conditions, such as If/Then/Else statements. To optimize performance, as a process executes, the processor keeps track of which branches are executed most often. This allows the processor to “think ahead”, read memory sections and snapshot pre-execution of the branch which it believes is most likely to be taken. This is referred to as speculative execution.

Spectre causes the processor to access a memory location of the attacker’s choosing within the user process’s space during branch prediction and speculative execution which would not be accessed during normal process execution. Although these memory locations are never actually executed by the processor, they now exist in the processor’s cache and can then be read by the attacker.

Patches and Workarounds

There are patches currently available for the Linux kernel to prevent the Meltdown attack. Known as KAISER or Kernel Page Table Isolation (KPTI), these patches prevent most kernel memory from being mapped into userspace processes (although some kernel memory, such as the IDT, must still be mapped to user mode address space). Microsoft has also developed a similar patch for Windows to address Meltdown; however, due to compatibility issues (BSODs) with some endpoint protection solutions, Microsoft has cautioned users to check with their endpoint protection provider prior to deploying the patch. An unofficial list of support for the Windows patch by common endpoint protection solutions is available here. It is important to note that these patches do not fix the actual vulnerability itself, they simply limit the practical exploitation of the vulnerability. Some users have also been reporting issues with the Microsoft patch, causing systems with older AMD processors to fail to boot correctly.
For users still running legacy systems, such as Windows XP and Windows Server 2003, these systems will continue to remain vulnerable to Meltdown and Spectre along with the many other vulnerabilities still present on these systems. The best protection is to harden around these systems, or even better, replace them.

Patches to address these vulnerabilities do come with some performance implications, however. Estimates range from a 5% to a 30% decrease in performance depending on system usage. Systems utilized for more common tasks, such as email, Internet browsing, and word processing, are less likely to see a major performance impact from these patches. However, systems used for tasks which require more intensive hardware utilization are more likely to suffer a noticeable impact.

While KPTI and similar patches are also effective against Spectre Variant 2, protection from Spectre Variant 1 is largely dependent on patches from individual software vendors. Software such as web browsers, or sandboxes and virtualization technologies are likely the most attractive target for Spectre attacks since it would allow attackers to access information from other browser tabs or escape the sandbox or VM. The major web browsers either already have patches available, or are planning to deploy patches in the upcoming weeks. Users should ensure that they are running the most up-to-date versions of their web browsers. Sandbox and virtualization users, such as those using JavaScript, Xen or Docker, should check with their respective vendors to see when patches will be available and ensure that they are running the most current versions of the software.

Apple, which bases its iOS A-series processors on ARM’s instruction set, has already deployed patches for some devices and plans to release patches for other devices soon. Apple has advised users are to check for new updates for their devices and check to ensure that they are running the most current operating system for their devices.

Google says that Android devices, which also most commonly run on ARM processors, should be protected if they have the latest security update installed. Currently, Android devices are protected by restricting access to the high precision timers needed to determine if a cache hit or miss has occurred; however future Android security updates will also include additional mitigations based on KPTI. Users of Google Android devices, such as the Nexus and Pixel, should have immediate access to the security updates. Users of other Android devices will likely have to wait a little longer for these patches as they are tested and pushed through each manufacturer’s update process.

Chromebook users running the latest version of Chrome OS (version 63 as of now) should already be protected against these vulnerabilities as well. To check if a Chromebook is updated to version 63, or if an update is available, users should check Google’s list of Chrome OS devices.

Qualcomm processors are affected by these vulnerabilities as well, although patches have not yet been released for all systems running on Qualcomm processors. Users are advised to check for operating system updates, particularly when running Android and Linux, on their Qualcomm-powered devices. IBM firmware updates should be available in the upcoming weeks for their Power CPUs to address Spectre-like issues in its design.

Cisco is also preparing to release patches to prevent exploitation of these vulnerabilities. Since most Cisco products are closed systems, which do not allow customers to run custom code on the device, practical exploitation of these vulnerabilities on Cisco devices is limited. However, certain processor and OS combinations in some Cisco products could leave them vulnerable, and it is recommended that users patch their Cisco devices as soon as a patch is available.

What does this mean for me?

While Meltdown and Spectre do pose some serious potential security risks, at the moment there is no need to panic. Users are still far more likely to be exploited via a phishing email than either of these vulnerabilities. So far, there has been no evidence that either of these attacks has been used in the wild, although it is certainly possible that others have known about these vulnerabilities for some time. It will likely take some additional time and effort to advance these attacks from a proof of concept to a reliable attack vector.

There has been enough attention given to these vulnerabilities that most major operating systems and applications already have patches available or will have patches available soon. Patching will be the best defense against these attacks. With proper patching, the risks from these vulnerabilities will be significantly reduced or eliminated. Users of less common or no longer maintained software which may be vulnerable to Spectre Variant 1 should check with their software vendors or deploy additional protections around these systems. Legacy and embedded devices, with limited or no ability to patch, will likely see the greatest long-term risk associated with these attacks.

The greatest potential impact from Meltdown could have been on cloud service providers, as they could have allowed both access to the hypervisor as well as data from other instances. However, most of the major cloud service providers were notified of the vulnerability prior to public disclosure and should have patches already deployed, or being deployed soon. Cloud service users should check with their individual providers to determine their potential existing exposure from these vulnerabilities.

The most significant lasting impact from Meltdown and Spectre may be these types of hardware vulnerabilities exist in the first place. Although these vulnerabilities have been present in hardware for many years, little attention has been paid to this class of vulnerabilities. Hardware vulnerabilities such as these present a very attractive vector for attackers due to the high level of access they provide and the potential for VM escape; even more so when they can be exploited remotely. We have seen this type of vulnerability “gold rush” in the past, where the discovery of a single vulnerability leads to increase in scrutiny of a certain application or system, disclosing dozens of additional vulnerabilities. Given the challenges in detecting, investigating and patching these types of hardware vulnerabilities, a gold rush here could have serious security implications.