CS 739 Reviews - Fall 2014

Summary,
In this paper the authors explore the security vulnerabilities faced by customers using the virtualized computing services provided by cloud computing service providers like Amazon EC2, Windows Azure etc

Problem,
In cloud computing services like EC2, the service lets customers to create and launch virtual machines to run their software. In this paper, given that there are clever adversaries who will target these customers, the authors explore the feasibility for these adversaries to create a virtual machine on the same physical machine as the target customer and then launch attacks on the target using VM side channels.

Contributions,
The authors produce a cloud cartography to learn the where the VMs are placed in the service just by using the public and private IP and DNS information available to any customer of these services. They demonstrate how easy it is for a clevel adversary to learn the characteristics of these cloud services.

Further, they show how easily the adversary can verify if they have achieved co-location, (i.e,) creating a VM on the same physical machine as the target. And given that this is verifiable, they develop a simple approach that can be used to achieve this co-location.

Given that the co-location is achievable, the authors also show how it is possible to exploit the covert side channels between these VMs to leak information, detect when there is peak activity in the target VMs etc.

Apart from demonstrating these vulnerabilities, the authors also discuss and suggest possible security measures that can be developed by the cloud vendors to beat such attacks.

Flaws,

Though it is possible for any adversary to learn the private IP information of the target VM and achieve co-location with a significant success rate, the attack that could be launched is very passive, given that it is only possible to steal key strokes only when the VMs share the same core which is not guaranteed in EC2.

Though there are vulnerabilities faced by small VM instances that share the physical machines, large VM instances where typically popular services would be run do not have any vulnerabilities since it would not be possible to achieve co-location.

Relevancy,
Provided that a lot of web services are increasingly migrating to cloud compute services, this paper gives a much needed insight into security vulnerabilities faced by such customers and hence is highly relevant.

summary:
- the paper discusses the scenarios in which a user can gain information about another user.

problem:
- cloud computing services provide computing facilities to users.
- they usually provide virtual machines to users.
- different users can have virtual machines on the same physical machine.
- they can access some information when the VMs are on the same machine.

method:
- they consider that the service provider is trusted and investigate the ways that a user can gain information about other users.
- there are two steps: placement and extraction
- placement is finding the physical machine that a VM is running on.
- extraction is gaining information about the other VMs
- they consider different scenarios and perform different experiments to find the physical machine of a given set of target VMs (for example by investigating the IP address of the VMs).
- they also investigate how a user can place its VM on the same machine as a target VM (for example using brute force).
- they run different experiments and tested the success rate of their attacks.
- they also provides some solutions on how a provider can prevent these scenarios (for example how the provider can obfuscate the co-residence; or letting the user decides whether or not share a physical machine with other unknown users).
- they investigate different kinds of information that can be accessed when two VMs are on the same machine (for example measuring the load)

contributions:
- they investigated the new kinds of vulnerabilities that can arouse from the cloud computing solutions.
- they found different vulnerabilities, they tested success rate of the attacks, and also provided some solutions.

Summary:
- The paper explores the probability of co-residence between the target victim virtual machine (VM) and the attacking VM on Amazon’s EC2.
- The paper exposes risks from co-residence, such as 1) measuring cache usage for denial of service and 2) keystroke timing attack for password recovery.
- The paper explores methods to inhibit side-channel attacks by inhibiting co-residence checks or avoiding co-residence altogether.

Problem:
- The paper wants to gather meaningful data (cryptographic keys and passwords) from target VMs of cloud computing services.
- The paper had to find methods to promote co-residence.

Contributions:
- The paper can determine co-residence using Dom0 IP address, small packet round-trip times, or internal IP addresses. This info is useful for the victim target-VM, because they can check if there is co-residence with any unknown VM (potential attackers).
- The paper explores the probability of co-residence, and concluded that neither zone nor time of day matters, and there is a 40% chance to find your target VM with 20 instances. This informs people that they could do security audits on a low budget.
- The paper links the information they could extract with co-residence to the potential threat for target-VMs. For example, keystroke timing attack could be used for pass recovery. This informs victims how to avoid such attacks.

Applicability:
- When customers sign up for cloud computing services, they are aware that the host is capable of monitoring their usage. Therefore, I question whether customers with strong privacy requirements will even bother using a third party cloud computing service. If the company is big and security attacks are profitable, then that big company should be able to afford their own private cloud. Furthermore, having your own private cloud is cheaper in the long run because each large VM costs $10 per a day.
- The paper only explored Amazon’s EC2 services, but not Microsoft’s Azure nor Rackspace’s Mosso. However, the paper’s methodology for co-residence might not be applicable to other cloud computing services with other target VMs because the paper already had a little bit of trouble establishing co-residence with rPath (target VM).

Summary

In this paper , Thomas Ristenpart exposes the vulnerabilities of deploying VMs in the third party cloud and provides a case study of how these cross VM attacks could actually take place

Problem

Due to obvious reasons such as reduced operational and maintenance costs , companies have started deploying their systems as VMs in third party clouds.Third party clouds on the other hand , to maximize server consolidation , run these isolated VMs on the same physical server . So the author argues that by placing the attacker's VM on the same physical machine as the victim's VM , the attacker can successfully detect this information and use side channels to leak the victim VM's information

Contributions

1.Cloud Cartography - Using network probing tools such as nmap,hping and wget along with Amazon EC2's DNS Server which maps the public IPs to the private IPs , the author was successfully able to map IPs to various zones and various types of VM instances that can be deployed

2.Coresidence - By matching Dom0 IP address , two VMs can be successfully matched to the same physical machine (running on the same Xen hypervisor )

3.VM Placement - By either a brute force method or gathering information on when the target VM is launched and spawning parallel VMs on every server , the attacker can successfully place his VM on the same server as the victim's VM

4.Extraction - By successfully being placed on the same physical machine as the victim , the attacker can gain useful information from the cache , estimate its network traffic and also use inter keystroke timings to gain victim’s password

Applicability

This paper shows that cloud service providers have not really scrutinized the security of their system . Simple changes such as disabling network probing tools in the servers or assigning IPs to VM dynamically using DHCP can definitely make it much harder to initiate cross VM attacks . The author also proposes giving explciit control of VM placement of the user making coresidence harder to achieve

Summary
Unlike the previous papers we read mainly focusing on the design of distributed system, this paper identifies the fundamental risks when using sharing physical infrastructure through a third-party cloud compute service. The authors describe the method they used to find the holes, prove the practicability of hacking, and propose simple approaches to mitigating these risks.

Problem Description
The cloud computing gains a lots of attentions over past few years, which is regarded as the next infrastructure for storing data and providing other services. Lots of famous companies, like Microsoft and Amazon, now provide such services and make benefits from that. Surprisingly, far away from high security as it should be, current cloud computing services are susceptible to attackers, since the physical resources are shared between VMs. The authors investigate current Amazon EC2 service thoroughly, verify the existence of the problems, and claim malicious attackers could take advantage of these rules and violate other’s privacies.

Contributions
1. Traditionally, to improve or find holes in the distributed system, one can go through the detailed design specifications to learn how system works. However, such specifications are not available to authors, since Amazon needs to keep it as confidentiality. Therefore, they cannot easily know the system configurations, and finding problem in such scenario becomes much harder. The first contribution comes from that the authors provides a detailed methodology about how they learn the EC2 system steps by steps through external experiments in a logical way. This is not a special problem they identified, but the idea how to study the system form external is non-trivial.
2. First, they found the topology of EC2, and this simple cloud cartography and mapping relation may led the attacker narrowed down searching scope. Besides, the providers might also want to hide their infrastructure information from outside, so they have incentive to complicate current cloud cartography.
3. Second, they propose two ways to identity co-residence of instances, and verify its applicability. Once attacker can successfully put malicious instances in the target instances within the same physical machine, they can use side-channel to obtain data from target instances.
4. Third, they show the sequential placement locality and parallel locality problem in EC2. This is great property if attacker want to install co-resident instance for a target instance. Random internal IP address assignment or virtual LANs can alleviate such problem.
5. Fourth, the authors confirm there is information leakage cross-VM. Attacker may use this hole to do the cache usage measurement, traffic rate estimation, and keystroke timing attacking. To overcome the side-channel attack, one may adopt blinding techniques to reduce the leakage.

