Hey, You, Get Off of My Cloud: Exploring Information Leakage in

Download Report

Transcript Hey, You, Get Off of My Cloud: Exploring Information Leakage in

Hey, You, Get Off of My Cloud:
Exploring Information Leakage in
Third-Party Compute Clouds
Written by
Thomas Ristenpart
Eran Tromer
Hovav Shacham
Stehan Savage
Presented by
Jeremy Weinstein
Outline
Introduction
Motivation
System specifications
Experiments




Explore cloud infrastructure.
Determine co-residency.
Achieve co-residency.
Exploit information.
Legal, Ethical, and Contractual implications
Conclusion
Contributions
Weaknesses
References
Questions?
Introduction
Cloud computing is an networked
computing system in which hardware with
extra resources can be used by other
users.
Resource examples:


Clock cycles
Disk space
Introduction
Sample Architecture
Introduction
Who is this useful for?
Consumers


Need more computing resources than they have
available.
Temporary need which does not justify purchasing
hardware.
Seller


Has more resources than they need.
Can make revenue selling or renting to clients.
Motivation
Computing systems such as this have
many well documented security flaws.
New infrastructure “expands the attack
surface of the victim.”
One client can access information from
another if they are on the same physical
machine.
System specifications
Experiments were preformed on Amazon’s EC2 (Elastic
Compute Cloud).
Client space was purchased.

This took the form of one or more Virtual Machines (VM).
Most experiments were done on m1.small instance type.
The following specifications were split across all active
clients on this particular cloud.





32-bit architecture
Single virtual core equivalent to 1.0-1.2 GHz 2007 Opteron
processor.
1.7 GB memory
160 GB disk space.
$0.10 per hour fee.
Experiments
The goal is to determine the viability of
attaining restricted data from another
client.
Targeted ports 80 and 443 only (http and
https).
The experiments use network probing to
attain relevant information.
Probes
External Probe:

Probe originates outside the EC2 server and
targets a user in the EC2 server.
Internal Probe:

Probe originates inside the EC2 server and
targets a user in the EC2 server.
External probing is contractually illegal by
Amazon’s Terms of Use Policy.
Exploring the cloud infrastructure
Clients on the EC2 server were assigned
an IP address with 16-24 prefix bits shared
with other clients’ IPs, depending on
instance type.
Probing other addresses with WHOIS
determined which areas of the network
were being utilized by users.
Cloud Cartography
Determining co-residency
To be co-resident you need:



Matching dom0 addresses (same hardware)
Small round-trip packet time or
Similar IP addresses
Using multiple accounts in arbitrary locations,
they checked these factors to determine coresidency.
Having the actual values of one’s own account
determined a nil false positive rate.
Achieving co-residency
Two techniques are presented to become coresident with another user
Brute Force


Arbitrarily probe a target zone over a long period of
time.
Experiments achieved an 8.4% coverage of targets.
Placement Locality


Attack recently launched instances (temporal locality).
Reports achieving co-residence 40% of the time.
Achieving co-residency
Exploiting information
Knowing about the cloud your account is
on gives you key information about other
users

E.G. computational load.
The slower your memory access, the more
resources a co-resident user is using.
One proposed method of using this
information is as a pseudo key logger,
determining the time between keystrokes.
Extracting information
1) Allocate memory
2) Sleep briefly to rank high on the scheduler
3) Prime: Read the memory to be sure its fully
cached
4) Trigger: Loop until CPU’s cycle increases by
a large amount (indicates other user access)
5) Probe: Analyze differences between reads.
Legal, Ethical, and Contractual
implications
Project was government funded.
Computer Fraud and Abuse Act
Probes checked public ports only
Skirted around definitions such as
“access” and “authorization”
A malicious hacker would not be
constrained by these issues
Prevention
A hacker can be slowed or stopped by
trying to prevent internal probing, or
reducing the information a client has.
Doing so would limit vulnerability of clients.
Hackers would be prevented from seeing
private information about the provider such
as server infrastructure.
Conclusion
Using these techniques a hacker can gain
access a cloud client.
As a client




Probe the network
Learn its mapping
Attempt to gain co-residence with another
client
Gain private information from the co-resident
Contributions
Thorough analysis of every step required
to exploit this technique.
Techniques yielded good results.

Indicated the importance of this work.
Made recommendations for further work.
Weaknesses
Omitted outlier results from their
conclusions.
Walked a fine line of unethical research.
Many graphs seemed busy and unhelpful.
One experiment implied a very low
number of test cases.
References
[1] Ristenpart T, Trhomer E, Scacham H,
Savage S. “Hey, You, Get Off of My
Cloud: Exploring Information Leakage in
Third-Party Compute Clouds.” 2009.
[2] Cloud Computing.
www.en.wikipedia.org/wiki/Cloud_Computi
ng. March 2010.
Questions?