1 / 25

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

Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds. Thomas Ristenpart , Eran Tromer, Hovav Shacham ,Stefan Savage CCS’09 Speaker : Kuo. Outline. I ntroduction THREAT MODEL EC2 service NETWORK PROBING CLOUD CARTOGRAPHY DETERMINING CORESIDENCE

lisaf
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Hey, You, Get Off of My Cloud:Exploring Information Leakage inThird-Party Compute Clouds Thomas Ristenpart , Eran Tromer, Hovav Shacham ,Stefan Savage CCS’09 Speaker:Kuo

  2. Outline • Introduction • THREAT MODEL • EC2 service • NETWORK PROBING • CLOUD CARTOGRAPHY • DETERMINING CORESIDENCE • EXPLOITING PLACEMENT IN EC2 • CROSS-VM INFORMATION LEAKAGE

  3. introduction • Cloud computing: • cloud computing services • cloud computing technologies • Advantages: • dynamic provisioning • Low capital expenditures • Drawback: • risks between customer and cloud provider • risks between customer and customer

  4. 2. THREAT MODEL • we consider the provider and its infrastructure to be trusted. • adversaries are non-provider-affiliated malicious parties. • Assume: • a malicious party can run and control many instances in the cloud • an attacker’s instances might even run on the same physical hardware as potential victims.

  5. 3. EC2 service • Amazon’s Elastic Compute Cloud (EC2) service: • flexibly rent computational resources • Amazon provides two “regions”, US and Europe • Each region contains three “availability zones” • provides the ability to run Linux, FreeBSD, OpenSolaris and Windows within a virtual machine (VM) provided by a version of the Xen hypervisor • Domain0 : • Configured to route packets for its guest images and reports itself as a hop in traceroutes.

  6. zone1 zone2 zone3 US Europe Domain 0 VM VM VM VM

  7. a single virtual core providing one ECU combined with 1.7 GB of memory and 160 GB of local storage provides 2 virtual cores each with 2 ECUs, 7.5GB of memory and 850GB of local storage. • a valid account, a user creates one or more VM images • Instance: one such running image • instance type • ‘m1.small’ • ‘c1.medium’ • ‘m1.large’ • ‘m1.xlarge’ • ‘c1.xlarge’ • Each instance has • external IPv4 address and domain name • an internal private address and domain name

  8. 4.NETWORK PROBING • utilize nmap, hping,and wget to perform network probes to determine liveness of EC2 instances • nmap : perform TCP connect probes, attempt to complete a 3-way hand-shake between a source and target. • hping: perform TCP SYN traceroutes, which iteratively sends TCP SYN packets with increasing time-to-lives (TTLs). • wget: retrieve web pages

  9. two types of probes: • External probes: a system outside EC2 and has destination an EC2 instance. • internal probes:an EC2 instance (under our control) and has destination another EC2 instance.

  10. 5.CLOUD CARTOGRAPHY • Hypothesis: different availability zones (instance types) are likely to correspond to different internal IP address ranges • using data sets: • One created by launching a number of EC2 instances of varying types and surveying the resulting IP address assigned.

  11. availability zones • assumption :internal IP addresses are statically assigned to physical machines

  12. instance type and account: • account A and B • launched 100 instances(20 of each type) in zone3 • 55 of the account B IPs were repeats of those assigned to instances for account A

  13. 5.3 A fuller map of EC2

  14. 6. DETERMINING CORESIDENCE • instances are likely co-resident if they have (1) matching Dom0 IP address: (2) small packet round-trip times, (3) numerically close internal IP addresses 50%

  15. 7. EXPLOITING PLACEMENT IN EC2 • Goal: • How an adversary launch instance that will be co-residence with target victims • Observations • n instances in parallel under a single account results in placement on n separate machines. • No more than eight m1.small instances were ever observed to be simultaneously co-resident. • placement locality • Sequential placement locality • Parallel placement locality

  16. Sequential placement locality : • two instances run sequentially are often assigned to the same machine. • Parallel placement locality : • exists when two instances run (from distinct accounts) at roughly the same time are often assigned to the same machine.

  17. 7.1 Brute-forcing placement • strategy: • run numerous instances over a long period of time • 步驟: • Enumerates a set of potential target victims. • Infers these targets belong to whichzone and which instance type • repeatedly runs probe instances in the target zone and of the target type. • Each probe checks if it is co-resident with any of the targets. • If not the instance is quickly terminated. • Achieve 8.4% coverage of the target set

  18. 7.2 Abusing Placement Locality • strategy: • Assume that an attacker can launch instances relatively soon after the launch of a target victim • The attacker then engages in instance flooding:running as many instances in parallel as possible

  19. Different zone does not affect co-residence rates • Different account and time of day does not affect co-residence rates

  20. The effect of increased time lag. • “Total co-resident” corresponds to the number of probe instances at the indicated hour offset that were co-resident with at least one of the victims. “New co-resident” is the number of victim instances that were collided with for the first time at the indicated hour offset.

  21. 8. CROSS-VM INFORMATION LEAKAGE • Goal: • show the ability of a malicious instance to utilize side channels to learn information about co-resident instances.

  22. 8.1Measuring cache usage • a high load indicates activity on co-resident instances • utilize the Prime+Probe technique to measure cache activity • Measurement via Prime+Probe: • This measurement method tries to discover the set of memory blocks read by the encryption a posteriori, by examining the state of the cache after encryption.

  23. Cache-based covert channel • Cache load measurements create very effective covert channels between cooperating processes running in different VMs • A covertchannel is any communication channel that can be exploited by a process to transfer information in a manner that violates the system’s security policy • cache covert-channel attack: • the sender idles to transmit “0” and frantically accesses memory to transmit “1”. • The receiver accesses a memory block of his own and observes the access latencies. High latencies are indicative that the sender is evicting the receiver’s data from the caches, i.e., that “1” is transmitted.

  24. 8.2 Load-based co-residence detection • In the second trial we used a fresh pair of instances co-resident on a different machine,

  25. Thanks!

More Related