Data

Internet Research Data

http://www.caida.org/data/overview/

Instruction Set Randomization

Motivation

The attackers can inject instructions to the executables. 

Definition

Instead of executing the executable directly, we add randomizations to the executable, and de-randomize when execute.

Randomization

• XOR
• Use a key to XOR with the instruction, and XOR again when execute

Reference

[1] https://www.youtube.com/watch?v=ZgNBjwXTrqA

Address Space Layout Randomization (ASLR)

Definition

Address space layout randomization (ASLR) is a memory-protection process for operating systems to guards against buffer-overflow attacks by randomizing the location where system executables are loaded into memory.

Objective

The success of many cyberattacks, particularly zero-day exploits, relies on the hacker's ability to know or guess the position of processes and functions in memory. 

ASLR is able to put address space targets in unpredictable locations. If an attacker attempts to exploit in an incorrect address space location, the target application will crash, stopping the attack and alerting the system.

Current Deployments

ASLR was created by the Pax Project as a Linux patch in 2001. 

• It was integrated into the Windows operating system beginning with Vista in 2007. Prior to ASLR, the memory locations of files and applications were either known or easily determined. 
• Adding ASLR to Vista increasing the number of possible address space locations to 256, meaning attackers only have a 1 in 256 chance of finding the correct location to execute code.
• Apple began including ASLR in MAC OS X 10.5 Leopard, and Apple iOS and Google Andriod both using ASLR in 2011.

Reference

[1] http://searchsecurity.techtarget.com/definition/address-space-layout-randomization-ASLR

HoneyPots

Introduction

[1] Deception is a mechanism that attempts to distort or mislead an attacker into taking a course of action that is more suited to the goals of the defender.

A common deception defense is the use of network honeypots.

A honeypot is a commuter system that is designed to be a trap for unauthorized accesses.

Honeypots are deployed within a network to appear like normal, active systems to an outsider.

How to build honeypots

• Mimicking
• One of the deception technique is mimicking. A honeypot attempts to mimic a real system to fool the adversary into probing and/or attacking it. 
• The amount of interaction the honeypots respond to queries with information that represents a possible system within the infrastructure but unlike a normal system, it maintains a very detailed logs of all interactions.  From these detailed logs, administrators can gain insight into an attacker's goal and methods as well as put in place other measures to hopes of preventing an attack. 

Reference

[1] Probabilistic Performance Analysis of Moving Target and Deception Reconnaissance Defenses, by Michael Crouse, in MTD15

Web Application Moving Target Defense

Motivation

• Web application remains the most popular way for businesses to provide services over the Internet. It is the "front door" of many companies, and therefore their security is of paramount importance.
• Example [1]
• JPMorgan Chase breach in 2014 affected 76 million US households
• Bloomberg reported that the hackers exploited an overlooed falow in one of the bank's webistes.
• The efforts in discovering and fixing vulnerabilities are not enough to protect web applications for many reasons [1]
• The increasing complexity of modern web applications brings inevitable risks that cannot be fully mitigated in the process of web application development and deployment
• Attackers can take their time, to understand the web application's functionality and technology stack, before launching an attack

Background

• Web application technology

Objective

• Ref [1]
• The key issue is to design MTD mechanism that 
• Prevent or disrupt a vulnerability or exploit
• While still providing the identical functionality

Issues

• Choose what component to move in a web application
• Decide the optimal time and how often to move components

Proposals

• Change the server-side language used in a web application 
• automatically translating server-side web application code to another language in order to prevent Code Injection exploits
• Shifts the Database used in a web application
• transform the backend SQL database into different implementations that speak different dialects in order to prevent SQL Injection exploits.

Reference

[1] Toward a Moving Target Defense for Web Applications, by Marthony Taguinod et al., in International Conference on Information Reuse and Integeration 2015

Shuffling Theory

1. If there are n computers, among which 1 is vulnerable. Each computer is assigned an IP address, the attackers probe randomly on the IP address to check whether its corresponding computer is vulnerable. If the IP addresses of all computer randomly shuffled after each attacker's probe. What is the probability that the attacker will find the vulnerable machine?

Answer:

$Pr(0<x<n) = 1 - (1-1/n)^n = 1 - 1/e$




Reference
[1] Analysis of Network Address Shuffling as a Moving Target Defense, by Thomas E. Carroll, in ICC14

Software Defined Network

Introduction

The SDN paradigm creates a separation between data plane processing and control flow processing.

