Fears about cloud security have been greatly exaggerated, but recently, a bona fide new cloud vulnerability emerged: A team of computer scientists has crafted a technique that lets an attacker use an account on Amazon EC2 to steal private cryptographic keys from other AWS users.

Cryptography is at the core of security. The fact that private keys can be lifted from one virtual machine to another shows that cloud providers still have more to do to protect customers.

In a paper published by the International Association for Cryptologic Research, a team from Worchester Polytechnic Institute's department of electrical and computer engineering showed how they used one instance of Amazon EC2 to recover the full 2,048-bit RSA key from a separate Amazon instance.

Why and how to steal a cloud key

Malicious hackers want cryptographic private keys so that they can impersonate the targeted system to other systems. They can also intercept the targeted entity's encrypted communications and extract potentially valuable information.

"We exploit the LLC [last-level cache] to recover the secret key of a modern sliding-window exponentiation based implementation of RSA, across cores and without relying on deduplication," the researchers wrote.

For this particular CPU cache attack to work, both the attacker's Amazon account and the target Amazon account containing the private RSA key must be on the same hardware chip or chip set. In the proof of concept, the researchers probed the LLC of the Intel Xeon E5-2670 v2 chip set used by Amazon's servers powering the EC2 platform. Whenever keys are used, they are stored in cache for a set time. The proof-of-concept relies on the keys still being in cache at the time of the attack.

One way to carry out this attack is to identify where the target's Amazon instance is located, then set up a rogue instance on the same piece of hardware in order to steal the RSA key. What's more likely to happen is that the attacker would grab the keys from a neighboring instance, then backtrack to try to figure out who the key belongs to and how it is used.

"Everything must work in concert together and it is highly difficult to pull off," Robin Alden, CTO of Comodo said.

Co-located virtual machines

The researchers had to rely on several different tactics to get two accounts located on the same chip to run the experiment. They noted that instances launched within short time intervals of each other were more likely to be co-located. They also created bottlenecks and monitored performance across instances to discover if they were co-located.

The attack technique "underlines the need for deploying stronger isolation techniques in public clouds," the researchers wrote in the paper's abstract.

The fact that researchers were able to demonstrate that an attack VM can be placed on the same machine as the victim VM was “troubling,” said Chenxi Wang, chief strategy officer of Twistlock. “The ability to manipulate the system to get on the same machine as a VM you intend to attack is not something a cloud provider would like to see.”

Providers need to patch the weaknesses that make these types of attacks possible, the researchers said. Smarter cache management policies at the hardware and software levels would prevent side-channel leakages and future exploits. Another method is to randomize the placement policy so that creating instances within a short period wouldn't put them all in the same co-located space.

"A more random placement policy would make it tougher for attackers to land on the same CPU or hardware as that of the intended target," said Sundaram Lakshmanan, vice president of technology at Ciphercloud.

Moreover, administrators should make sure to use the latest encryption software and libraries. The research team conducted its experiments on an Amazon EC2 virtual machine running Libgcrypt 1.6.2. Libgcrypt's maintainers have updated the library to version 1.6.3, which is no longer susceptible to this technique. Other cryptographic libraries should also be updated to ensure cache-based leakages cannot be exploited, the team said.

Rogue virtual machines ready to attack

This isn't the first time researchers uncovered a way attackers could steal keys on virtual machines. Back in 2009, another paper highlighted a key-recovery attack on co-located virtual machines. Many of the colocation techniques that worked back in 2009 no longer work.

"While the attack is still possible, our results show that, through combined efforts of all involved parties, the bar for performing successful attacks in the cloud is quickly rising," the researchers wrote. It will be up to Amazon to show how they will continue to add randomization into their VM-to-server mapping so these newer co-location attacks will cease to work, Wang said.

Although the attackers showed this type of attack is possible, businesses needn't panic and flee the cloud yet. Yes, cross-VM leakage is present in public clouds and can be a practical attack vector, but for co-location detection and data theft, the attacker would need a lot of luck to succeed.

Increased hardware complexity and better protected cryptographic libraries means attackers must have a large amount of expertise and sophistication to use these techniques. While a "very smart attack," the success probability is low, said Lakshmanan. Yet cloud providers should work to reduce that probability further nonetheless.