Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds

1. 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

2. Outline • Cloud Computing and Threat Model (Najim) • Amazon EC2 Service, Network Probing (Ning) • Attacking Tasks: • Cloud Cartography (Najim) • Co-residence Checks (Najim) • VM Placement (Ning) • Information Leakage (Ning) • Conclusions (Najim)

3. The problem with Cloud Computing 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.

4. Threat Model 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.

5. Exploring Information Leakage in Third-Party Compute Clouds Difficulties/Tasks for the attacker: • Need to find out where the target VM is located • Need to be co-resident with the target • Need to compromise valuable information from the target What we do: • Explore how to map the cloud and understand instance creation parameters to establish co-residency • Actual attack on current-day third-party popular Amazon EC2 service to highlight relevancy • Experienced 40% success in co-residency with target VM

6. Threat Model - Questions • Can one determine where in the cloud infrastructure an instance is located? • We first show how to map the cloud • Can one easily determine if two instances are co-resident on the same physical machine? • We implement co-residence checks • Can an adversary launch instances that will be co-resident with other user's instances? • Launch waves of probe VMs for VM placement • Can an adversary exploit cross-VM information leakage once co-resident? • We highlight cross-VM information leakage

7. The Amazon Elastic Compute Cloud (EC2) • Services Provided by EC2 • EC2 allows users to rent virtual computers on which to run their own computer applications.  • EC2 allows scalable deployment of applications by providing a Web service. User can boot an Amazon Machine Image to create a virtual machine, which Amazon calls an "instance", containing any software desired. • EC2 crashed on April 21 • Victims: Foursquare, Quora, Heroku

8. The Amazon Elastic Compute Cloud (EC2) • A privileged virtual machine, called Domain0, is used to manage guest images, physical resource provisioning, and access control rights. It routes packages and reports itself as a first hop. • 2 regions (United States and Europe), each have 3 availability zones, 5 Linux instance types • Instances have a one-to-one mapping of internal IP addresses and external IP addresses, which are static • Example: • External IP: 75.101.210.100 • Name: ex2-75-101-210-100.compute-1.amazonaws.com • Internal IP: 10.252.146.52 • Name: domU-12-31-38-00-8D-C6.compute-1.internal

9. Network Probing tools We use Nmap, hping, and wget for probing • Nmap (Network Mapper) is a security scanner used to discover hosts and services on a computer network, thus creating a "map" of the network. To accomplish its goal, Nmap sends specially crafted packets to the target host and then analyzes the responses. •  hping is a packet generator and analyzer for the TCP/IP protocol. Hping is one of the de facto tools for security auditing and testing of firewalls and networks. •  Wget is a computer program that retrieves content from web servers. It supports downloading via HTTP, HTTPS, and FTP protocols, the most popular TCP/IP-based protocols used for web browsing. Each tool is free and easy to use.

10. Question 1 - Mapping the Cloud Hypothesis: Different availability zones correspond to different statically defined internal IP addresses and may also correspond to instance types. Disclaimer: 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).

11. Question 1 - Mapping the Cloud Figure 1: Plot of internal IPs against zones Result: Different availability zones correspond to different statically defined internal IP address ranges.

12. Question 1 - Mapping the Cloud Figure 2: Plot of internal IPs in Zone 3 against instance types Result: Same instance types correspond loosely with similar IP address range regions.

13. Question 2: Determining Co-Residence Network-based co-resident checks: instances are likely co-resident if they have: • matching Dom0 IP address, • small packet round-trip times, or • numerically close internal IP addresses (e.g. within 7) 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.

14. Question 3: Probe VM Placement Key Amazon EC2 observations: • A single account never has more than one instance running on the same physical machine (this might be an issue..) • Strong placement locality. When 2 instances run sequentially or concurrently, most likely on the same machine. • Amazon balances load across running machines. A  bias for placement on machines with fewer instances. 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.

15. Question 3: Probe VM Placement 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)

16. Question 3: Probe VM Placement 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.

17. Question 3: Probe VM Placement 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.

18. Question 4: Information Leakage Co-Residency affords the ability to: • Denial of Service • Estimate victim's work load • Cache • Network Traffic • Extract cryptographic keys via cache-based side channels. • Other cross-VM attacks

19. Conclusion We have successfully shown that: • Public clouds can be successfully mapped using simple networking probing tools • Demonstrated the possibility of targeted co-residency • Highlighted many security holes presented once an attacking instance is successfully a co-resident of a victim

20. Take-Home Points 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.

21. Thank You!