Transcript Lecture 3: Cloud Computing Security: first look

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