• data plan processing
•  forwards packets
• control flow processing
• determine how to populate forwarding tables

The OpenFlow protocol acts as an API between network switches and a logically centralized decision maker, called the OpenFlow controller. In this model,

• Network switch
• cache data flow rules
• when a switch receive a packet and does not know how to forward it according to its cached rules, the switch sends an "elevation" request containing the original packet and a request for guidance to the controller
• OpenFlow Controller
• examines the packet and sends a set of rules that the switch should add to the data plane cache for use in forwarding packets.

Vulnerability

DDos Attack on the controller 

• DDos Attack on the controller [1]
• Since the switches will send all the packets it cannot handle to the controller
• There is no need for an attacker to catch the IP address or location of the controller through scanning before launching an attack. The attackers can send some specific attack packets and abnormal packets to SDN networks, all switches will automatically forward these packets to their controller.
• Attackers send packets to probe whether the target is SDN architecture [1]
• Every flow entry in the flow table of a switch contains three items, i.e., rule, action and stats.
• The attacker can make a new or abnormal packet from carefully selected IP, Port, MAC etc., and then send it to the switch.
• Generally, there is no rule in the switch matching the fresh packet sent for the first time. The packet will be uploaded to the controller, and then the controller will broadcast this packet's information to all the network interface to find its route. 
• Once getting the route, the controller will issue corresponding rules to the switch's flow table. Otherwise, the controller will make a rule to switch to drop these packets. This whole response will take a long time. 
• Then the attacker will send a group of packets with the same information for a second time to the switch, if the response time is much shorter than that of the first time, the network can be determined to be SDN architecture.
• An attacker may launch Blind DDoS directly on the network which claims to be SDN network architecture or switch the attackers has already known is SDN system by scanning. 

Tools

• Mininet [2]
• can be used to create a network of OpenFlow switches that are connected according to your plan. 

Reference

[1] Defending Blind DDoS Attack on SDN Based on Moving Target Defense, by Duohe Ma, Zhen Xu and Dongdai Liu, in SecureCOMM14
[2] OpenFlow random host mutation: Transparent moving target defense using software defined networking, by J. H. Jafarian, in HotSDN 2012

Network Mapping Threat

Threat

Reconnaissance enables adversaries to gather information about the target system including network topology, configurations, network dynamics.

This information can be used to identify system vulnerabilities, and to design and execute specific exploits.

Procedure of Attack

Most network mapping tools perform their operations by using ICMP packets and TCP or UDP scans.

• ICMP messages are typically used to verify connectivity or reachability of potential targets. TCP and UDP port scans are used to identify running services of a target. 
• Replies (RCP RST, silent drop of ICMP unreachable) to scans can also reveal what services are allowed or filtered through transit devices. 
• Additionally, the TTL field of IP packets is used to identify the distance between the target and the destination.

Reference
[1] SDN-based solutions for Moving Target Defense Network Protection, by Panos Kampanakis, in WoWMoM14

Network-based Moving Target Defense

Background

• Software Defined Network

Motivation

• Scanning Worms
• [3] Scanning tools and worms usually send probes to random IP addresses in the network in order to discover their targets. 
• When a target responds, it can then be identified and attacked. Otherwise, the probed addresses will be considered unused.
• Despite firewall deployment, most enterprise networks have many public and private hosts accessible from outside. 
• The IP address assignment scheme can become more dynamic by using approaches based on DHCP or NAT, but they are insufficient to provide proactive countermeasure because the IP mutation is infrequent and traceable.
• Network mapping threat

Previous Work

• DHCP
• Prior work focused on defending hit-list scanning malware utilized DHCP to change the IP address of the host over time
• However, this change can disrupt existing connections.
• This can be solved by placing an intermediate NAT-like box in the network and transparently transition to the new address over time.
• The NAT-like device provided similar address translating behavior, with additional logic to preserve old addresses while they are still in use by previously established connections. 
• IP address randomization [4]
• Rather than changing out the DHCP lease to achieve randomization, they randomly rotate the IP address contained in the DNS reply and notified the NAT device.
• The NAT device then allows new connections with that IP to reach the requested host by mapping it to the host's fixed internal address.
• NAT
• Using NAT to hide the real IP address of the server will make it difficult to reach legitimate hosts remotely. [8]

