Hey, You, Get Off of My Cloud:
Exploring Information Leakage
in Third-Party Compute Clouds
by Thomas Ristenpart et al.
defended by Ning Xia & Najim Yaqubie
Outline
1. Cloud Computing and Threat Model (Najim)
2. Amazon EC2 Service, Network Probing (Ning)
3. Attacking Tasks:
1.Cloud Cartography (Najim)
2.Co-residence Checks (Najim)
3.VM Placement (Ning)
4.Information Leakage (Ning)
4. Conclusions (Najim)
The problem with Cloud Computing
Originally, servers were hosted by
individual companies and maintained
on separate and (hopefully) secure
hardware.
Public clouds allow multi-tenancy:
Multiple independent users share the
same physical infrastructure:
multiplexing virtual machines of
potentially malicious users on the same
server.
Threat Model
Traditional threat is a remote exploitation of vulnerabilities in
software, whereas clouds allow attackers to act as legitimate
clients of the third-party cloud.
Major Threat: Potentially malicious and
adversarial instances can run on the same physical resources
as a victim instance. Thus, those resources (CPU caches,
DRAM memory bus, CPU pipelines, etc.) can be manipulated
to compromise information.
Exploring Information Leakage in ThirdParty Compute Clouds
Difficulties/Tasks for the attacker:
1. Need to find out where the target VM is located
2. Need to be co-resident with the target
3. Need to compromise valuable information from the target
What we do:
1. Explore how to map the cloud and understand instance
creation parameters to establish co-residency
2. Actual attack on current-day third-party popular Amazon
EC2 service to highlight relevancy
3. Experienced 40% success in co-residency with target VM
Threat Model - Questions
1. Can one determine where in the cloud infrastructure an
instance is located?
o We first show how to map the cloud
2. Can one easily determine if two instances are co-resident on
the same physical machine?
o We implement co-residence checks
3. Can an adversary launch instances that will be co-resident
with other user's instances?
o Launch waves of probe VMs for VM placement
4. Can an adversary exploit cross-VM information leakage
once co-resident?
o We highlight cross-VM information leakage
The Amazon Elastic Compute Cloud
(EC2)
• Services Provided by EC2
o
o
EC2 allows users to rent virtual computers on which to run their
own computer applications.
EC2 allows scalable deployment of applications by providing a
Web service. User can boot an Amazon Machine Image to
create a virtual machine, which Amazon calls an "instance",
containing any software desired.
• EC2 crashed on April 21
o Victims: Foursquare, Quora, Heroku
The Amazon Elastic Compute Cloud
(EC2)
• A privileged virtual machine, called Domain0, is used to manage
•
guest images, physical resource provisioning, and access control
rights. It routes packages and reports itself as a first hop.
•
• 2 regions (United States and Europe), each have
3 availability zones, 5 Linux instance types
•
• Instances have a one-to-one mapping of internal IP addresses and
external IP addresses, which are static
 Example:
 External IP: 75.101.210.100
 Name: ex2-75-101-210-100.compute-1.amazonaws.com
 Internal IP: 10.252.146.52
 Name: domU-12-31-38-00-8D-C6.compute-1.internal
