It looks like 2018 has the potential to surpass 2017 in security challenges if this latest threat vector has anything to do with it. AttackIQ Labs has developed an automated system test scenario that validates if your infrastructure is susceptible to these new attacks.
By now, surely you are already aware that these new logos should be part of your threat model:
Oh, did I say logos? I meant attacks! Well, nowadays everyone knows that if an attack does not have a logo it’s not worth the media’s attention, right? Anyway, going back to what really matters…
There are two logos because there are two different attacks. However, both attacks allow an attacker to read memory contents which they should not be able to.
As it is very well summarized in the official website, the meltdown attack (the shield logo) breaks user and system memory isolation allowing for a user process (ring 3) to access kernel memory (ring 0).
The spectre attack can force a bug-free application (if that even exists…) to leak arbitrary memory contents from its address space. The outcome of this attack is similar to what happened with our old friend heartbleed, with the important difference that the heartbleed attack was exploiting a heap overflow (a bug in the application) while the spectre attack is not leveraging any vulnerability in the application itself but in the processor algorithms.
Should you be worried? Hell, YES!... You will be busy these next few days making sure all the patches are correctly applied on all your assets. For example, Amazon engineers probably haven’t had much sleep the past few nights. I mean it when I say these past few nights. It looks like they’ve been working on fixing these issues for quite some time already:
Luckily we can help you out with new scenarios that will identify what Windows assets have already been patched in your network and if you are vulnerable to the Spectre exploit. Make sure you deploy a FireDrill agent on as many assets as you can.
This is one of those exceptional cases similar to when two different mathematicians find a proof for a hundred-years-old unproven theorem at the same time.
Meltdown was found by three different parties at the same time: Jann Horn from Google’s Project Zero, Werner Haas from Cyberus Technology and Daniel Gruss, Moritz Lipp, Stefan Mangard, Michael Schwarz from Graz University of Technology.
Spectre was found by two different parties: Jann Horn from Google Project Zero and independently by Paul Kocher (in collaboration with Daniel Genkin from University of Pennsylvania and University of Maryland, Mike Hamburg from Rambus, Moritz Lipp from Graz University of Technology and Yuval Yarom from University of Adelaide and Data61).
Both meltdown and spectre were found at the “same“ time.
To what extent each one of them participated in the discovery of the vulnerability, we don’t know. What we do know is that there are some common denominators in those two discoveries right?
What is obvious is that it’s no coincidence that all this was released at the same time. Looks like the researchers have been actively working with vendors in order to carry out a responsible disclosure of the issue, that’s why as of today there are patches for most of the affected assets.
It’s still interesting to see all that people involved in the discovery of such an important and unique threat. Even more when this flaw has been laying around for such a long time. I don’t believe in coincidence.
There were rumors on the internet that something big was about to happen.
The message we quoted before by Jan Schaumann was an early example of what I mean, but there were many other indicators pointing out that something was going on.
The KAISER Linux memory layout re-design post from November 2017 hinted about the necessity of a big shift in how operating system memory architecture worked.
I want to give a special mention to this post from July of 2017 by Anders Fogh titled Negative Result: Reading Kernel Memory from User Mode. It is one of those texts which is thought provoking similar to the Malloc Maleficarum in the sense that even if it does not give the full solution or even if the experimentation does not give positive results, it still advances the state of the art knowledge in the field and gives some exceptional food for thought.
If I had to choose something from that post, I’d stay with:
While I did set out to read kernel mode without privileges and that produced a negative result, I do feel like I opened a Pandora’s box.
I wouldn’t be surprised if anyone from that long list of names read this post in the right moment.
Another interesting thing is the fact that a talk by the team behind this research was submitted to BlackHat 2017 and eventually rejected.
It gives you something to think about. Either on the selection process…
...Or on the type of proposal sent. Your choice.
There’s been much speculation about what was affected by these attacks. Intel, AMD, ARM? Nvidia? Browsers? Linux, Windows, macOS? That’s part of all the expected FUD surrounding such a critical vulnerability.
For you to get a clear idea about what’s the stance of each vendor on the matter you can find a repository with their statements here. What we know is the following:
These vulnerabilities are likely to affect CPUs dating back to 1995.
Intel is surely affected.
Windows and Linux are affected. Patches for their kernels have been released.
Hypervisors such as XEN (other have not released an official statement yet) are affected and they affirm that other system guest VMs memory can be accessed.
Funny enough, Firefox already released a patch in November 2017 for Firefox 57, while Google Chrome has not yet released a patch even though the team who discovered the vulnerabilities belong to Google.
As of today, there are a couple of PoCs for the Spectre attack out there. We haven’t seen any Meltdown PoC publicly released yet.
This vulnerability affects the whole technology stack of a given system. From the processor to the browser passing through the operating system. Therefore everyone is working to clean up their own backyard.
All the mitigations but the ones related to the processors themselves will come in the form of software updates. Either regular user space software updates like in the browsers case or kernel based patches.
To reinforce the theory that there’s been a raising concern related to the discovery and exploitation of hardware based flaws (mostly side channel attacks), the Linux kernel community started implementing the KAISER mitigation to their kernels.
This mitigation will break with the established implementation of software address space layout in which the address space of the kernel is mapped into every running process in the system, making it accessible from the process address space itself but still protected by access privilege checks.
In order to avoid attacks that leverage hardware flaws to access privileged memory, KAISER will implement almost-complete isolation between user-level memory and kernel-level memory by implementing two sets of page tables, one for user and kernel-level address space when the process lives in ring 0 (kernel) and a different set of page tables that will only contain the user-level process address space.
This mitigation was meant to fix side channel attacks that were found to be used in order to bypass a security mitigation called kASLR. Funny enough, KAISER happens to protect against the the Meltdown attack, however it does not protect against Spectre.
As it always happens, this mitigation will introduce some performance penalty. As an average, it is said that a 5% performance penalty is a reasonable number to pick. However, the worst case scenario they found were a 30% when carrying out “a loopback networking test that did a ton of syscalls and context switches”. So there you go! Now you know from where all the news are getting the 30% slow down they are all mentioning (regardless of whether they know from where this number comes or not).
To be clear, software updates (even OS re-architectures such as Linux KAISER) should do the trick for Meltdown
However, for Spectre, things are not clear. What is sure is that Spectre is way harder to fix. It needs to be fixed either by replacing hardware or maybe by firmware updates.
As for Spectre, there's a combination of facts here. All software vendors (such as Google or Firefox) are doing whatever they can to prevent Spectre. It is not certain if their workarounds fix the issue 100%. For example, Google states: "With Site Isolation enabled, the data exposed to speculative side-channel attacks are reduced as Chrome renders content for each open website in a separate process". So they don't say that the attacks are completely mitigated.
In the meantime, we are waiting for a fix of the root cause of this issue which is the processor. And that brings us to the last paragraph.
We know it’s going to be a rough week or even a rough month. We definitely hope it’s not going to be a rough quarter though! To that end we want to ease your analyst’s lives a little bit.
At AttackIQ we have created two scenarios to help you out. The first one identifies if your system is updated with the last patches that prevent these attacks from being successful and another that will execute a Spectre proof of concept in your system and will assess if your system is vulnerable to the attack.
Basically you can choose between a simple check or you can execute the real thing and see how your defenses respond against it. Their names are:
Spectre and Meltdown Patch Check: This scenario validates if specific patches are installed regarding Spectre and Meltdown vulnerabilities rely on Speculative Execution Side-Channel attacks, and tested patches on this scenatio are...
Spectre PoC Exploit: This scenario runs a Proof of Concept exploit for the Spectre vulneratbility...
Whatever option you choose, we recommend you to deploy an agent to all your assets and schedule one of those two scenarios to run each N hours (or once a day) while your devops engineers work on keeping your systems safe by updating them.
Most likely, in the beginning you’ll see all the results of these attacks in red! However, as time goes on you’ll be able to see some assets changing from red to green. This will allow you to measure the time it takes for an OS update to be spread among all the assets in your company. Metrics! It’s all about metrics, right?!