• Network Address Space Randomization (NASR) [7]
• It was proposed to offer an IP hopping approach that can defend against hitlist worms.
• NASR is a LAN-level network address randomization scheme based on DHCP updates.
• Cons
• Not transparent
• NASR is not transparent to end-hosts because DHCP changes are applied to the end-host itself which results in disruption of active connections during address translation.
• Expensive to deploy
• Moreover, it requires changes to the end-host operating system which makes its deployment very costly.
• Limited unpredictability
• Also, NASR provides very limited unpredictability and mutation speed because its IP mutation is limited on the LAN address space and will require DHCP and host to be reconfigured for this purpose (the maximum IP mutation speed in once very 15 minutes). 

Network Address Randomization

• IP address randomization [5]
• Requires the DNS gateway in both the clients and servers to do the translation

DNS Capability Approach

• Ref [6][2]
• The mapping system was implemented using two components
• A DNS server
• Provide clients with the destination IP address of a targeted server at that moment
• A NAT mapping device
• Grant the client access to the server when a destination mapping is used.
• It stores the state for each established flow, allowing the DNS server to change addresses and providing a unique response to each new client without disrupting the established flow. 
• My questions
• As the NAT needs to maintain so many states, will it result in DDoS attack?

OpenFlow Mutation Approach

• Ref [6] [3]
• Similar to DNS Capability approach.
• The network switches plays the role of NAT devices.
• When the switch receives a packet and does not known how to forward the packet, it can ask for instructions (called elevation) from a specific machine, called the OpenFlow controller.
• The OpenFlow mutation approach uses this elevation mechanism to alter the NDS records and to change packet address in flight. 
• When a client performs a DNS lookup, the DNS server will provide the client with a virtual IP address for a target. 
• When the client attempts to access the target, the packet is forwarded using the virtual IP address until it reaches the destination switch, at which point it is translated to the destination host's real IP address. The network switches essentially act as NAT devices, performing translations between virtual and real IP addresses. 

Communication via Name

• Steps 1-3
• When a DNS query is sent to resolve the name of a host
• The DNS response is updated by the NOX controller to replace the rIP of the server with its active vIP
• The NOX controller also sets the TTL value in the DNS response to a small value. 

• Step 4
• The source host can then initiate the connection using the vIP of the destination
• The OF-switch encapsulates and sends the initial packet to the controller, because there is no matching flow for it.
• Step 5
• The NOX controller installs relevant flows in OF-switches in the route.
• These flows are associated with relevant required Set-Field actions which determine the translation of source/destination rIP addresses to/from vIP addresses
• Relevant flows are installed in destination OF-switch as well. Any other switches in the path are only configured (i.e., flows with no actions) to route the traffic based on vIP. 
• Future packets will be matches and forward by OF-switches (without being sent to controller) according to the installed flows in the flow table.
• The vIP-rIP translation actions will be applied to packets by OF-switches. 

Communication via rIP address

Figure 3 shows how authorized users (e.g., administrator) can reach hosts using rIPs. In this case, the source host initiates a connection with the destination using its rIP. 

• Step 1
• Similar to DNS scenario, the OF-switch will fail to match the new packet with any flow and sends it to NOX controller
• Step 2
• The NOX controller authorizes the access request
• Step 3
• If granted, the controller installs appropriate flows in OF-switches in the route with appropriate vIP-rIp translation actions according to Figure 3

If the source host is internal, NOX controller installs two inbound and outbound flows in source OF-switch, same to DNS scenario. 

Two flows are also inserted in the flow table of destination OF-switch.

However, destination flows require no translation, because the destination host is being reached via its rIP. 

MT6D Approach

• Ref [6][1]
• The client and the server share a symmetric key out-of-band and use these keys to determine the IPv6 addresses the hosts will use.
• To construct their IPv6 address
•  the hosts construct a hash using the shared key, a value derived from the host's MAC address, and a timestamp. The approach extracts 64 bits from the hash output to encode the lower 64 bits of the host's IPv6 address.
• To perform uniform communication between the host applications, the operating system on each host uses a tunneling approach and rotates the addresses of the tunnel end-points. 
• Cons
• Organizations cannot protect public-facing server infrastructure without requiring clients to install software
• The MT6D approach is only effective when both the client and the server can be modified, which prevents its use when protecting public infrastructure for legacy clients. 

Reference

[1] MT6D: A moving target IPv6 defense, by M. Dunlop et al, in Military Communications Conference 2011.

[2] On building inexpensive network capabilities. by C. A. Shue et al, in SIGCOMM 2012

