How to Measure Cache Usage

Prime + Trigger + Probe

[1] demonstrates how to utilize the Prime + Probe technique to measure the cache activity, and extend it to the following Prime + Trigger + Probe measurement to support the setting of time-shared virtual machines.

  • The probing instance first allocates a continuous buffer B of b bytes
    • Here b should be large enough that a significant portion of the cache is filled by B.
  • Let s be the cache line size, in bytes.
  • Then the probing instance performs the following steps to generate each load sample
    1. Prime: Read B at s-byte offset in order to ensure it is cached. 
    2. Trigger: Busy-loop until the CPU’s cycle counter jump by a large value
      • This means our VM was preempted by the Xen scheduler, hopefully in favor of the sender VM. 
    3. Probe: Measure the time it takes to again read B at s-byte offsets. 
When reading b/s memory locations in B, we use a pseudorandom order, and the pointer-chasing technique to prevent the CPU’s hardware prefetcher from hiding the latencies. 
The time the of the final step’s read is the load sample, measured in number of CPU cycles. These laod samples will be strongly correlated with use of the cache during the trigger step, since last usage will evict some portion of the buffer and thereby drive up the read time during the probe phase. 

Reference 

[1] Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds, by Restenpart, T. et al., in CCS09

Threat of Covert Channel Attacks

Summary

  • Attackers can build various side channels to circumvent the logical isolation in cloud physical machines, and obtain sensitive information from co-resident VMs
    • Coarse-grained, e.g., workloads and web traffic rates
      • Since the cache utilization rate has a large impact on the execution time of the cache read operation, attackers can infer the victim’s cache usage and workload information, by applying the Prime+Probe technique. 
      • Similarly, they can estimate the victim’s web traffic rate, which also has a strong correlation with the execution time of cache operations. [2]
      • [1] demonstrate a clear correlation between a victim’s web traffic rate with the load sample. 
    • Fine-grained, e.g., cryptographic keys
      • Attackers can exploit shared hardware resources, such as the instruction cache, to extract cryptographic keys. Specifically, the following challenges are overcomed
        • Dealing with core migrations and determining if an observation is associated with the victim
        • Filtering out hardware and software noise, and regaining access to the target CPU core with sufficient frequency
  • For clever attackers, even seemingly innocuous information like workload statistics can be useful.
    • For example, such data can be used to identify when the system is most vulnerable, i.e., the time to launch further attacks, such as Denial of Service attacks. [9]
Reference
[2] 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

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

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

Reinforcement Learning

Introduction

Multi-agent reinforcement learning (MARL) algorithms gradually learn good (ideally optimal) strategies with respect to long-term goals through trial-and-error interactions with both the opponent and the unknown dynamic environment. 
The Stochastic Game (SG), together with MARL can address the environmental dynamics in security games in a systematic manner.

Reference

[1] A comprehensive survey of multi-agent reinforcement learning, by L. Busoniu, R. Babuska, and B. De Schutter, in IEEE Trans. Syst., Man, Cybern. C, 2008

[2] Improving Learning and Adaptation in Security Games by Exploiting Information Asymmetry, by Xiaofan He. Huaiyu Dai and Peng Ning, in INFOCOM 2015

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

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