Discussion and Application
This paper, as a pioneer, systematically inspected the problems in real platform Amazon EC2. The methodology of experiment they used is quite reasonable and applicable. For the third-party compute clouds, security problems needs to be addressed carefully, since no of us is willing to reveal our privacies to the public.

Summary
The author presents how feasible are cross VM attacks on the example of Amazon EC2. The authors examined how to achieve placement on same physical server allowing cross VM attacks. In adidtion to that they provided possible side channel attakcs and usage measurements using placements.

Description
Cloud computing is fast becoming popular as way to provide dynamically scalable resources. It is usually implemented as service providing virtual machine resources. A physical machine used as part of cloud computing runs many VMs. It may so happen that VMs doing work of two different companies might run on same machine.

Many cloud computing providers , under the assumption that VMs act as sandboxes, allow this. The authors show that, information used in one VM can be found by another VM on same machine, as they both use share physical resources.

Contributions
1) Provided side channel attacks in VMs.
2) Demonstrated the practicality of their attacks using Amazon EC2
3) Showed a way to infer availability zone and instance type by the difference in ip addresses belonging to different zones and enumerating public EC2 based web servers by externally probing them and launching a number of EC2 instances of varying types and surveying the resulting IP assigned.
4) Showed how to check Co-residence by matching Dom0 IP address, small packet round-trip times and numerically close internal IP addresses.
5) Showed how to achieve bettwe co-residence time by exploiting the tendency of EC2 to assign fresh instances to the same small set of instances
6) Gave prime + trigger + probe technique to measure cache usage by the victim
7) Used readily available tools for the attack.
8) Argued that such attacks can be used against any organising which multiplexes VMs.
9) Suggested ways to mitigate such attacks.

Flaws
Not sure how far their suggestion to give direct placement control to consumer would work to mitigate such attacks.

Relevance
The usage of cloud computing services is increasing at a fast rate.The paper is a wake up call to the providers to take a look into the security loop holes of their service.

Summary:
Paper examines recently popular cloud IaaS models wherein customers purchase compute resources on a need basis. Customers' VM instances potentially run on the same physical machine as an adversary's instance as the cloud owner multiplexes separate instances in a more efficient manner than one per machine. They study Amazon's EC2 specifically.

Problem/Goal:
Co-locating a target and adversary's VMs on the same hardware supported by a hypervisor can present new security threats. The authors wish to better understand the possible threats, their difficulty, and their criticality.

Techniques/Findings:
1) Cloud Cartography - Giving various parameters to new EC2 instances and observing (with network probing) any relation to resulting IP address of running VM. Found clear division of addresses for some parameters, and consistent patterns for others.
2) Co-Residence checks - In EC2, simply use address of a special instance called the Dom0 instance to determine co-residence. In general, can perhaps use packet RTT or IP address ranges (if cartography supports this).
3) Placement Strategy - when targeting a newly created instance, using knowledge of cartography, can launch just 20 attacker instances and achieve co-residence with target 40% of the time!
4) Also used some well-known cache-based side channels to get some coarse-grained info from target (traffic rates, keystroke timing, cache usage).

Contributions:
1) One of first cloud security papers. This is very important work to help (a) cloud providers start thinking about ways to improve security in the new model and (b) security-conscious cloud customers to understand the risks and to know what to ask of their providers.
2) Along with exposing threats, authors provided some mitigating techniques to at least make the jobs of attackers more difficult in the space.

Relevance:
Cloud computing is still popular and growing today. The low starting capital requirements to launch a new product, and ability to scale up/down with dynamic needs is attractive to startups and established companies alike (see Netflix).

Whether or not the particular techniques found in this paper are still effective in today's EC2, the main ideas of (1) hiding co-residence and (2) hardening systems to VM side channels will remain highly relevant.

Summary
The paper explores the security issues with cloud services. The main focus has been on how cross VM attacks can be used to gain access to confidential data. Amazons EC2 service was used to demonstrate the possible vulnerabilities.

Problems trying to solve
The EC2 service multiplexes disjoint virtual machines onto a single physical machine. The paper tries to find a way to improve its chances of placing a malicious VM in an advantageous position to be able to perform cross VM attacks on user.
Extract information via the cross attack.

Contributions
Location of an instance in a cloud infrastructure performed with the help of a map. The map is obtained co relating IP addresses with both availability zone and the type of address.

Determined if two instances are co resident on the same physical machine by comparing internal IP addresses of the two instances. If they are in the vicinity Check for a single hop on performing a TCP SYN trace route which yields the Dom0 IP address.

Showed that adversary can launch instances that will be co-resident with the user’s instance by using brute force placement and by taking advantage of placement locality.

Showed that an adversary can use side channels to take advantage of memory leaks in order to obtain gain access to confidential information.

Applicable
The use of cloud services is increasing fast thus defining security issues and pitfalls is essential in order to improve security of data. The paper has with the use of a real world system helped mitigate the issue.

Summary:
Thomas Ristenpart et. al. give a fresh perspective in security by addressing new possible vulnerabilities inherent in the “multi-tenancy” hosting strategy that is ubiquitous in the cloud. Their experiments, mostly done on Amazon’s EC2 service, show that these security risks do exist and can be abstracted to other cloud service providers. Also, there is discussion on what can be done as a cloud provider to minimize these risks as well as a cloud consumer.

Problems:
In the author’s threat model, a few new problems were brought up that expose some novel risks with cloud computing. Granted that a cloud provider is trusted and the application the cloud consumer is confidently secured, side-channels across virtual machines pose a new threat. A victim’s virtual machine could be residing on the same host as a malicious virtual machine and could leak sensitive information via any multiplexed shared physical resource. This could be as simple as a key logged password in victim’s virtual machine to complex cryptographic capture of RSA and AES secret keys. Before all this can be accomplished, however, the adversary must correctly share the host with the victim and verify it is doing so.

Contributions:
Besides the threat model already mentioned several other contributions were given in this paper:
• Covert Channels across VMs: It was demonstrated that two virtual machines can communicate without a network over physically shared, but isolated resources.
• Mapping out the cloud: Some unique techniques were used to determine the layout of VM hosts by type and IP address space.
• Obtaining co-residence in better than naïve time: Discoveries were made about the scheduling policy of new instances which could be exploited to more easily allocate a malicious VM on the same host as a victim’s VM. The solution discussed for this was having the cloud consumer decide placement of VMs, this strategy I disagree with as it could open up to a whole host of new risks from a game theoretical perspective.
• Verifying co-residence: Using simple network heuristics cohabiting VMs could be verified, but also more advanced strategies were described in case the network didn’t leak location data.
• Side Channels across VMs: The central risk detailed in this paper which described how two co-residing VMs could leak sensitive data across simply sharing a cache line. Unfortunately further practical advanced exploits weren’t given, but were for the most part purely theoretical.

Applicability:
This paper is highly applicable as most of the experimentation laid out was done on the very popular Amazon AWS EC2 service. Although several techniques were used that applied exclusively to Amazon, it is easy to see how such strategies could be used on other cloud services, such as Google Cloud Platform, Rackspace, and Microsoft Azure. Also, some of the suggestions given to cloud providers have been implemented since this paper was published. For example, Amazon now has Virtual Private Clouds where EC2 instances are run inside software-defined networks with isolated IP address space per account. Also, the simple trick to discover the VM host IP address has been turned off, so traceroutes no longer leak such information.

Summary

Cloud computing providers multiplex multiple tenant virtual machines on top of a single shared physical hardware. This paper shows how one can launch cross-VM side channel attacks by using intelligent VM placement techniques in Amazon EC2. Using side channel attacks, an attacker can gain confidential data from the victim's VM.

Problem