[3] OpenFlow random host mutation: Transparent moving target defense using software defined networking, by J. H. Jafarian, in HotSDN 2012
[4] The SDN Shuffle: Creating a Moving-Target Defense using Host-based Software-Defined Networking, by Douglas C. Macfarland, in MTD15
[5] Adversary-aware IP Address Randomization for Proactive Agility against Sophisticated Attackers, by Jafar Haadi Jafarian, in INFOCOM 2015
[6] Characterizing Network-Based Moving Target Defense, by Douglas C. MacFarland, in MTD15
[7] Defending against Hitlist Worms using Network Address Space Randomization, by S. Antonatos, in Computer Network 2007
[8] Random Host Mutation for Moving Target Defense, by Ehab Al-Shaer, Qi Duan, and Jafar Haadi Jafarian, in Securecomm 2012

Motivation of Moving Target Defense

Phases of Attacks

Any attack will go through at least three phases: probing, constructing and launching phases. [1]

If the environment stays static, the attacker has time to identify existing vulnerabilities to be exploited.

However, if the life cycle of an application version ins much shorter than it takes for the attacker to launch the attack as it will be, the attacker will not be able to succeed in exploiting any existing vulnerabilities in the cloud application.

Current Static Network/System

The static nature of current network configuration approaches has made it easy to attack and breach a system and to maintain illegal access to privileges for extended periods of time. [2]

• The attacker have time to study the network of defender and to determine potential vulnerabilities and choose the time of attack and gain the maximum benefit.
• Once an attacker acquires a privilege, that privilege can be maintained for a long time without being detected. 

Objective of Moving Target Defense

Moving target defense aims at continuously changing a system's attack surface, and thus

• increase the uncertainty, complexity and cost for attackers
• limit the exposure of vulnerabilities
• ultimately increase overall resiliency

The idea of moving target defense is to

• reduce information asymmetry between the attacker and the defender
• and ultimately rendering the reconnaissance information misleading or uesless\

Even if the attacker succeeds in finding a vulnerability at one point, the vulnerability could be unavailable as the result of shifting the underlying system, which makes the environment more resilient against attacks. 

Reference

[1] Autonomic Resilient Cloud Management (ARCM), by Cihan Tunc etc, in ICCAC 2014
[2] Simulation-based Approaches to Studying Effectiveness of Moving-Target Network Defense, by Rui Zhuang, Su Zhang, Scott A. Deloach, Xinming Ou, and Anoop Singhal, in MTD 2015

Code Reuse Attacks

What it is

Code reuse attacks allow the adversary to make malicious results by exploiting the control flow of existing program without any additional code injection.



In a code-reuse attack, the attacker combines existing code fragments (called gadgets) to achieve arbitrary computation. While code-resue attacks are Turing complete, they are generally used to disable code integrity and to allow an attacker to execute injected code. 

Return Oriented Programming (ROP)

Code reuse attacks allow attackers to execute arbitrary code on a compromised machine.

In this, the attacker directs the control flow through existing code without injecting new executable code.


Using ROP, the attackers can link small pieces of code which is known as gadgets, that already exist in the binary image of a vulnerable application.

In fact, the ROP gadgets are short sequence of code, typically ending with a return or indirect control transfer instruction. Instead of injecting binary code into the memory space of an application, the attacker can use a sequence of gadget in the stack or other memory of the program.

Each gadget ends with an indirect control transfer instruction, which transfers the control of next gadget according to the injected gadget sequence.

Existing defender lose effects

During the attack, the adversary can circumvent many defenses such as 

• Read-only memory
• Non-executable meomry
• Kernel-code integrity protections

Since the injected part is only data (rather than code). In addition, access to ROP exploits is not difficult since they are provided in the publicly available packs. 

Most of existing defense mechanisms cannot defend code reuse attacks, such as

• Instruction Set Randomization
• Simple Address Space Layout Randomization (ASLR)
• Stack canaries (Ref [25] in [3])

How to defense

Instruction Location Randomization

Software Diversity

• By randomizing a binary's code layout, a memory vulnerability is moved to a priori unknown location in the binary, thereby bring down the probability of return-to-libc and return-oriented attacks. [2]
• [2] proposes an approach to recompile the code during execution with Java JIT compiler.

Reference

[1] Enhancing Software Dependability and Security with Hardware Supported Instruction Address Space Randomization, by Weidong Shi, in DSN15
[2] Adaptive Just-in-Time Code Diversification, by Abhinav Jangda, in MTD15
[3] An Evil Copy: How the Loader Betrays you 

How to come up with new ideas in security domain

