Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds. by Thomas Ristenpart et al. defended by Ning Xia & Najim Yaqubie. Outline. Cloud Computing and Threat Model (Najim) Amazon EC2 Service, Network Probing (Ning) Attacking Tasks:
Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds
by Thomas Ristenpart et al.
defended by Ning Xia & Najim Yaqubie
Originally, servers were hosted by individual companies and maintained on separate and (hopefully) secure hardware.
Public clouds allow multi-tenancy:
Multiple independent users share the same physical infrastructure: multiplexing virtual machines of potentially malicious users on the same server.
Traditional threat is a remote exploitation of vulnerabilities in software, whereas clouds allow attackers to act as legitimate clients of the third-party cloud.
Major Threat: Potentially malicious and adversarial instances can run on the same physical resources as a victim instance. Thus, those resources (CPU caches, DRAM memory bus, CPU pipelines, etc.) can be manipulated to compromise information.
Difficulties/Tasks for the attacker:
What we do:
We use Nmap, hping, and wget for probing
Each tool is free and easy to use.
Hypothesis: Different availability zones correspond to different statically defined internal IP addresses and may also correspond to instance types.
We limited our scope to public servers on Amazon EC2. Highlighting legal, ethical and contractual obligations, we targeted publicly facing ports (80 - HTTP, 443 - HTTPS) under the assumption that providing a service designed to be accessed by the public is an implicit authorization to do so.
We utilized WHOIS queries on 57,344 IP addresses and narrowed down to 14045 unique internal IPs (after probes to port 80 and 443, and appropriate DNS lookup inside EC2).
Figure 1: Plot of internal IPs against zones
Result: Different availability zones correspond to different statically defined internal IP address ranges.
Figure 2: Plot of internal IPs in Zone 3 against instance types
Result: Same instance types correspond loosely with similar IP address range regions.
Network-based co-resident checks: instances are likely co-resident if they have:
These checks do not require that both instances are under our control and from an experiment using a hard-disk-based covert channel, since both instances must be co-resident to send messages over a cross-VM covert channel.
Conclusion of test: Effective false positive rate of ZERO for the co-resident checks.
Key Amazon EC2 observations:
We concentrate on m1.small instances because they are most popular with EC2 and can run up to 4 instances on one machine.
We have achieved similar co-residence with c1.medium, and m1.large, though m1.xlarge and c1.xlarge instance types encompasses entire machines. But no co-residence was ever observed for m1.xlarge and c1.xlarge instances.
Strategy 1: Brute-forcing placement
Attacker determines victim set and their respective IP ranges based on zone and type, then repeatedly runs probe instances.
Not really all to clever, but achieves a success rate of 8.4% (141 victim servers of 1686 target victims).
This shows that even a very naive attack strategy can successfully achieve co-residency with a target instance (over a large target set, limits relevancy)
Strategy 2: Abusing Placement Locality
Attacker engages in instance flooding in the appropriate availability zone and of the appropriate instance type immediately following launch of instance.
Achieves a success rate of 40%
Why? Cloud computing allows dynamic resource allocation, thus, the nature provides environment for servers to be terminated when not used, then run again later when need.
Also, an attacker may be able to trigger new instances due to the use of auto-scaling systems due to increased load.
Figure 3: Effects of time lag between victim and probe launch
Result: The window of opportunity is large to afford co-residency and multiple 3-way collisions (2 attackers, 1 victim)
Placement locality has a strong impact.
Co-Residency affords the ability to:
We have successfully shown that:
A blogger, William Vambenepe also went after disk blocks and memory after reading this paper. By using a Foremost (console program to recover files based on their headers, footers, and internal data structures), he was able to extract more than 23,000 files. (example shown at: stage.vambenepe.com/archives/922)
This paper has since been cited over 121 times, of which subsequent recent papers have been cited over 140 times collectively. We hoped that this research would illuminate some of the security issues inherent in third-party compute clouds and would spur research and necessary security approaches to mitigate the clear risk.