Distributed System Lab.1 Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds Thomas Ristenpart ¤, Eran Tromer, Hovav Shacham ¤, and Stefan Savage ¤ ¤ Dept. of Computer Science and Engineering University of California, San Diego, USA Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology, Cambridge, USA

Distributed System Lab.2 Outline Introduction Treat Model & EC2 Network Probing Cloud Cartography Determining Co-Residence Exploiting Placement EC2 Cross-VM Information Leakage Conclusion & Future References

Distributed System Lab.3 Introduction Third-party cloud computing represents the promise to out-sourcing as applied to computation. The use of virtualization allows third-party cloud providers to maximize the utilization by a shared physical infrastructure. New vulnerabilities: It is possible to map the internal cloud infrastructure. We explore how such placement can then be used to extract information.

Distributed System Lab.4 Threat Model We consider the provider and its infrastructure to be trusted. Adversaries are non-provider-affiliated malicious parties. Victims are users running confidentiality- requiring services in the cloud. Two kinds of attackers: Those who are interested in being able to attack some known hosted service. Those focused on attacking a particular victim service.

Distributed System Lab.5 The EC2 Service To run Linux, FreeBSD, OpenSolaris and Windows as guest operating system. Those VMs are provided by a version of the Xen hypervisor. EC2 does not appear to currently support live migration of instances. Each user account is limited to 20 concurrently running instances.

Distributed System Lab.6 Amazon s EC2 Two regions at U.S. and one at Europe. Three availability zones for each region. availability zones are meant to specify infrastructures with distinct and independent failure modes. There are five Linux instance types: m1.small, c1.medium, m1.large, m1.xlarge, and c1.xlarge. Each instance is given Internet connectivity: External IPv4 address and domain name. Internal RFC 1918 private address and domain name.

Distributed System Lab.7 Network Probing We use nmap to perform TCP connect probes To complete a 3-way hand-shake. We use hping to perform TCP SYN traceroutes. To send TCP SYN packets with increasing TTLs until no ACK is received. We only targeted ports 80 or 443. We used wget to retrieve web pages, but at most 1024 bytes. Two types of probes: External probes: It originates form a system outside EC2 to EC2 s instance. Internal probes: It originates from an EC2 instance to another. We use DNS resolution queries To determine the external name of an instance. To determine the internal IP address of an instance associated with some public IP address.

Distributed System Lab.8 Cloud Cartography (1) map the EC2 service to understand: Where potential targets are located in the cloud. The instance creation parameters needed to attempt establishing co-residence instance. The hypothesis: Different availability zones are likely to correspond to different internal IP address ranges. Two data sets: One created by enumerating public EC2-based web servers using external probes and translating responsive public IPs to internal IPs. Another created by launching a number of EC2 instances of varying types and surveying the resulting IP assigned.

Distributed System Lab.9 Cloud Cartography (2) Surveying public servers on EC2 We performed: a TCP connect probe on port 80, a follow-up wget on port 80, and a TCP port 443 scan. Via an appropriate DNS lookup from within EC2, we translated each public IP into an internal EC2 address. One of the goals is to enable identification of the instance type and availability zone of these potential targets. Instance placement parameters To launch instances by a single account, or two accounts. The samples from each zone are assigned IP addresses from disjoint portions of the internal address space. A fuller map of EC2

Distributed System Lab.10 Instance placement parameters

Distributed System Lab.11 Determining Co-Residence Instances are likely co-resident if they have Matching Dom0 IP address, Instance owner: the first hop on any route from it. Uncontrolled instance: the last hop of a TCP SYN tranceroute to it. Small packet round-trip times, The first reported RTT in any probes was almost an order of magnitude slower than subsequent probes. Numerically close internal IP addresses The same Dom0 IP will be shared by instances with a contiguous sequence of internal IP address. Veracity of the co-residence checks If two instances can successfully transmit via the covert channel then they are co-resident, otherwise not. A hard-disk-based covert channel (under our control). A TCP SYN traceroute to an open port on the target, and sees if there is only a single hop.

Distributed System Lab.12 Exploiting Placement in EC2 (1) To say the attacker is successful if he achieves good coverage (co-residence with a notable fraction of the target set) A single account was never seen to have two instances running on the same physical machine. Strong placement locality: Two instances run sequentially are often assigned to the same machine.

Distributed System Lab.13 Exploiting Placement in EC2 (2) Brute-forcing placement To run numerous instances over a long period of time and see how many targets are co-residence. Abusing placement locality We assume an attacker can launch instances soon after the launch of a target victim. The attacker engages in instance flooding. This suggests servers are often run on instances, terminated when not need, and later run again. Patching placement vulnerabilities Let users request placement of their VMs on machines that can only be populated by VMs from their accounts.

Distributed System Lab.14 Cross-VM Information Leakage (1) Measuring cache usage Load measurement: 1. Prime: Read BUFFER at offsets of cache line size. 2. Trigger: Busy-loop until CPU s cycle counter jumps by a large value. 3. Probe: Measure the time for reading BUFFER at offsets of cache line size. Cache-based covert channel Sender: To transmit 0 for idle, and frantically accesses memory for 1. Receiver: To access memory and observes the access latencies. High latencies = the sender is evicting the receiver s data form cache.

Distributed System Lab.15 Cross-VM Information Leakage (2) Load-based co-residence detection An adversary can actively cause load variation due to a publicly-accessible service on the target.

Distributed System Lab.16 Cross-VM Information Leakage (3) Estimating traffic rates Two m1.small instances 1000 cache load measurements in one instances 20 users (jmeter) Web page is 3 Mb

Distributed System Lab.17 Cross-VM Information Leakage (4) Keystroke timing attack The adversary s goal is to measure the time between keystrokes made by a victim typing a password. We utilize the Prime+Trigger+Probe load measurement technique to detect activity spikes in an otherwise idle machine. The same attack could be carried over to EC2, except that this technique applies only to VMs that timeshare a core.

Distributed System Lab.18 Conclusion & Future We argue that fundamental risks arise from sharing physical infrastructure between distrustful users. Future Cloud providers may obfuscate both the internal structure of their services and the placement policy. One may focus on the side-channel vulnerabilities and employ blinding techniques. We believe that the best solution is simply expose the risk and placement decisions directly to users.

Distributed System Lab.19 References [1] T. Ristenpart, E. Tromer, H. Shacham, and S. Savage, Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds. In CCS, 2009.

Distributed System Lab.20 Q & A Thank you!