Popular cloud computing providers like Amazon EC2 and Microsoft Azure multiplex multiple virtual machines on top of a single physical hardware using a hypervisor software. These virtual machines are said to be co-located and can belong to two different tenants. Side channel attacks are known to be effective in stealing information from co-resident VMs. The authors show that they can map the provider's VM placement strategy, co-locate a malicious VM with a target victim VM and launch cross VM side channel attacks.

Contributions

0. Sheds light on new class of vulnerabilities that are possible in commercial cloud provider platforms.
1. I think this work was the first to introduce the notion of a "Cloud Map" - i.e., insights into how cloud providers partition their IP range. Their hypothesis that different zones and different instance-types have different IP ranges was intuitive.
2. Co-residence checks that use network measurements. It is surprising to note that cloud providers don't disable traceroute and similar tools for Dom0.
3. The placement techniques for co-locating a malicious VM with a target VM with a success rate of ~50%.

Relevance

With increase in people using cloud computing platforms, it is really important to think hard about cloud security. This paper sheds light on a new class of vulnerabilities possible in the shared cloud infrastructure. I feel this work is really a great step towards addressing security challenges in cloud. It would be great to know how Amazon and other cloud providers reacted to this work.

Summary: In this paper, the author discuss one security
issue of "cloud computing" provided by third party
providers, and use Amazon's EC2 as an example. The
observation is that by taking advantage of the
fact that different VMs could be executed on the
same physical machine, side-channel attack could be
conducted.

Problem: The author asked four questions that spans
systematically in the topic that they want to study.
First, the feasibility of detecting location; Second,
the feasibility of detecting co-location. Third, the
feasibility of achieving co-location. Forth, the
feasibility of side-channel attach after co-location.
Given these four questions, the user conducts
study for each of them using interesting experiments
on EC2.

Contributions: In my opinion, the observation about
the feasibility of side-channel attach on today's
cloud infrastructure is interesting. The study is
conducted in a way that is so systematic and I really
enjoy reading it.

Technically, the author points out that the regularity
of location for different EC2 instances with IP as
indicators for both detecting current location, finding
candidate zones, and detecting co-location. Also,
the author discovers the temporal locality of
assigning VM to different physical machines. These observations
are novel, and important for third-party vendors
to take advantage of to further improve the security of
their service.

Conceptually, I think one important point raised by the
author is that today's cloud computing trend provides
novel ways of attacking that has never been seen before.
This conceptual point is a great observation in my opinion.

Applicability: The proposed approach relies on
the fact that different VMs could be run on a single
physical machine, and the hypervisor of VM directly
shared CPU. Therefore, there are at least three limitations.
First, for reserved instance on EC2, the attacks cannot be
conducted, which is arguably more popularly used by serious
commercial users? (This is just my personal opinion without
any validation)
Second, for more powerful instance, the chance of co-location
would decrease, and therefore, the proposed attack would
be harder. Third, the assumption based on the VM hypervisor
can be fixed by techniques like hardware-level visualization.
Despite these limitations, I really like this paper, and I
think the conceptual point it draws if much more important
than its real-world applicability.

Summary
In this paper authors has shown some exploits in current popular could service, where an attacker can guess the physical location of its VM as well as fuzz the system to achieve a co-location with some other target VM. They used network look up as and some reverse engineering of Amazon EC2's VM hosting algorithm as well as local IP providing algorithm to build the exploits. The authors have stated that with 40% probability they were successful in placing their "malicious" VM with targeted VM!
Problem/Goal
Map the cloud infrastructure and determine the VM's physical location. Determine co-location of two VMs. And last but not the least, can one fuzz the system of VM allocation to be able to launch an instance in solicited target (specific or any) VM's physical location.
Contribution

Summary:
This paper introduces the new vulnerabilities brought by third-party cloud computing. Using the Amazon EC2 service as a case study, the paper shows that it is possible to locate the target VM and create VMs co-resident with the target VM, which can be used to mount cross-VM side-channel attacks.

Problem:
In cloud computing, multiple VMs may be simultaneously assigned to execute on the same physical server. In this case, a customer's VM can be co-resident with his adversary's VM. This introduces the possibility of cross-VM attacks.

Contributions:
Cross-VM attacks include two steps: placement and extraction.
(1) Placement: The authors show that the cloud's infrastructure properties can be used to achieve co-resident placement. They observe that servers (of EC2) from each zone are assigned different portions of the internal address space and they get a map of EC2 to infer the instance type and availability zone of any public EC2 instance. The matching Dom0 IP address, small packet round-trip times and numerically close internal IP addresses help to determine co-residence. They also propose a more efficient load-based co-residence detection. Two adversarial placement strategies are introduced including brute-forcing and a policy that can abuse placement locality.
(2) Extracting: The authors provides examples of cross-vm information leakage including stealing cryptographic keys, use of other channels, measuring cache usage and so on.

Applicability:
Back to the 2009, this paper seems to be one of the early papers paying attention to cloud security and giving experiments on a real cloud plaform (Amazon EC2). I can not deny its applicability because it points out the real security problems in real cloud computing platforms. But I don't think the security responsibility should be mainly on the users. Besides the cross-vm attack, there will be other security problems. The cloud service providers should provide a secured system which can solve most, if not all of these problems systematically.

Summary: The author propose the vulnerability of cloud computing platform, mainly the leaking of the victims information to the attackers with instance on the same machine. The author showed by experiment on Amazon EC2 platform that by utilizing the vulnaratiliby of virtual machine and the physical machine assignment algorithm of the platform, an attacker can determine the physical machines the victim is using, co-reside the machine with the victim, and then extracting the information from the victim. The author also discuss several possibility of defenses, e.g. randomizing the machine assignment.

Problem: Cloud computing is a next generation infrastructure and business model that hosting data, outsourcing software and service. However, security concern comes with the efficiency of cloud computing: the sharing of data and task on one physical machine may make the leaking of user information. These information includes the user's password, the workload of user's tasks and so on. Study the capacity and limits of such attacks and then ultimately design corresponding defense method is very compelling.

Contributions:
(1) The author determine the physical machine mapping to types of instances on Amazon EC2 by experiment on multiple instance deployment. Basically, the zones (selected by user) and the types of the instances correspond to different intervals of internal IPs.

(2) Based on the mapping, the author provide the method to check the co-residence on the physical machine with the target instance. The small packet round-trip method works well. The proposed possible defense is to make the response time random.

(3) Based on the co-residence check, the author design the deployment algorithm of instances to make most victim's instances are co-located with attacker's instances. The deployment algorithm utilizes the mapping and the locality of the assigned instances (prefer to assign to the same physical machine for time close instance requests).

(4) Once the attacker successfully co-reside with the victims. They utilize the well-studied side-channel attacks to extract the cache usage (monitor compute load), the network traffic rates, and the keystroke time. These information seems to be tiny but may lead to significant damage on the victim.

Application:
This paper is a pioneer concerned with the security of cloud computing on the real platform. It is published in 2009 and the citation surged to around 900 (by google scholar) with the widely deployment of cloud computing. I really like the experiments on real platform in this paper. These experiments directly show the vulnarability of the current cloud computing platform and the suggested defense metheds are quite applicable in the practice.

The paper discusses about the various information security risks that can occur as a result of outsourced third party cloud computing. The authors discuss in detail the experiments that they carried out to expose the various cross VM attacks that could occur in a multi-tenant cloud computing infrastructure and also suggest that the foolproof solution is to give the customer the choice of the placement of VM’s in the cloud.

Contributions :

1. They performed a couple of experiments on Amazon EC2 so to get a sense of the cloud cartography and the heuristics derived from them were used to deduce that the IPs were assigned to the available zones and instance types in a certain pattern.
2. Another major analysis was that of the co-residence check. Experiments helped them conclude that the matching Domain0 IP address residence check was accurate.
3. They were able to exploit the parallel placement locality patterns by resorting to instance flooding instead of a naive brute force strategy and exposed the risk of high co-residence. They had observed the dependence of various instance parameters like zone, account and time of day on co-residence while carrying out their trials.
4. They have also demonstrated these experiments with the commercial instances like RightScale and rPath on Amazon EC2.
5. The vulnerability of the instances to cross information leakage is exposed by experiments that use side channels to learn information about the victim instance. The cache usage measurement is used as a prime measure in the techniques employed for most of the attacks.
6. Using the Prime-Trigger-Probe technique, they showed that the attackers could detect co-residence and also estimate the traffic to a particular service on the victim instance. The same technique was also used to expose keystroke timing attacks on a testbed.
7. They propose a couple of solutions like preventing co-residence checks and using blinding techniques to reduce side channel attacks.

