Transcript Security I
Lecture 4: Cloud Computing Security: a first look Xiaowei Yang (Duke University) Cloud Computing: the good • Elasticity – On demand scaling – The illustration of infinite resources • Pay-as-you go – No up-front cost – Pay what you need: no risk for under or over provisioning Cloud Computing: the bad • Placing your valuable code/data on a third party infrastructure – A rogue cloud admin – How do you verify what you get? • Your VMs may co-reside in the same physical machines/network as your adversaries’ – Information leaking – Denial of service attacks • • More discuss in the next lecture Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds THOMAS RISTENPART, ERAN TROMER, HOVAV SHACHAM, STEFAN SAVAGE Overview of the attack 1. Placement – Placing eavesdropping VMs to co-reside with targeted VMs 2. Extraction – Extracting confidential information via cross-VM side channels • RSA or AES secret keys Threat model • Trusted cloud provider – A requirement for using third-party resources for now • Attackers are non-provider-affiliated malicious cloud users • Victims are other cloud users that have sensitive information Case study: EC2 • Three availability zones for fault tolerance – Geography – Hardware isolation • Five types of instances – m1.small, c1.medium, m1.large, m1.xlarge, c1.xlarge • a total of 15 combinations IP addresses of instances • An instance may have a public IP – 75.101.210.100 • A public IP corresponds to a DNS name – ec2-75-101-210-100.compute-1.amazonaws.com • Internal DNS queries return an internal IP and DNS names – 10.252.146.52 – domU-12-31-38-00-8D-C6.compute-1.internal Virtualization structure • Dom0 manages guest images, physical resource provisioning, and access control rights • EC2: Dom0 routes packets for guest images – Last hop in traceroute Guest1 Guest2 Zen Hypervisor Dom0 Network probing • External probing from outside EC2 • Internal probing from an instance inside Cloud Cartography • Hypothesis – Same availability zone shares IP prefixes – VMs on the same physical machines share IP prefixes • Evaluation – Mapping EC2 public service to internal IPs – Creating test instances Determining placement parameters • Launch instances for each of the 15 availability/instance type combination • Obtain their internal IP addresses Availability Zone Instance type and accounts • 100 instances for the same zone • From a different account • Stick to the same Derive IP address allocation rules • Heuristics to label /24 prefixes with both availability zone and instance type: • All IPs from a /16 are from the same availability zone. • A /24 inherits any included sampled instance type. If there are multiple instances with distinct types, then we label the /24 with each distinct type (i.e., it is ambiguous). • A /24 containing a Dom0 IP address only contains Dom0 IP addresses. We associate to this /24 the type of the Dom0’s associated instance • All /24’s between two consecutive Dom0 /24’s inherit the former’s associated type. A mapping of public EC2 servers Determining Co-Residence • ? Achieving Co-Residence • Bruce-force – Launching many instances – Co-residence with 141 victim servers out of 1686 targeted servers – Sets of 20 – Varied time intervals – 1785 probe instances Abusing placement locality • Timing correlation • Instance flooding – Launch many instances soon after victim servers are launched – 40% success out of 20 probes Question • How to determine when a victim instance is launched? Extraction • Many low level techniques – Cache usage – Load-based co-residence detection – Estimating traffic rates – Keystroke time attack Summary • A first look at cloud security problems • Co-residence can be harmful • Next: more case studies and overview of security problems