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

THOMAS RISTENPART, ERAN TROMER, HOVAV SHACHAM, STEFAN SAVAGE Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds

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 – A public IP corresponds to a DNS name – ec compute-1.amazonaws.com Internal DNS queries return an internal IP and DNS names – – domU D-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 Zen Hypervisor Dom0Guest1Guest2

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