Relevance : Multi-tenant cloud computing infrastructure is quite common and prevalent these days. This is a very good analysis of what kind of cross VM attacks could occur when multiplexing hardware resources between multi-tenant VM’s. The paper gives us a few solutions to tackle these problems but most prominently, they indicate that at the cost of under-utilization, the choice of the placement of VM’s could be given to the users to avoid such risks.

Summary:

Third party cloud computing providers such as Amazon EC2, Microsoft Azure provide resources for customers to host their servers in the cloud. But the service providers partition the systems as virtual machines on the same physical machine and a cluster consists of lot of such machines. This paper tries to point out the security vulnerabilities when an attacker wants to get hands on a victim machine, if the attacker was able to run his instance of VM on the same physical machine as the victim's VM. The paper tells us about different methods used to create a coresident VM in Amazon EC2. EC2 service runs a xen hypervisor over the physical machine which runs different VMs of the customers. Every physical machine has Domain0 virtual machine, which actually maintains the images of different VMs and also routes the packets to and fro from the machine. The allocation of VMs depends on three degrees of freedom: Region - geographic region where the service is located, Availability zone- The partitions which have separate power and network connectivity, instance type - which determines the processor, memory and storage. The paper also talks about external and internal network probing to identify the external and internal Ip addresses using hping, traceroute and nmap. Using all these tools, the paper could develop a cloud cartography of VMs placement. An important observation from this cartography is amazon issued IP addresses in the same range for the machines in the same availability zone. And the authors could able to develop a map of zones to IP addresses. The authors proposes some ways to make sure the attacker VMs is resident on the same machine as target's.

Techniques:

1. The Ip address of the Dom0 VM can be found from the instance VM first hop address and also can be verified using last but one hop of the receiving machine's Domo VM if they are both in different machines.
2. They also have a covert channel VM check, where the two VM instances one which reads from the same location and one which seeks randomly. By observing the read times of the same read VM by controlling the other VM we can make sure that both VM instances are co resident, if they have same Dom0 VM IP.
3. By brute force placement logic, the authors proposes that selecting a target machine and using the map they just created they will create a large instances in the same zone to increase the probability of getting a co-resident VM as the target.
4. The paper also proposes a parallel placement locality followed by Amazon, in which two VM instances created contemporaneously gets the same physical machine. Thus by increasing the load on the target VM when in the auto-scaling mode, they create instances to increase the chances of coresident VMs.

Applicability:

1. Thus the paper brings out the possible vulnerabilities in such a cloud computing platform, thus asking the providers to make the security much better.
2. The providers can easily prevent the network based co-residence checks, and can minimize the info leaked on placement policy and such.

Summary:
The paper explores the vulnerabilities in third party cloud computing services that might help an attacker to gain useful insights about the targets. In specific the authors experiment on Amazon EC2 service and demonstrate how an attacker could map the cloud infrastructure and identify the target existence and then use cross-VM side-channel attacks to gather information about the target. The authors also propose some of the measures that can make these attacks more difficult to be achieved.

Problem:
Third party cloud computing allows the flexibility of obtaining required computational power on the fly at affordable price also and avoids the need for maintaining the infrastructure. The main issue the users face is the trust with the cloud service providers in terms of privacy and security. Although the service providers ensure integrity, there exist vulnerabilities as shown in this paper, that need to be identified and countered. It is non-trivial how the attackers can target victims by co-existing on the same physical machine.

Contributions:
• The authors make an interesting approach to formulate the cloud cartography. They show how the IP addresses can correlate to the availability region and the type of machine requested by the user. They then suggest that using dynamic IP addresses can help alleviate this issue.
• The experiments illustrate how the network based approaches can be used for co-residency checks. Co-residency can be correlated by matching Dom0 IP, evaluating roundtrip times and checking for IP address proximity.
• Even simple placement techniques such as brute force method can make it possible to run on the same machine as the victim. Although it is probabilistic and requires huge trials, the likelihood increases with techniques such as using placement locality.
• Once the co-residence is confirmed the attacker can gain information about the victim by cross-VM leakage. Measuring cache usage and load detection on the physical machine provides information about the behavior of the victim, its performance and activities.
• It’s also interesting to see how such information can be useful to the attackers in commercial cases. The paper gives examples to illustrate this, at bare minimum the attacker can gain information about the activities and patterns of the competitor and use it to advantage.
• The authors give recommendations to avoid cross-VM attacks and suggest that the best measure would be to avoid co-residence, which again requires efforts.

Applicability:
I think the work presented in this paper is recent and very applicable today. The authors have clearly shown the vulnerabilities in one of the biggest cloud service providers and the concepts would most likely hold true for other service providers too, may not be exactly same. As more and more users are resorting to cloud services it is quintessential to analyze such vulnerabilities and come up with measures that can assure the users of the service integrity.

Summary:

In the paper the authors analyze and exposes the vulnerabilities associated with third-party cloud-computing services such as Microsoft's Azure and Amazon's EC2 which uses visualization for security, isolation among virtual machines and utilization of a single physical machine (by sharing). The authors demonstrate the practicality of such vulnerabilities using experimental analysis on EC2. In addition, the authors provide discussions on defenses a cloud provider might try in order to prevent such attacks.

Problem:

If a victim’s VM is placed on the same physical machine as that of the adversary, the adversary can penetrate the isolation between VMs and mount cross-VM side-channel attacks. Any attack consists of two parts: placement of the attacker’s VM on the same machine as that of the victim and to make use of the shared resources to extract confidential information. The author talk about placement and teh fact that an attacker has a very good chance of achieving co-residence with the victim. After successfully placing the malicious instance on victims physical machine the adversary can measure computational load of co-resident instances using time shared caches. This information can be used by the adversary to perform malicious activities like co-residence detection without relying on the network, mounting keystorke timing attaches and detecting web-traffic rates of the co-resident web server.

Contribution:

• Given the time this paper was published it was a pioneer in exposing threats and vulnerabilities in cloud services.
  • It's a good head-up for cloud providers so they can provide much more secure services to their users.
  • Also the users are made aware of the risks they are exposed to at that time.
• The practicality of the potential threats were successfully demonstrated on Amazon's EC2.
• Potential measures were suggested to mitigate such attacks and slow down the attacker.

Applicability:

This is one of the pioneering papers in cloud security and is high cited(924). The ideas presented in this paper are very relevant today is very important for cloud providers and consumers.

Summary: Paper discovers a delves into a potential security problem with public compute clouds. They show that it is easy for an adversary to get VM co-residence with a target VM. Achieving that, they show a variety of side channels and exploits that an adversary could employ.

Problem: Public compute clouds like Amazon EC2 and Microsoft Azure are becoming more prominent as a way for users to have access to compute resources. Since these cloud computing companies want to make efficient use of their compute resources, they multiplex the physical resources among multiple tenet VMs. This presents a problem. Given that cloud compute companies can generally be trusted, an adversary can take advantage of the multiplexing of physical resources and get their malicious VM onto the same machine as a target and exploit side-channels to learn privilege information.

Contributions: The main contribution of this paper was describing the different layers of vulnerability that allows adversaries to access privileged information.

First, they show that Amazon EC2's infrastructure can be mapped. EC2's availability zones within a region are easily partitioned into distinct IP address spaces. Thus, they can deploy instances of VMs within a region that a target is. This means if they know what the IP address of a target is, they can know what zone that target resides. Second, they show that the actual VM instance type (small, medium, etc.) take up specific portions of the IP space within a zone. Finally, they show that the Dom0 IP address is an excellent indicator with regards to whether a VM is co-resident on a machine.