The followings are my own experience in finding research ideas in security domain.

Ideas from Security Threat

• What the defenders can do to improve security?
• How to detect attackers?
• How to defend against attackers?

For the cloud computing problem, the defenders can be further divided into two categories: (1) Cloud provider (2) Cloud benign users

• What the attackers can do to increase damage?

Ideas from Existing Work

• Improve
• Scalability of their mechanism
• Combine
• Can we combine other mechanisms with their mechanism
• New Problem
• Can we use the proposed mechanism to solve a different problem
• New Mechanism
• Can we solve the problem with a better mechanism

Latin Square

What it is

• An n*n array filled with n different symbols, each occurring exactly once in each row and exactly once in each column. 

What property does it have

What's the application in security

• use for image cipher

References

[1] The Role of Latin Square in Cipher Systems: A Matrix Approach to Model Encryption Modes of Operation, UCLA

[2] Image encryption based on permutationsubstitution using chaotic map and Latin Square Image Cipher, in EDP 2014

Split Keys to Multiple Machines

The objective of this post is to discuss the feasibility of splitting credentials into multiple machines.

Why to Split Key

• The motivation is to enhance the difficulty for the attackers to steal the key. The attackers would need to compromise several machines together 

How to Split Key

• [2] RSA

Feasibility of Splitting Key to Protect Security

• Though the secrets are separated, the rebuilding process must occur, by necessity, on a single machine which obtains, at some point, the secret itself. In particular, if you do the reassembly on a machine which is evil (i.e., which is under the control of an attacker through some malware), then the attacker learns the SSH private key. [1]

Conclusion

• It is not feasible to defense covert channel attack through splitting credentials to multiple machines. 

References

[1] Is there a way to split up my SSH Key using Shamir's Secret Sharing?,  in StackExchange 

[2] RSA Splits Authentication Credentials Across Multiple Servers For Added Protection
[3] Distributed Credential Protection: Trying to beat the hackers and protect our passwords

Cloud Covert Channel Attack

What it is

- Introduction of covert channel attack

Co-residence threats in Cloud 

In current commercial cloud, cloud providers allow multiple users to share the physical machine rather than assigning a dedicated machine to every user. Although in theory, VMs running on the same server (i.e., ci-resident VMs) should be logically isolated from each other, malicious users can still circumvent the logical isolation, and obtain sensitive information from co-resident VMs [6].

A malicious virtual machine (VM) can extract fine-grained information from a victim VM running on the same physical machine.

Thus malicious users can try to co-locate their VMs with target VMs on the same physical server, and then exploit side channels to extract private information from the victim [5].

Types

• Access Driven
• The attackers program monitors usage of a shared architectural component to learn information about the key, e.g., the data cache, instruction cache, floating-point multiplier, or branch-prediction cache.
• The attackers could be asynchronous, meaning that they do not require the attacker to achieve precisely timed observations of the victim by actively triggering the victim operation. 

Examples

• Zhang et al. [1] demonstrate a VM can extract a private ElGamal decryption key from a co-resident victim VM running Gnu Privacy Guard (GnuPG), which is a popular software package that implements the OpenPGP email encryption standard.
• By overloading the CPU while a victim AES encryption process is running. They managed to gain control over the CPU and suspend the AES process thereby gaining an opportunity to monitor cache access of the victim process.

Threats Of Covert Channel Attacks

How it works

The first step for the attackers is to try to achieve co-residence with the target VMs, and then conduct covert channel attacks by exploiting shared microarchitectural components such as caches.

How to achieve co-residence

• The most straightforward approach is to use a brute-force strategy, start as many VMs as possible until co-residence is achieved.
• [7][8] investigate how to efficiency achieve co-residency.

Approach 1: PRIME + PROBE method 

• Step 1: 
• Attackers create one or more eviction sets. An eviction set is a sequence of memory addresses that are all mapped by the CPU into the same cache set. 
• The PRIME+PROBE method also assumes that the victim code uses this cache set for its own code or data.
• Step 2:
• The attackers prime the cache set by accessing the eviction set in an appropriate way.
• This force the eviction of the victim's data or instructions from the cache set and brings it to a known state.
• Step 3:
• The attackers trigger the victim process, or passively waits for it to execute. 
• During this execution step, the victim may potentially utilize the cashe and evict some of the attacker's elements from the cache set.
• Step 4:
• The attacker probes the cache set by accessing the eviction set again.
• A probe step with a low access latency suggests that the attacker's eviction set is still in the cache.
• Conversely, a higher access latency suggests that the victim's code made use of the cashe set and evicted some of the attacker's memory elements.
• The attackers thus learns about the victim's internal state. 
• The actual timing measurement is carried out by using the (unpriviledged) instruction rdtsc, which provides a hide-fidelity measurement of the CPU cycle count.
• Iterating over the eviction set in the probing phase forces the cache set yet again into an attacker-controlled state, thus preparing for the next round of measurement.