Network Probing tools
We use Nmap, hping, and wget for probing
o
Nmap (Network Mapper) is a security scanner used to discover hosts and
services on a computer network, thus creating a "map" of the network. To
accomplish its goal, Nmap sends specially crafted packets to the target
host and then analyzes the responses.
o
hping is a packet generator and analyzer for the TCP/IP protocol. Hping
is one of the de facto tools for security auditing and testing of firewalls and
networks.
o
Wget is a computer program that retrieves content from web servers. It
supports downloading via HTTP, HTTPS, and FTP protocols, the most
popular TCP/IP-based protocols used for web browsing.
Each tool is free and easy to use.
Question 1 - Mapping the Cloud
Hypothesis: Different availability zones correspond to different
statically defined internal IP addresses and may also
correspond to instance types.
Disclaimer:
We limited our scope to public servers on Amazon EC2. Highlighting legal, ethical
and contractual obligations, we targeted publicly facing ports (80 - HTTP, 443 HTTPS) under the assumption that providing a service designed to be accessed
by the public is an implicit authorization to do so.
We utilized WHOIS queries on 57,344 IP addresses and
narrowed down to 14045 unique internal IPs (after probes to
port 80 and 443, and appropriate DNS lookup inside EC2).
Question 1 - Mapping the Cloud
Figure 1: Plot of internal IPs against zones
Result: Different availability zones correspond to different
statically defined internal IP address ranges.
Question 1 - Mapping the Cloud
Figure 2: Plot of internal IPs in Zone 3 against instance types
Result: Same instance types correspond loosely with similar IP
address range regions.
Question 2: Determining Co-Residence
Network-based co-resident checks: instances are likely coresident if they have:
o matching Dom0 IP address,
o small packet round-trip times, or
o numerically close internal IP addresses (e.g. within 7)
These checks do not require that both instances are under our
control and from an experiment using a hard-disk-based covert
channel, since both instances must be co-resident to send
messages over a cross-VM covert channel.
Conclusion of test: Effective false positive rate of ZERO for the
co-resident checks.
Question 3: Probe VM Placement
Key Amazon EC2 observations:
1. A single account never has more than one instance running
on the same physical machine (this might be an issue..)
2. Strong placement locality. When 2 instances run
sequentially or concurrently, most likely on the same
machine.
3. Amazon balances load across running machines. A bias for
placement on machines with fewer instances.
We concentrate on m1.small instances because they are most
popular with EC2 and can run up to 4 instances on one
machine.
We have achieved similar co-residence with c1.medium, and
m1.large, though m1.xlarge and c1.xlarge instance types
encompasses entire machines. But no co-residence was ever
observed for m1.xlarge and c1.xlarge instances.
Question 3: Probe VM Placement
Strategy 1: Brute-forcing placement
Attacker determines victim set and their respective IP ranges
based on zone and type, then repeatedly runs probe instances.
Not really all to clever, but achieves a success rate of 8.4%
(141 victim servers of 1686 target victims).
This shows that even a very naive attack strategy can
successfully achieve co-residency with a target instance (over a
large target set, limits relevancy)
Question 3: Probe VM Placement
Strategy 2: Abusing Placement Locality
Attacker engages in instance flooding in the appropriate
availability zone and of the appropriate instance type
immediately following launch of instance.
Achieves a success rate of 40%
Why? Cloud computing allows dynamic resource allocation,
thus, the nature provides environment for servers to be
terminated when not used, then run again later when need.
Also, an attacker may be able to trigger new instances due to
the use of auto-scaling systems due to increased load.
Question 3: Probe VM Placement
Figure 3: Effects of time lag between victim and probe launch
Result: The window of opportunity is large to afford coresidency and multiple 3-way collisions (2 attackers, 1 victim)
Placement locality has a strong impact.
Question 4: Information Leakage
Co-Residency affords the ability to:
1. Denial of Service
2. Estimate victim's work load
1.Cache
2.Network Traffic
3. Extract cryptographic keys via cache-based side channels.
4. Other cross-VM attacks
Conclusion
We have successfully shown that:
• Public clouds can be successfully mapped using simple
networking probing tools
• Demonstrated the possibility of targeted co-residency
• Highlighted many security holes presented once an
attacking instance is successfully a co-resident of a victim
Take-Home Points
A blogger, William Vambenepe also went after disk blocks and
memory after reading this paper. By using a Foremost (console
program to recover files based on their headers, footers, and
internal data structures), he was able to extract more than
23,000 files. (example shown at:
stage.vambenepe.com/archives/922)
This paper has since been cited over 121 times, of which
subsequent recent papers have been cited over 140 times
collectively. We hoped that this research would illuminate some
of the security issues inherent in third-party compute clouds
and would spur research and necessary security approaches to
mitigate the clear risk.
Thank You!