They show that if the adversary can start instances at around the same time as the target, they can get 40% of their VMs to be co-located with the target. Given that co-location is easy, they show there are side-channels to abuse to gain access to information such as traffic statistics of the VM, which a competitor may use for nefarious purposes. Finally they present a key-stroke timing attack that a adversarial VM could use if they are assigned to the same CPU core of the target. All these side-channels relied on the cache access times, which are hard to prevent without making the assumption that all side-channels are blocked (not good). They suggest that tenets should have control over the placement of their VMs to get around the network agnostic way of finding co-location.

Applicability: The paper presents very real security flaws within a public compute environment. They show that it is easy to get a VM on a target machine and suggest ways that the provider can combat a potential adversary. For the most part, the changes that the paper suggests would be easy to implement and just present administrative hurdles to overcome.

The only hitch is that it relies on the administrative effort (giving greater control of placement to tenets for their VMs) to not outweigh the actual threat of the vulnerability. That means that enough tenets would want to have extra privacy in order to make the cost worth it. If all the tenets accept the risk, then the cost for ensuring extra privacy might be higher per tenet and that might be a “catch-22” situation for implementing such a change. Otherwise, all the ideas in the paper seem to be spot on.

Hey, You, Get Off of My Cloud

Summary:
This paper presents the different security issues that are present in Cloud Computing, taking Amazon's Elastic Compute Cloud as an example. The problem it showcases are that it is possible to map the internal cloud infrastructure, to identify the location of a target VM and to place VMs along with the target and introduce some potential cross VM information leakage.

Problems:
The physical resources being shared among virtual machines is the root cause for the security issues that can arise in the cloud. Since multiple different users can share the same physical machine, the attacker can make sure that his VM is placed in the same machine as his target.

The authors introduce a threat model in which placement and extraction plays an important role in attacking a target. Using this model the authors showcase how easy it is for an attacker to colocate his VM with the target VM and to perform some side channel attacks.

Contributions:
1. The first important contribution of the paper is to expose the security threats that are possible in a cloud computing environment.
2. Mapping the EC2 Cloud was another contribution of the paper since this formed the basis for understanding where exactly a target VM is placed in the cloud infrastructure.
3. The ease by which the authors determine the co-residence of 2 VMs in EC2 using Dom0 IP address, RTT and the closeness of internal IP addresses points out that it is easy to hack the cloud infrastructure with some advanced networking backgroud.
4. The final contribution of the paper is the ways they suggest to mitigate these security threats like using dynamic IP address allocation, preventing the identification of Dom0, allowing users to decide where their VMs are to be placed, etc. More importantly the authors have concluded that it is not possible to provide complete security within the cloud !

Relevance:
Cloud Computing is so popular nowadays since people want to pay for software and hardware only for the duration that they want to use and they don't want to worry about the various issues is maintaining such an infrastructure. In this scenario where many people of moving their services to the cloud, it is very important to make sure that the cloud they are using is secure. Therefore the problem this paper points out is so relevant during this time and it's also important to address these issues with utmost care.

Summary:
The paper talks about the threats of muti-tenancy in a cloud computing setting i.e how shared physical infrastructure can be leveraged by attacker to penetrate into targets VM and access confidential resources. Main steps involved in attack are: correct placement of attacker with the target and extraction of information.

Problem:
Multiple VMs are executed simultaneously on the same physical server to maximize efficiency. Cloud vendors generally place disjoint customers to gain efficiency and hardware utilization. Malicious VMs can manipulate underlying hardware and extract information from target. The paper talks about how to identify cloud service providers mapping/placement strategy and leverage this information to place malicious VMs next to target and carry out cross-channel attacks.

Contributions:
1. One of the first work in Cloud Cartography. The paper talks about techniques to map the cloud infrastructure to find where the target is located.
2. Various heuristics to determine co-residence of two VMs like matching Dom0 IP address, small packet round trip times, numerically close internal IPs.
3. Exploit Cross-VM leakage to gather information about target.
4. Provides countermeasures to prevent cloud cartography, co-residence checks, placement abuse and side-channel attacks.

Applicability:
Security in the cloud is a very hot topic. The paper highlights various security loopholes in the cloud infrastructure and suggests solutions for them. I am not fully convinced with the idea of a dedicated physical machine per customer service as it defeats the purpose of cloud and increases cost too. The paper seems to be have been really influential as it has been cited by 920 publications (source: Google Scholar) since it was published in 2009

Summary:
This paper explores the possibility of placing a “malicious” virtual machine co-resident to a target virtual machine in the cloud; specifically Amazon’s EC2 environment is explored. The paper demonstrates the possibility and goes on to explore the efficacy with which this can be accomplish using the few configurable parameters exposed to a user when booting an EC2 instance. The paper also discusses possible side-channel attack vectors when the virtual machines are co-resident.

Problems:
- The main problem that the authors attempt to solve is simply an answer to the question of “Is it possible to (with decent accuracy) place a virtual machine (under an attacker’s control) co-resident to a specific target virtual machine (or group of virtual machines)?”.
- The above problem is addressed by solving the problem of physically locating the target virtual machine and then having a means to determine that a deployed “attack” machine has achieved co-residency with the target virtual machine.
- The second main problem the authors explore is whether placing a controlled virtual machine co-resident to a target virtual machine exposes it to possible attack vectors (e.g. side-channel timing attacks) due the use of shared hardware.

Contributions:
- The authors build a system to map an public IP address to an internal private address within the EC2 environment. This is useful as it allows a target virtual machine to be mapped simply with it’s publicly facing IP.
- The authors demonstrate a simple method to determine co-residency. This method is to simply inspect the first hop a packet takes leaving a virtual machine. Since each VM on a physical server shares a hypervisor they share a virtual network card termed Dom0.
- A straightforward strategy for deploying a virtual machine that will be co-resident to the target virtual machine.
- Demonstration of the efficacy of a side-channel that could be exploited by two virtual machines that are co-resident. This part was not tested on the actual EC2 environment.

Application to Real Systems:
As the authors actually demonstrate this in a live production environment (name Amazon’s EC2) which is used by millions of customers, they have shown this a real possibility and therefore a real vulnerability. As there is literature demonstrating attack vectors possible when two virtual machines are co-resident this is a serious risk. Their suggestion to mitigate this risk is also simple, straightforward, and fits nicely into a product model (i.e. pay more to running on dedicated hardware).

Summary: This paper demonstrates the vulnerabilities of popular cloud computing services such as Amazon EC2. They show that with reasonably high probability it is possible to place malicious instances to be together with the target service, and further do harmful things to the target.

Problem: Cloud computing is popular nowadays, but there is less research done on the security aspect of cloud computing. This topic is very important because such cloud applications usually involve sensitive data such as encryption keys. So the problem is, given the current popular cloud services, is it possible for attackers to steal sensitive data or do harm to any targets chosen by attackers? If the answer is yes, what can we do to prevent this from happening?

Contribution:
1. Demonstrated that it is possible for attackers to determine whether two instances are co-residents. Cloud service providers usually multiplex their physical machines for the best profit. The authors proposed a method based on IP address and network latencies to decide whether two virtual machines are located on a same physical machine. This enables them to devise a method to purposefully place one malicious instance on the physical machine of the target.
2. Proposed a method to place a malicious instance together with the target. Though the distribution of virtual clients seems random and chaotic, the authors showed that actually clients with similar configurations and zones are located in same physical regions. Based on that discovery, they first proposed a brute force method to place the malicious client with the target. The brute force method actually had already worked reasonably well. Then then proposed a better algorithm that based on locality. They observed that if a client started right after another client's departure, then it is very likely that the second client will take the place of the first client's machine. Based on this observation, they can start many concurrent client after it is detected that the one of the targets has just departed.
3. Discussed the possibility of cross virtual machine information leakage. They showed that information like cache usage can be leaked to other instances on the same machine. Though these side channel leakages seems useless, they showed that they can be used to implement a robust co-resident detection (without making use of network properties), web traffic detection, even timing keystrokes.
4. Proposed methods to alleviate or solve these issues. Random IP address assignment can be employed to prevent co-residence detection based on IP addresses. To prevent malicious co-residence placement, cloud services can give users a choice how to reside their virtual clients. For example, the user can choose not to share physical machines with virtual clients from other parties.