How to defense against it

Several countermeasures have been proposed at different levels: hypervisor, guest OS, hardware and application-layer approaches.

1. Eliminating the side channels

• Hypervisor-based approach.
• Modify the Xen scheduler to limit the frequency in which an attacker can preempt the victim.
• Locking cache lines to prevent preemption by an attacker and multiplexing the cache lines among VMs such that each has an access to its own.
• Remove high resolution clock
• Note the side-channels attacks relies on it
• Add noise/latency
• Periodic time-shared cache cleasing, in order to make the side channel noisy.
• Hide the program execution time
• Alter the timing exposed to an external observer.
• e.g., add latency
• Statistical multiplexing of shared resources to prevent eavesdropping.
• Guest OS
• Injecting noise into protected processes on L1 and L2 caches.
• Hardware
• Hardware design incorporates access randomization and resource partitioning.
• e.g., avoid sharing of sensitive resources
• Remove hypervisor, and use hardware mechanisms for the isolation of access to shared resources

Cons

• These methods often require substantial changes to be made to existing cloud platforms, and hence are unlikely to be adopted by cloud providers any time soon.

2. Increasing the difficulty of verifying co-residence

• Existing works show that traceroute tool can be used to decide the IP address of a VM's Dom0, which is a privileged VM that manages all VMs on a host. If two Dom0 IP addresses are the same, then the corresponding VMs are co-resident.
• Cloud provider can prevent Dom0's IP address from being exposed to customers. so that attackers will be forced to resort to other options that do not rely no network measurements.
• However, as more and more methods of detecting co-residence have been proposed [10-12], simply hiding Dom0's IP address is not sufficient. [9]

3. Increasing the difficulty of steal information

• Application-level
• Partitioning a cryptographic key across multiple VMs.
• E.g, divide the secrets using Shamir's secret

4. Detecting the features of co-resident attacks

• When attackers use Prime+Probe technique to extract information from the victim, there are abnormalities in the CPU and RAM utilization, system calls, and cache miss behaviors. [13][14]

5. Migrating VMs periodically

• VM migration 
• This approach is proposed in [4]. 
• Pros
• Other approaches are not suitable for immediate deployment due to the required modification to the cloud platforms, while VM migrations can be implemented immediately.

6. Using VM allocation policies to make it difficult to achieve co-residence

References
[1] Cross-VM side channels and their use to extract private keys, CCS 2012
[2] Wait a Minute! A fast, Cross-VM Attack on AES, in Research in Attacks, Intrusions and Defenses, LCNS 2-14
[3] The Spy in the Sandbox: Practical Cache Attacks in JavaScript and their Implications, CCS15
[4] Nomad: Mitigating Arbitrary Cloud Side Channels via Provider-Assisted Migration, CCS15
[5] Security Games for Virtual Machine Allocation in Cloud Computing, by Yi Han et al., in GameSec15
[6] Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds, by Restenpart, T. et al., in CCS09
[7] A Placement Vulnerability Study in Multi-Tenant Public Clouds, by Venkatanathan Varadarajan, in UnixSecurity15
[8] A Measurement Study on Co-residence Threat inside the Cloud, by Haining Wang, in UnixSecurity
[9] Using Virtual Machine Allocation Policies to Defend against Co-resident Attacks in Cloud Computing, by Yi Han et al, in Transactions on Dependable and Secure Computing
[10] Detecting co-residency with Active Traffic Analysis Techniques, by A. Bates, in CCSW12
[11] Detecting VMs co-residency in Cloud: Using Cached-based Side Channels Attacks, by S. Yu 2013
[12] On Detecting Co-resident Cloud Instances Using Network Flow Watermarking Techniques, by A. Bates, in International Journal of Information Security, 2014
[13] Detecting malicious Coresident Virtual Machines Indulging in Load-Based Attacks, by S. Sundareswaran, in Information and Communication Security 2013
[14] An Approach with Two-stage Mode to Detect Cache-based Side Channel Attacks, by S. Yu, in ICOIN 2013