Will Deane

Director at ASX Consulting Ltd

Side-channel attacks abuse information leaked by the processing system, rather than directly attacking the system itself. Attackable side channels include analysis of power, electromagnetic emissions, acoustics, heat, and timing. Historically, side-channel attacks were predominantly focused on cryptographic systems. With the adoption of hypervisors and cloud computing, recent research has focused on cross–virtual machine side channels, mostly using CPU cache timing techniques. Even though side-channel attacks are typically slow and often provide only partial data recovery, sophisticated attacks have been demonstrated in public clouds, including stealing encryption keys and creating covert channels between cooperating non-networked systems.

In 2009, researchers from the University of California and the Massachusetts Institute of Technology published a paper demonstrating techniques for coresiding an attacker’s virtual machine on the same physical host as a victim in Amazon EC2.¹ They also demonstrated some basic side-channel attacks, including low-bandwidth covert channels between cooperating coresident hosts using both hard disk and memory bus contention timing. By 2017, researchers from Graz University of Technology in Austria had developed a practical covert channel providing 45 KBps of bandwidth using CPU cache timing.² They implemented a Transmission Control Protocol (TCP) stack on top of this channel and demonstrated streaming a music video across the channel at Black Hat Asia 2017.

So, what do those attacks mean for the use of public cloud infrastructure? For covert channels, an attacker has to get their code running on the victim virtual machine and also get their VM coresident on the same physical host. Lots of methods can be used to get malware onto a running system, but for typical cloud workloads, common techniques include the following:

• Using stolen credentials

• Phishing developers or DevOps

• Attacking supply chains

• Compromising CI/CD pipelines

The coresidence requirements can be met by brute-forcing virtual machine creation and testing for coresidence with the victim; this is made easier if the attacker’s code is already running on the victim VM.

These requirements suggest that cloud users processing sensitive data on virtual machines without direct internet connectivity who are subjected to threats from well-funded, sophisticated threat actors are most at risk from these attacks.

For traditional side-channel attacks, cryptographic keys are most at risk; for example, keys associated with Transport Layer Security (TLS) services. These attacks don’t need software running on the victim machine; however, this makes confirming coresidency more difficult. These attacks are also prone to noise-based errors, and at the time of writing, I’m not aware of any practical demonstrations of real-world key recovery from realistic public cloud workloads.

It’s said the NSA has a saying: “Attacks always get better; they never get worse.” Research into side-channel attacks seems to follow this axiom. In January 2018 details of the Spectre and Meltdown vulnerabilities affecting CPUs were published, with further related vulnerabilities published throughout 2018, including Spectre-NG, ret2spec, SpectreRSB, and NetSpectre, to name a few. This trend continued in 2019 with related attacks published including Fallout, RIDL, ZombieLoad, and Spectre SWAPGS.

Although many of these issues can be remediated with software patches, some (such as cache timing attacks) abuse underlying hardware operations and require hardware architecture changes to mitigate—something that isn’t going to happen in the short to medium term.

If you are running sensitive workloads at risk of side-channel attacks in public clouds, all of the major IaaS suppliers provide options to use hardware dedicated to you, removing the option for an attacker to become coresident with your virtual machines. AWS offers Dedicated Instances, Azure has Isolated Instances and recently announced Dedicated Hosts, and Google Cloud has sole-tenant nodes. These options all cost a little more than their standard shared tenancy offerings, typically in the range of 6% to 10% for pay-as-you-go pricing.

Organizations should consider the risks of side-channel and covert communication attacks to their public cloud–hosted systems and decide whether to accept the risks or pay the additional cost for sole-tenancy hardware.