Applicability: This work is not very practical because even though they may be able to co-reside with the target, there are still not much can be done because of the virtual barrier and hardware limits. Moreover, none of these exploits are fundamental and they can be fixed rather easily.

Summary:
This paper presents the security issues associated with third party cloud computing like Amazon EC2, Microsoft’s Azure etc. Though there are numerous advantages to the cloud providers in terms of resource utilization and money they are paid, there are some security threats which the customers are exposed to and this paper analyzes one such threat (cross VM information Leakage). The authors clearly explain ways to zero in on a machine which contains the target VM and how the adversary VM manages to extract confidential information from the target VM.

Problem:
The problem they are highlighting is two VMs that are co-resident on the same physical machine are not completely isolated from each other. With cloud providers like Amazon EC2, their infrastructure is vulnerable to such attacks, where an attacker could easily figure out where in the cloud is the victim’s virtual machine hosted.

Contributions:
1. Drawing the map of the entire cloud using known networking calls like hping, trace route and wget.

2. Using the cloud map in order to zero in on the availability zone and instance types. The various heuristics the authors had developed and proved like 1) instances of the same availability zone would map to same range of IP addresses and 2) instances of same type would have the same range of IP addresses , helped to increase the possibility of placing a adversary VM co-located to a target VM very quickly.

3.Employed various methodologies to check co-residence. Other than matching DomoIp address, they also verified the correctness of these checks via an experiment that uses hard-disk based covert channel.

4.Exploiting EC2’s property of placement locality (sequential vs parallel). Combining this with instance flooding, they were able to achieve a placement same as that of the victim’s virtual machine.

5.Using prime- probe technique to measure how caches can be used as a covert channel.

Limitations:

1. Under the usage of cache as a covert channel, there could be a possibility that the cache could get wiped out by some other VM and not necessarily the victim VM.

2. Under hard-disk based covert channel, any in-between disk seeks could have also caused the increase in latency.

Applicability:
I am not sure how far these issues still exist in Amazon’s EC2. Though the paper was published few years ago, it clearly explains how a cloud service could not be completely transparent to the user.

Summary:
In this paper, the author shows that new vulnerabilities are introduced in the current popular third-party cloud SaaS provider. Taking Amazon EC2 as the study case, several concrete problems are proposed to demonstrate such vulnerabilities really exist.

Problem:
The use of virtualization on cloud allow third-party cloud providers to maximize the utilization of their underlying infrastructures. But multiplexing the virtual machines introduces the potential risk that adversaries could penetrate the isolation between VMs that locate on the same physical machine. The concrete problems are:
1. can one determine the location of VM
2. can one determine if two VMs are on the same machine
3. can one launch the instance to be co-resident with others’
4. can one get the leakage information once co-resident.

Contribution:
1. Getting the fuller map of EC2 via WHOIS tool which maps internal IPs to different zones and regions. This reveals that hidden cloud cartography can be inferred from the outsides.
2. Proposing a co-residence detection algorithm.
3. Exploiting placement strategy. Two different attack strategies are used to exploit the location information of each instance. The one abuse placement locality is really neat.
4. Discussion one several possible scenario that malicious user utilize side channel, like stealing cryptographic keys, gathering statistical information from physical machines.

Applicability：
As cloud computing and cloud storage become more and more popular, the cloud security problem is the one of the major issues that accompanies with the development of cloud computing. The exploit methods proposed in this paper are effective ways to determine current design of cloud services and underlying infrastructure are secure enough, or in other word, trustworthy enough for user.

Summary:
In this paper authors have explored new vulnerabilities introduced due to the shared physical resources in third party cloud computing services (like Amazon EC2). They have demonstrated that it is possible to map internal cloud infrastructure, which can be exploited to place malicious VM on same physical machine as other VMs, thus exposing the other VMs to several side-channel attacks.

Problem:
Cloud services providers place VMs of different users on the same physical hardware, to achieve efficiency and hence offer cheaper services to users. However this could lead to new vulnerabilities not possible in non-shared physical resource setups. Here authors aim at finding out:
- Is it possible to penetrate the isolation between the VMs and target a co-resident user on the same physical machine, leading to compromise of security of user's data.
- If it is possible, how practical are the steps needed to deploy such an attack.
Authors have focused on Amazon EC2 as a case study for such type of attacks.

Contributions:
- The primary contribution of this paper is the changing of the threat model for cloud servers. Previously, people seemed to assume that shared resources, when virtualized, could be treated as if they were perfectly isolated (e.g., perfect virtualization). However, shared resources can still fall victim to side-channel attacks and DoS attacks.
-Cloud cartography - Authors have shown how using the properties of the cloud’s infrastructure (in this case limited to Amazon’s EC2) to discover the internal layout and even the location of a specific target.
-Revealing the VM placement policy of cloud providers, in this case Amazon EC2.
-Strategy to achieve co-tenancy with target VM on the shared physical server with high success rate and in an economically feasible way.

Flaws:
I wonder the approaches mentioned for mapping and attacks is general to all cloud service providers, since some of the steps for identifying co-residency relies on the behavior of Xen hypervisor where Dom0 acts as a privileged VM and manages other instance VMs.

Applicability:
Authors have shown, that the steps needed to deploy such an attack is practical and economically feasible. With cloud services being highly popular, the paper provides a word of caution to the cloud users and the providers alike. As data security being one of the primary concerns of the users, it will interesting to see what steps did the cloud service providers take, since this paper was published, to allay the concern of the users.

Summary
This paper discusses the security implications of using a shared cloud environment. They show that an attacker could effectively make a VM a co-resident with a target, and may possibly extract information from that service.

Problem
This paper focuses on how an attack may be carried out. In that sense, the problem is simple - how to extract information from virtual machines in a cloud environment. There are several parts to this, including: determining where an instance is located, creating instances that co-reside with a specified instance, deciding if two instances are co-residents, and exploiting the shared nature of the cloud environment to extract information about the other VMs.

Contributions
This paper has a few contributions. One of the first takeaways for me was that since the network inside a data center is a fat tree, the internal IP address shows where a server is located inside the data center (logically). Thus, an attacker can exploit this information to find out where a VM might be running. Based on this, it is entirely possible for an attacker to co-reside with the target based on this information.

The next takeaway is that even though the cloud has separated out the machines into VMs, their separation is of course not total. That is, an attacked could extract information about other VMs on the server. This is mainly just using probing techniques, that utilize the shared hardware. The big takeaway is in their conclusion - that the cloud environment may never be totally secure.

Discussion
The fact that security concerns might be worth paying extra money for (as described in the conclusion) is very interesting, because it brings in more questions. Is better security worth worse performance? Lower memory utilization? Higher latency or increased packet size? Often we look at distributed systems in terms of these different values, but there are tradeoffs here as well. Of course it is application specific, but distributed systems are especially likely to be attacked since they have, by definition, a greater attack surface.

Flaws
The only problem I have with this paper are the many assumptions they make with their workloads. For example, many of the attack vectors and detection mechanisms work best when there is little or no load on the machine. But this seems an unlikely scenario in a heavily used cloud environment. It is not in Amazon's interest to have a machine with no load, with so many users complaining about "noisy neighbours".

Summary:

The paper describes security issues that arise in cloud computing environments when VMs of two different applications reside on the same machine. It describes techniques to maximize the chance of VM co-location and methods to extract confidential information across such VMs.

Problem:

Cloud computing services multiplex untrusted applications on the same physical machine. The assumption is that the underlying distribution of VMs is invisible to the customer, and that VMs are sandboxed to prevent any VM from being aware of the context within which it is running. Both these assumptions are false, and this causes security issues.

Contributions:
- Determine the parameters that are used to control placement of the VM with a reasonably high accuracy which allows them to do cloud cartography.
- Deduce and verify temporal placement strategies to maximize the chances of co-location.
- Multiple techniques to confirm co-residence.
- Covert side channel techniques that break the sandbox that the VM is supposed to run in.
- Potential solutions to problems mentioned above.

