How to Defend Against ZombieLoad

Earlier this week a group of security researchers from Graz University of Technology, imec-DistriNet, KU Leuven, Worcester Polytechnic Institute, and Cyberus Technology identified and analyzed a vulnerability in Intel chips being called ZombieLoad (CVE-2018-12130) that allows sensitive data to be stolen from the processor. You can get all the details on ZombieLoad directly from the researchers here. Thankfully, researchers do not believe this exploit has been used in a real-life attack.

Similar to Spectre, Meltdown, and Foreshadow, ZombieLoad allows attackers to exploit vulnerabilities in the speculative execution process to launch what Intel calls a “Microarchitectural Data Sampling (MDS)” attack. In plain English this means that an attacker can leverage this vulnerability and see data from applications it should not have access to. This time, the scope of the problem is limited to Intel’s implementation of speculative execution — other chip manufacturers are not affected.

While this vulnerability affects all Intel CPUs manufactured since 2011 including PCs and cloud servers, Intel is better prepared as a result of the backlash following Spectre and Meltdown. They have shipped microcode updates, and most of the big tech companies have already rolled out patches.

Of particular note for Threat Stack customers on AWS, the company issued a security advisory stating that “All EC2 host infrastructure has been updated with these new protections, and no customer action is required at the infrastructure level” (AWS security bulletin). Of course, customers will still want to apply kernel updates to the AMIs they’re already using.

It’s good to see the responsible disclosure and rapid patching of this new vulnerability, but it underscores the need to proactively protect yourself against similar vulnerabilities that will undoubtedly continue to be discovered in the future.

ZombieLoad exploits a manufacturer-specific processor implementation flaw, so it can’t be tied to a certain bit of code or attacker technique. One of the most dangerous parts of vulnerabilities like ZombieLoad is the lack of clear IOCs in log files or signatures that can be detected by traditional virus scanners. While many tools would not have been able to detect an attack leveraging this vulnerability, Threat Stack customers would have been alerted to suspicious behavior during several points of the attack: either during the initial breach where actors attempt to escalate privileges, or leading up to actual code execution.

Based on the publicly available POC code posted by the researchers, Threat Stack has confirmed that customers would have been alerted at the following stages of the hypothetical attack:

• User: Privilege Escalations

• Exploit: Service Running as Root

• • These entries from our base ruleset all detect ways attackers could gain the privileges they need to start exploiting ZombieLoad.

• Exploit: Processes Activity from /tmp

• Exploit: Processes Activity from /dev/shm

• Exploit: Service Running Shell

• • These entries from our base ruleset all detect ways that attackers could run code or issue commands to run a ZombieLoad exploit.

It is also possible that customers would have received additional alerts at the following stages depending on their unique environment and further details on the ZombieLoad exploit structure:

• User: Potentially Suspicious Command Usage

• File: Kernel Parameters Configuration File Modified

• Exploit: Kernel Module Activity

• • These base rules and one FIM rule could catch the kernel modification steps needed to run the proof-of-concept code written by the researchers who discovered ZombieLoad. In particular, they would catch the nopti and nokaslr flags passed on the kernel command line (as well as any kernel config file edits), or an actual kernel module insertion attempt via insmod.

To learn more about how Threat Stack leverages behavioral analysis to detect sophisticated attacks in the cloud, read our Cloud Security Threat Briefing: Anatomy of a Sophisticated Cloud Attack.