Limitations:
- Although the paper alludes to potential major security issues that might arise due to cross VM side channels in other papers, the only evaluation that is conducted by them for information extraction is across co-operating VMs.
- Techniques seem fairly fine tuned to EC2's strategy. Not sure if this work would be broadly applicable with the exception of few techniques.

Applications:
- The fact that someone could co-locate VMs exposes an entire attack surface in case VM sandboxes are compromised. Customers who do not want to take this risk should be able to opt for having their own machines (at a premium).

Summary:
This paper analyzes the different security risks that a cloud service providing virtualization, like Amazon EC2, can potentially face. The authors have performed a very neat set of experiments to establish the vulnerability of these services and they come up with solutions to avoid these.

Problem:
In a distributed cloud service like EC2, to reduce cost and improve efficiency, virtual machines belonging to different customers may be multiplexed to the same physical hardware. Moreover, VMs may be simultaneously assigned to execute on the same physical server. Because of this, it is possible to (as shown in the paper) place an attacker's instance on a machine, and identify co-residing machines easily. Therefore, the attacker then can extract information from the target through cross-VM information leakage. The authors are trying to show the many ways this can happen in and then provide a solution to this.

Contributions :
* One of the main contributions of the paper is to pinpoint all the security loop holes in a service like Amazon EC2 that can be easily exploited by attackers.
* The authors explain how an attack can take place. First, the attacker launches instances that are co-resident with the target instance. Then, the attacker can find out data access patterns and such to slow down the system potentially and so on.
* Taking EC2 as an example, they have clearly stated how IP addresses are assigned for every instance. Since this is done statically and there is a range of IP addresses for each region and zone and type, they show that just by brute force they are able to hit the right target machines with a success rate of 8 percent!
* They also continue by exploring the sequential and parallel-running instances assignment to a server and show how these can be exploited to attack targets.
* The tests done on the EC2 server are very neatly explained and I personally feel that they have covered every kind of attack possible. The results showing that they could find a target machine with about 40% success rate by instance flooding made me think how easily co-residing nodes could be detected in the cloud through network.
* Finally, the authors propose a solution to avoid these attacks, which is to leave it up to the user to decide the location of his instance and not decide it for him.

Applicability:
This paper basically points out all the ways in which a cloud service can go wrong. Since this technology is growing a lot these days, this would be very useful for engineers to design a secure system. I would like to learn more about how and if services like Amazon EC2 ended up making their system more secure after these experiments.

Summary
Renting compute in the cloud comes with several advantages, such as the ability to scale with demand, ease of provisioning and configuration, and avoiding having to maintain the hardware and the interconnectivity. Services such as Amazon’s EC2, Microsoft Azure and Google’s Compute Engine make it easy and cost effective to spin up VMs that can be rented out. From the provider’s standpoint, such a system is made feasible by hosting multiple virtual machines on underlying shared hardware through a hypervisor. This paper looks to examine the threats that exist in such an environment and provides insight into potential solutions that avert these threats.

Problem
When VMs are spun up on the cloud, users could perceive them to be run in isolation of other VMs, almost in a sandbox, providing the perception that it runs in relative anonymity on the provider’s infrastructure. What the authors show is that not only is it possible to map the provider’s placement strategy, but also identify and co-locate with a potential target and administer cross channel attacks on it.

Contributions

• Cloud Cartography : The authors demonstrate the ability to map ranges of IP addresses to target VM types, to effectively narrow down the configurations that an attacker would have to deploy to collocate with a target. This also provided some insight into how EC2 internally partitions its IP address space.
  


• Provide a mechanism to “quietly” identify colocation with a target VM. This is significant in the sense that even without smart collocation strategies, one could brute force their way into collocating with a sufficiently a large target set.
  


• Identify a means to achieve co-tenancy with a target, based on the placement strategy used by EC2, with a near 50% success rate, and using this co-tenancy to perform cross channel attacks on targets.
  

Applicability
Given that this paper was published, and provided what resembles a WikiHow page on how to prep an attack on a target hosted on EC2, I’d be interested in learning about what has changed since this paper was published, and which of the solutions described (or others outside) have been adopted to inhibit such attacks.

Summary:
This paper discusses a kind of vulnerability of cloud computing: when the malicious VM instance residents in the same physical machine as the target VM instance, the malicious VM instance can launch attacks to the target VM instance by utilize cross-VM information channel. The paper also explains the strategy that the malicious VM instance can use to achieve high success rate to launch the malicious VM instance on the same physical machine as the target VM instance. Several attack examples are discussed in the paper. The authors propose to offload the placement choice to users in order to improve the security of cloud computing.

Problem:
Cloud computing vendors place the VM instances from different customers to the same hardware infrastructure in order to improve hardware utilization and efficiency, it’s possible for VM instances from different customers to resident on the same machine. It’s easier for the malicious VM instance to attack the target instance if they reside in the same physical machine because the malicious VM instance can manipulate the same hardware resource as the target VM instance. Cloud computing vendors’ strategy to place VM instances is regular, that can be used by attackers to get the information about the placement of the target VM instance and improve the success rate to launch the malicious VM instance on the same physical machine as the target VM instance.

Contributions:
The feasibility to identify the target VM instance’s placement information by testing and probing. Internal IP address assignments are regular on availability zones and instance types.

Based on the information of the target VM instance (availability zone and type), attackers can launch numerous instances with the same type in the same zone to achieve 8.4% coverage of the target rate. With abusing placement locality, the coverage rate could be further improved.

The accuracy of determining co-residence by network-based co-residence checks is very high. The authors confirm the accuracy of the checks by the ability to send messages over a cross-VM convert channel.

The authors also discuss several examples of cross-VM information leakage, for example, the time-shared caches allow an attacker to measure when other instances are experiencing computational load, such information is very useful for clever attackers.

Discussion:
The authors claim that the best solution to the cross-VM information leakage is simply to expose the risk and placement decisions directly to users. The users need high security might insist on using physical machines populated only with their own VMs. This suggestion is useful before we can mitigate the risk that attackers can deliberately place malicious VM instance on the same physical machine as the target VM instance and launch attacks by leverage cross-VM information leakage.

Summary:
The paper presents the techniques to attack a target VM in Amazon Cloud computing. This includes mapping of internal structure, checking co-residency of two VMs, forcing placement of a new VM to be co-residence with the target VM and finally attacking the target VM through side channels.

Description:
The greatest fear of consumers of Cloud computing is the leakage of their confidential information. Amazon's cloud computing tries to improve the efficiency and cost effectiveness by multiplexing different VMs on same physical machines which follow sequential and parallel locality pattern. However, Different VMs running on same physical machine are not as isolated as we think. A co-resident VM can exploit side-channels to attack the target machine. For eg. by observing load on the caching on the machine, attacker VM can gain information about load patterns or it can guess the keystroke entered by user. To achieve co-residency with a target VM, experiments are conducted to find pattern in internal IP address mapping. Turns out that the assignment of ip address is partitioned according to availability and instance type. Using this information, an attacker can try to launch a new VM on a target VM's physical machine. To be able to do that, paper presented some very effective co-residence checks such as if two VM have the same Dom0 address, that means they are on the same physical machine.

Contribution:
1. One of the main contribution of the paper is that they presented a completely different approach to attack a target service and suggested ways to mitigate these attacks. Normally attacker directly attack a target service, but using a co-resident VM to attack a neighbor service is an interesting idea.
2. What I also like was how the authors find out and were successful in abusing the placement locality of Amazon EC2. Running VMs in temporal locality has a higher probability of being co-resident. We get to have an idea of how Amazon's EC2 try to utilize their resources by multiplexing VMs.
3. The paper described some very nice technique of co-residency checks. By using covert disk communication they confirmed that the same Dom0 address is used by different VM of same physical machine.

Applicability:
I agrees with the author suggestion that users should be made aware of these potential risks and offered the option to acquire a complete physical machine if they want. (For example, if some banking related services are running in cloud, they would want to have a complete physical machine by themselves).

Summary: this paper describes the steps that an attacker can take to perform a side-channel attack on a VM running on a cloud provider that collocates customer.

Problem: cloud providers collocate VMs so that physical machines can be fully utilized. These collocated VMs may not necessarily belong to the same customer, but potentially to an attacker. An attacker can use some heuristics (described in the paper) to determine the physical machine that the victim's VM is running on, and then instantiate a VM on the same machine in order to perform a variety of attacks. Since the VMs are running on the same hardware, a variety of attacks can be performed, including DoS and compromising confidentiality, potentially exposing secret keys.

Contributions: the authors discuss techniques for discovering what hypervisor (physical machine) a VM is running on based on external network techniques. Then, other techniques, mainly to do with internal network probing or CPU/memory usage patterns, can be used to determine whether a VM was successfully collocated with the victim's. Although these techniques themselves may not be new, this paper shows how they can be used together to perform an attack. The authors propose measures that can be taken to avoid such a problem, most notably: obfuscating data center cartography and giving customers the option to run their VMs on the same physical machines.

Applicability: the techniques used in the paper already exist, and may already be used by attackers. Whether these attacks significantly compromise confidentiality or availability of the target VM can be disputed. Some of the attacks they described had limited scope, like sniffing keystrokes sent over SSH, or load generated by requesting a web page -- in more complex system with multiple nodes, I would imagine it would be more difficult to directly measure the load caused my making a request to the system. Also, what about VM migration? I had understood that VMs are migrated between physical machines to distribute the load. What does this mean for knowing what hypervisor a VM is currently running on? How does collocating an attacker VM with the target VM affect the migration of VMs?

Summary:
Tenants share physical infrastructure in a public cloud and this paper looks at the vulnerabilities arising due to this. The authors propose ways in which:
i) public cloud (EC2) could be mapped
ii) co-location of two instances on a single physical machine can be verified
iii) Instances be can launched so that they get placed on the same physical machine as the target
iv) Co-location of instances can be exploited to gain access to unauthorized information of the target instance.

Problem they are trying to solve:
Public clouds provide a cheap alternative for enterprises to run services compared to constructing their own datacenters. However, the big question is “are public clouds safe”? We assume that the cloud service provider is trusted. Despite that, there are ways for an attacker to exploit the cloud infrastructure and gain access to unauthorized information.

Techniques:
The authors’ main goal is to find a way to co-locate a VM on the same physical machine as the target VM that is to be attacked. To do this, they first map the EC2 cloud using probes. They first identify that different availability zones and instance types tend to get assigned to their own exclusive set of IPs. They then use nmap, hping and wget along with Aamzon’s internal DNS resolution service to map a target instance with a particular external IP to an internal IP and to the type of instance and availability zone it belongs to.
They can check for colocation of VMs on the same physical machine by comparing the proximity of the internal ip-addresses assigned to them and doing a TCP SYN traceroute to the target (which should consist of a single hop – DOM0).
Once we know how to check if two VMs are co-located, placing our own instance in the same machine as the target instance seems trivial. Brute force could be used or as in the paper, they leverage Amazon’s sequential and parallel placement heuristics.
After co-locating our instance on the same machine as the target, various kinds of attacks can be made to steal cryptographic keys, estimate traffic rates, measure cache usage, perform keystroke timing attack etc. as detailed in the paper (omitted for brevity).

Contributions and applicability:
First of all, the authors provide solutions to counter each of the attacks they propose. This paper is a good blend of measurement and security. Their measurement techniques are pretty novel. Security in cloud is a hot topic currently and this paper provides a very good insight on the kinds of vulnerabilities that can be exploited by any normal tenant. The only drawback here is that the ground truth is not well established and is based on other measurements/observations. But there is no way to get the ground truth without having an agreement with the cloud provider.

Summary:
Third party cloud computing, such as Amazon EC2, Rackspace Mosso, and Microsoft Azure Cloud all offer the ability to outsource processing power on demand via virtual machine instances on shared physical infrastructure. Using Amazon EC2 as a case study, Ristenpart, et al demonstrate that it’s possible to map the cloud infrastructure, and strategically obtain co-residence with a target instance on the same machine. VM-side channel attacks can then be mounted to extract information from a target VM on the same physical hardware.

Problems:
Traditional security threats involve direct compromise; in contrast cloud computing opens up side-channel attacks due to cohabitation of VM instances on the same physical hardware. This increases the attack surface available significantly since CPU caches, branch target buffers, network queues, and any other shared physical resources all become potential vulnerability points for exploitation.

Vulnerabilities:
1-Cloud Cartography: The Amazon EC2 cloud infrastructure is mappable because heir allocation strategy is relatively homogenous which allows an attacker to determine the location, and size of the target instance just based on the IP address. This narrows down candidates for co-residence, thereby increasing the odds of a VM placement on a victim target.

2-Co-residence: this can be determined via the the network: with 1-a matching Dom0 IP address, 2-small packet round trip times, and 3-numerical close internal IP addresses. The false positive rate was 0 based on their verification hard-disk based VM covert channel verification process which involved writing to a disk (or doing nothing) and having the other VM convert this into a series of 1’s and 0’s.

3-Exploiting placement: the author’s show they could place a VM instance on a target machine 8.4% of the time with brute force attempts, and as often as 40% of the time with a more strategic approach.

4-Cross-VM Information Leakage: although stealing cryptographic keys wasn’t practical, traffic rates could be estimated, other attacks were available including: 1-denial of service, 2-measuring cache usage via prime / trigger / probe, 3-load based co-residence detection, 4-estimating traffic rates, 5-keystroke timing attack, and 6-keystroke activity side-channel.

Contributions:
1-Identifying vulnerabilities (above)
2-Safer full-machine allocation algorithm: since infrastructure change is a half measure, the only viable solution they offered is to give users a choice in the allocation algorithm (and shift the cost of underutilization to those users).

Applicability:
Since obfuscating co-residence is not easily achieved, the most effective immediate solution offered is to allow users to partially bypass the current allocation algorithm and decide whether they want to take the risk of sharing physical hardware with potentially hostile 3rd parties. It is clear that sharing physical hardware with a 3rd party opens up a plethora of vulnerabilities and I hope that cloud providers are aware of these issues (and that they are taking measures to patch these vulnerabilities or at least let users decide on their own level of exposure).

Summary:

The paper presents the feasibility of provisioning co-resident VMs in Amazon EC2 cloud environment and exploiting this multi-tenancy for various attacks like cache usage measurements, denial of service, key stroke timing. Probable means for thwarting such attacks is also discussed with the foolproof solution being dedication of physical machine to the customer.

Problem:

The paper addresses the following problems:

• Given the presence of various diverse regions and availability zones, is it possible to determine a mapping pattern to co-locate a malicious VM on the same physical machine as the victim?
• Even if we did the co-residence of malicious VM, would the information extracted from the victim's VM be useful for creating attacks?

One main advantage for the attacker is that they can provision or terminate VM's without raising any suspicions; also multiple accounts could be used by the attacker.

Contributions:

• The exposure created for the practicability of cross VM attacks by co-residence.
• Creation of map between internal IP address and availability zones/instance types using simple, yet powerful network analysis. Additionally, considering that these network analysis methods could be blocked easily, computation load based co-residence detection methods are proposed.
• Determining that VMs provisioned by a single account never go onto the same physical machine.
• The reasons for effectiveness of launching a instance flooding attack soon after victim VM's provisioning seem very practical and trackable.
• Showing direct applicability of the information extracted from covert channels in attacks like computation load detection, SSH password recovery.

Applicability:

The paper clearly shows that VMs on cloud do not have complete isolation and hence are vulnerable to cross VM attacks. With the increasing demand for cloud-based services, the security flaws presented are highly applicable to all cloud service providers. But the solution of dedicating a physical machine to a particular customer seems to defeat the purpose of cloud architecture; instead other counter mechanisms like blinding techniques should be applied along with enhancement of the hypervisor's ability to detect covert channels.