Authors:
Dennis Steinhilber
Albert Téllez
Supervisor: Ola Flygt
Semester: VT 2020
Subject: Computer Science
Linnaeus University
A Comparison of the Resiliency
Against Attacks Between
Abstract
Virtualisation is a technology that is more and more applied due to its advantages regarding cost and operation. It is often believed that it provides a better security for an IT environment since it enables centralisation of hardware. However, virtu-alisation changes an IT environment fundamentally and contains new vulnerabilities that must be considered. It is of interest to evaluate whether the belief that virtual environments provide a better security for an IT environment is true or not. In this project, the resiliency against attacks for physical environments and virtual envir-onments is analysed to determine which one provides a higher resiliency and why. Therefore, the physical and digital attack surfaces of all entities are analysed to reveal the relevant vulnerabilities that could be exploited. Beside a theoretical research, a physical and a virtual environment have been established to test chosen attacks prac-tically. The results show that virtual environments are less resilient than physical environments, especially to common attacks. This shows that virtualisation is still a technology that is new to many companies and the vulnerabilities it has must be taken seriously.
Contents
1 Introduction 5
1.1 Background . . . 5
1.1.1 Differences between physical and virtual environments . . . 5
1.1.2 Hypervisor . . . 6
1.1.2.1 Type 1 hypervisors . . . 6
1.1.2.2 Type 2 hypervisors . . . 7
1.1.2.3 Interactions between guest operating system and host hardware . . . 8
1.1.2.4 Types of virtualised devices . . . 8
1.1.3 Virtual switch . . . 9 1.1.4 Attack surface . . . 9 1.1.5 Attack vector . . . 10 1.2 Problem formulation . . . 10 1.3 Motivation . . . 11 1.4 Objectives . . . 11
1.5 Scope and limitations . . . 11
1.6 Target group . . . 12 1.7 Method . . . 12 2 Experiments 13 2.1 Test environments . . . 13 2.1.1 Virtual environment . . . 13 2.1.1.1 Hardware . . . 14 2.1.1.2 Configuration . . . 14 2.1.2 Physical environment . . . 16
2.1.2.1 Hardware and configuration . . . 17
2.2 Attack surfaces and vectors of the environments . . . 17
2.3 Experiment realisation . . . 18 2.3.1 ARP poisoning . . . 18 2.3.2 DHCP spoofing . . . 21 2.3.3 DHCP starvation . . . 24 3 Results 26 3.1 Scoring system . . . 26 3.2 Score determination . . . 28 3.2.1 Switch . . . 28 3.2.1.1 Physical destruction . . . 29
3.2.1.2 CAM table overflow . . . 29
3.2.1.3 ARP poisoning . . . 31
3.2.2 Firewall . . . 32
3.2.2.1 Physical destruction . . . 33
3.2.3 Storage . . . 34
1
Introduction
In the context of an IT environment, most people would think of physical computers that are able to communicate with each other within a local network or, on a larger scale, the Internet. Such a purely physical environment had been typical for a long time. However, since the beginning of this century, virtualisation has become more and more popular due to the advantages it offers to IT environments. For example, the less complex monitoring makes it easier to react on security issues. Furthermore, the reduced amount of hard-ware and energy will translate into a reduced cost [1]. On the other hand, new problems and challenges, especially regarding security, appear in environments whose entities have been virtualised to some degree. In this project, purely physical environments, which do not contain any virtualised entities, and virtual environments, which contain at least one virtualised entity, will be analysed to determine their resiliency against attack vectors that would be relevant for the outcome of the project (see 1.5). Attack vectors that are feasible to perform will be tested in a practical experiment.
1.1
Background
Virtualisation is a technology used to create virtual entities of something instead of phys-ical ones [2]. Virtuality is the property of not existing as it appears, to be immaterial but also real [3]. This means that these virtual entities do not exist physically, but have the same functionality as their physical counterparts and exist, therefore, logically. In order to create virtual entities, appropriate physical entities are required. For example, several power sources can be combined to form a virtual power plant that provides electrical en-ergy [4]. Another example is several individuals that form a virtual organisation [5]. In IT, where the term virtualisation is mainly used, physical hardware is required to create virtual hardware. Both types of hardware will be separated by an abstraction layer created by the existence of a hypervisor, which is the software needed for the establishment of virtual hardware [6]. The physical entities are hidden to those who use virtual entities. Therefore, physical entities have become less important since they are exchangeable and can be replaced by other physical entities, which has no effect on the virtual entities.
Although virtualisation is used in many areas in IT, it is mostly referred to desktop and, especially, server virtualisation [7], which results in virtual machines. A virtual machine is a logically separated domain for an operating system or application, created by the hypervisor, that contains simulated hardware [8]. Although the domain’s hardware does not exist as it appears, it makes no difference to the operating system or application running in the virtual machine since they can use this simulated hardware in the same way as physical hardware. Virtual machines are accessed over internal or external networks by using a terminal computer like a thin client [2]. For users, there is logically no difference in using virtual machines compared to using physical computers [8].
1.1.1
Differences between physical and virtual environments
workstations. The entities in a physical environment are typically more spatially distrib-uted while entities in a virtual environment are more concentrated in one location. The advantage of virtualisation here is that security measures can also be concentrated and the physical attack surface can be narrowed down. On the other hand, the concentration of entities in one location can become a single point of failure. For example, in case a vir-tual machine server collapses, all virvir-tual machines hosted on this server are affected [9]. A virtual environment relies more on the network since clients in such an environment are only used for input and output. The data is transmitted over the network to and from virtual machines, where its processing happens. A disruption of the network connection affects the system’s availability. Another issue in virtual environments is network conges-tion, which can occur since a virtual machine server has to handle more network traffic than an ordinary server [10]. One significant difference is that a virtual environment has a hypervisor as an additional software layer, which does not exist in a physical environment.
1.1.2
Hypervisor
The hypervisor is an integral part of a virtualised computing environment. It is a piece of software running on the host machine that can manage virtual machines by allocat-ing resources from the host machine’s operatallocat-ing system or hardware directly [11]. It will present to administrators the underlying hardware as a pool of available resources and sep-arate the physical hardware from the virtual machines [11]. Concludingly, the hardware is isolated from the guest operating systems, which leads to isolated software between virtual machine.
There exist two different types of hypervisors, which are named Type-1-hypervisors or Bare-metal hypervisors and Type-2-hypervisors or Hosted hypervisors [6].
Figure 1.1: Type 1 hypervisor
1.1.2.2 Type 2 hypervisors The software of type 2 hypervisors runs in the operating system of a host machine. Said operating system is a layer of abstraction that exists between the hypervisor and the hardware, which does not exist in the architecture of type 1 hypervisors [6]. Since type 2 hypervisors run on top of an underlying operating system that is in control of the hardware, resource allocation works differently. Resources given towards a guest machine will be completely allocated and withheld from the host machine instead of reserving only the needed resources the virtual machine needs at a specific time [6]. A simple diagram on the architecture of type 2 hypervisors can be seen in Figure 1.2.
1.1.2.3 Interactions between guest operating system and host hardware The hy-pervisor manages the interaction between the guest operating system and real hardware. In order to understand how a guest operating system interacts with the hardware (directly or through the hypervisor), the basic functionality of how an operating system executes programs must be explained.
Operating systems send instructions to the processors sourced from executable pro-grams in the form of execution threads with their own reserved memory space [12]. If a thread has to wait for more instructions or faces an issue, the operating system intervenes and handles the resources necessary for that thread to continue or not, which could also invoke the creation of another thread [12].
There is an allocated resource space, such as memory regions, for each virtual machine guest when the hypervisor exists as a layer. These allocated resources can be categorised as resource sandboxes [12]. Such a sandbox, on which the guest OS runs, is designed to provide the OS in question an environment it believes to be its own. The hypervisor supervises operations on each resource sandbox and intervenes when one of the guest virtual machines attempts to use resources that have not been allocated to it [12].
Multiple virtual machines might request the use of the same physical hardware, for instance, a network card. Hardware devices do not usually support concurrent access from multiple device drivers that have unrelated execution threads [12]. Therefore, there has to be a software layer that can manage access to these resources in an organised way. 1.1.2.4 Types of virtualised devices There are three main methods of sandboxing the hardware, each with its advantages and disadvantages. The immediate difference regarding the usage of the different types of devices is the performance overhead between them.
1.1.2.4.1 Virtualised Fully virtualised devices make use of software emulation. All the signals sent to a fully virtualised device are intercepted by the hypervisor, which possesses the necessary code to emulate the device and interpret the signals to and from the device [12]. The emulation is performed via a mixture of binary translation, which is a software technique that replaces sensitive instructions by non-sensitive instructions [13], and direct execution on the CPU [14]. Sensitive instructions are instructions that change the configuration of the resources or their availability. For fully virtualised devices, all these instructions must first go through the hypervisor in order to be translated [15]. Other non-sensitive instructions can be executed by the CPU with native performance [14]. A large number of hardware configurations and operation translations result in reduced per-formance of the virtualised device [12].
particular device driver that can allow communication between the idealised device and the physical device, which is simpler due to the software-driven design of these idealised devices [12]. The VirtIO framework is a popular framework for para-virtualised devices [12] and is the framework of choice for the virtual environment in this project.
1.1.2.4.3 Pass-though Pass-through devices are devices to which the hypervisor gives a specific guest OS full access [12]. In pass-through mode, virtual machines other than the one given full access to will not be aware of the existence of the pass-through device. The lack of visibility prevents other OSs from loading drivers for that device [12]. Therefore, pass-through technology is meant for devices that are used exclusively by a single OS and is not an option for devices that are intended to be shared.
1.1.3
Virtual switch
A virtual switch works like its physical counterpart, except for the fact that it does not physically exist, but is purely software based [16]. It is part of a virtual environment and is used to enable the communication of virtual machines among each other. Virtual switches can be part of virtualisation software or part of the firmware [16].
1.1.4
Attack surface
All vulnerabilities together that can exist in a system form the attack surface of that sys-tem, which itself can be divided into the physical attack surface and the digital attack surface [17]. Social engineering can also be considered as an attack surface. However, there is no difference between the social engineering attack surface of a physical environ-ment and the social engineering attack surface of a virtual environenviron-ment. Therefore, they are irrelevant for the results and not considered in this project.
The physical attack surface contains all vulnerabilities that can be exploited by having unauthorised physical access to an entity. Unauthorised physical access to such entities, to which devices that store or process data belong, gives an attacker access to digital attack surfaces which might contain vulnerabilities [17]. If an attacker wants to compromise availability of a system, physical access to it is often sufficient and an attack on the digital attack surface is not necessary. The number of vulnerabilities on a physical attack surface can be reduced by applying appropriate security measurements on all entities. Access control measurements should narrow down physical entry points and restrict access to sensitive entities, surveillance measurements should keep track of all sensitive entities and testing measurements should ensure that disaster recovery works as intended [17].
of the network attack surface, well-known measures like firewalls and intrusion detection system should be used, and default policies like blocking all traffic should be implemen-ted. All vulnerabilities in executable code that can be accessed in an unauthorised way belong to the software attack surface [19]. The greater the accessibility of code is, the greater the vulnerability. Code that can only be executed locally is less likely to contain exploitable vulnerabilities than code that can be executed from the Internet. Vulnerabilit-ies in code can be exploited to access more sensitive parts of a system and to compromise security, which can also be performed by authenticated users [19]. In order to limit the size of the software attack surface, all software, including the operating system, should be up to date, systems should not execute unneeded software and code, and access control should be implemented properly on the software level.
It is recommended to perform an analysis of all attack surfaces of all entities that exist in an environment [17].
1.1.5
Attack vector
The term attack vector describes a method for an attacker to compromise the IT security of a system by making use of vulnerabilities [20]. This method includes the way and resources needed to perform an attack. Attack vectors in IT typically involve malware and attack methods, like Denial-of-service, when attacking the digital attack surface. The vulnerabilities determine the attack vectors, which are changing over time since tech-nologies are developing, and some vulnerabilities disappear while new ones come up. Attack vectors usually involve software or code when attacking the digital attack surface while attack vectors on the social engineering attack surface involve human manipulation methods [20]. Attacks nowadays begin often by exploiting vulnerabilities on the social engineering attack surface, which gives an attacker direct access to the target or, at least, access to a deeper level of the system that opens up a way for further attacks. A typical procedure of an attack is that an attacker determines the target, explores its vulnerabil-ities, determines an attack vector, gets access to the system and performs the intended actions [21]. Common attack vectors nowadays that exploit vulnerabilities on the digital attack surface include malware, phishing, man-in-the-middle attacks, DoS-attacks, SQL injection, drive-by attacks, and password attacks [22].
1.2
Problem formulation
The aim of this project is to determine whether virtual environments or physical envir-onments are more resilient against attacks that exploit vulnerabilities that occur by nature or unawareness in these environments. In order to achieve this aim, a theoretical analysis will be conducted as well as a virtual and a physical environment that are comparable will be implemented to answer the following research questions:
1. How could "resiliency against attacks" be measured? 2. What are the attack vectors of the virtual environment? 3. What are the attack vectors of the physical environment?
After having answers for these questions, attacks that are feasible to perform will be executed alongside theoretical research. The resiliency against attacks is expected to be higher in the virtual environment than in the physical environment as a result of the increased security assumed from a centralised design.
1.3
Motivation
Since the expansion of virtualisation as a technology in general, the concerns regard-ing vulnerabilities in virtual environments have increased. Some vulnerabilities are con-sidered to be real problems while others appear to be more theoretical. This project should provide an objective statement on whether the widespread belief that virtual environments are more resilient against attacks than physical environments is accurate or not. Addition-ally, this project intends to emphasise the more relevant vulnerabilities. The results of this project could increase the awareness of system administrators regarding the security of virtual and physical environments as well as influence the design of enterprise IT envir-onments. Indirectly, there could also be an impact in society if the companies that possess user data have fewer exploitable vulnerabilities.
1.4
Objectives
1. Develop a scoring system to measure resilience 2. Implement a virtual and a physical environment 3. Identify the relevant attack vectors for this project
4. Run experiments or research to evaluate the resilience of both environments against the attacks
5. Comparison of the scores
1.5
Scope and limitations
Events that compromise security by accident, such as unpredictable hardware failure, or natural disasters will not influence the results, meaning these scenarios are out of the scope of the project.
Attacks that involve no or insufficient encryption, weak passwords, social engineering or are caused by misconfigurations will not be evaluated since they do not to make a difference in either environment or are well-known vulnerabilities that are not expected in a reasonable scenario.
The small size of the networks in the testing environments is a limitation that needs to be taken into consideration. In more extensive networks or networks that have more hops, the latency or other derived implications of network size could result in a different outcome. The results of the experiments take this limitation into account.
1.6
Target group
Since virtualisation is mostly used in business, the target group of this project is com-panies. However, students, scientists and those who are interested in virtualisation could also benefit from the results of the project considering that virtualisation is becoming a more widespread technology and could raise awareness regarding virtualisation security. Furthermore, researchers and students could also use the project as a baseline for further research.
1.7
Method
2
Experiments
This section contains information about the establishment of the test environments as well as the realisation and outcome of the experiments that were run in the test environments. The literature research performed will not be part of this section, but will be found under the corresponding attack vector in question in section 3.2.
2.1
Test environments
The test environments consist in two individual environments; the virtual environment and the physical environment. Although some entities could not be kept the same in both environments (such as virtual entities), both of these environments were kept as similar as possible. The following subsection is given to provide a better understanding of the results. Since a difference in hardware would not translate into different results (as long as it performs the same function), it was not important to have specific equipment for the environments. This hardware was provided by the university and was primarily chosen based on availability. The test environments were modelled and configured according to currently existing technologies that could be used in a corporate environment.
2.1.1
Virtual environment
The virtual environment consists of four physical entities (Virtual machine server, file server, network switch and thin clients) and five virtual entities (hypervisor, pfSense, Linux bridge, PXE server and Windows 10 OS), which can be seen in Figure 2.1.
2.1.1.1 Hardware This section provides information about the hardware used in the virtual environment for this project.
2.1.1.1.1 Virtual machine server Hardware-wise, the virtual machine server is an IBM x3850 X5 with four Intel Xeon X7550 (totalling to 32 cores) and 380 GB of DDR3 RAM. The storage for the virtual machines consists of two 140 GB SAS drives and two 70 GB SAS drives. These drives were combined using ZFS in striped mode, which is similar to RAID 0. ZFS was chosen due to the support of striping with drives of uneven sizes. The server itself is connected to the outside switch with two statically assigned IP addresses. One of them will allow connectivity to the Internet via the LNU network, while the other will be used for management.
2.1.1.1.2 Network switch The switch that manages the traffic of the network is a single Netgear GS724Tv2, which was configured simply as described in section 2.1.1.2.3. 2.1.1.1.3 File server The file server is an IBM X3850 M2 with two Intel Xeon E7330 (totalling to 16 cores) and 125 GB of DDR2 RAM. The storage consists of four 70 GB SAS drives where three of them are configured in a ZFS pool and the fourth is used to hold the operating system for the file server. This server is connected to the virtual machine server via a network bond, which is used to share the ZFS pool. This server is also connected to the outside network via the switch. The usage of this server is to store templates that have been made for easy deployment in Proxmox as well as to store the disk image that the PXE server virtual machine uses to boot. Therefore, without the file server, the virtual environment would a have limited functionality.
2.1.1.1.4 Thin clients The thin clients that are connected to the internal network are five Dell Latitude E7440 with 8 GB of DDR3 RAM and an Intel Core i5-4300U. The laptops were used for booting over the network using PXE without needing a hard disk. 2.1.1.2 Configuration This section provides information about how the hardware ex-plained previously was configured for the virtual enironment.
2.1.1.2.1 Virtual Machine server Software/configuration wise, the operating sys-tem of choice for virtualisation is Proxmox VE 6.1.3 with Linux 5.3.10-1-PVE. The vir-tual machine server is running a total of seven virvir-tual machines and one Linux bridge. Each entity has a specific purpose as described followingly:
VLANs in the switch. PfSense acquires an IP address over DHCP (172.18.8.0/23 subnet) and acts as the DHCP server for the 192.168.1.0/24 subnet, which means any devices connected to the inside VLAN could receive an IP address from this DHCP server if requested. PfSense will also act as a DNS resolver for the Inside network to facilitate the task of using remote desktop to the virtual machines. 2. Windows 10 VM These virtual machines use Windows 10 Pro as an operating
system. There were no changes done to the default configuration except for the enablement of Remote Desktop and hostname change. The hostname of each ma-chine was changed to WindowsX, where X is the number of the user ranging from one to five, respectively. The network interfaces used for the machines are para-virtualised VirtIO devices, which were chosen for performance reasons. The only extra piece of software installed was the SPICE guest package since it would render a more responsive experience when accessing the virtual machines over Proxmox. If any extra program is installed for a specific experiment, it will be mentioned in the respective section.
3. PXE Server is a virtual machine running Ubuntu Server 18.04 set up with a TFTP server, HTTP server, and an NFS export. The function of this server is to enable PXE booting for any machine connected to the Inside network.
4. Linux Bridge The Linux bridge in the virtual environment acts as a virtual switch between the virtual machines. All Windows 10 machines, the PXE server, and the firewall are connected to this bridge. PfSense possesses an internal bridge that con-nects its port to the Inside network with the Linux bridge. In conclusion, all virtual machines connected to the Linux bridge are indirectly connected to the inside net-work of the firewall, allowing them to access the Internet and request DHCP leases. 2.1.1.2.2 File server The file server is running Debian 10 Buster with Linux 4.19. An important part of the server is the network bond, which is set up using four GbE ports configured in round-robin mode between itself and the virtual machine server. There are two main downsides of using round-robin in the virtual environment. The first downside is that there is no real redundancy provided by the bond in case of failure. However, this downside is not critical since the bond is not an integral part of the network and could easily be replaced. The second downside of using round-robin is the lack of order for packets in TCP connections since a large number of out of order packets will lead to a large number of re-transmissions. In spite of these issues, the bond can peak to three Gb/s of throughput, which is more than enough for the purpose of the file server. For even better data transfer performance, especially for the ZFS share, the bond was configured to use jumbo Ethernet frames of 9000 bytes.
2.1.1.2.4 Thin clients The thin clients have all been set up for network booting using the PXE server described in 2.1.1.2.1 and shown in Figure 2.1. Due to their ability to boot over the network, they do not require the installation of an operating system on the local hard disk. The OS of choice for the thin clients is ThinStation OS, which has been configured to have only VNC, SPICE and RDP protocols installed. Other items such as web browsers, word processors, and other applications have been removed to ensure a more minimal thin client installation that could minimise the attack vectors of the machines.
2.1.2
Physical environment
Figure 2.2: Physical environment setup diagram
2.1.2.1 Hardware and configuration This section provides information about the hardware used in the physical environment and how it was configured.
2.1.2.1.1 Firewall The firewall in this environment is a Cisco ASA 5510 Adaptive Security Appliance running at Software Version 8.2.5 and Device Manager Version 7.8.2 where Ethernet port 0/0 is configured for the inside network (192.168.0.0/24) and Ethernet port 0/1 is configured for the outside network (172.18.8.0/23 DHCP). It acts as a DHCP server and provides a pool of addresses for clients on the internal network if necessary. Port address translation was activated for the outside interface.
2.1.2.1.2 Network switch The switch used in the physical environment is of the same type as the one used in the virtual environment, the Netgear GS724Tv2 24-Port Gigabit Ethernet Smart Managed Pro Switch with 2 SFP Ports. All entities in the physical environment are interconnected via this switch.
2.1.2.1.3 Fat clients All five clients used in the physical environment are of the same type, the Dell Latitude 7400 with Intel Core i5-8365U 1.60GHz CPU, 16 GB RAM and Windows 10 64-bit OS. All machines have local user accounts configured and are connected to each other and the Internet via the switch.
2.2
Attack surfaces and vectors of the environments
The physical attack surface of a virtual environment is typically smaller than that of phys-ical environments since its entities tend to be more concentrated. Virtualisation techno-logies make it possible to consolidate entities on one or more powerful physical entities and therefore allow to focus security measures on only some specific locations [24]. This makes it easier to protect such an environment since the physical attack surface is nar-rowed down and possible entry points are better protected. On the other hand, if an attacker manages to break into the heart of a virtual environment, which is the location of the virtualisation server, the impact on this environment is devastating.
Offices of companies that have a virtual environment, which contain thin clients, are considered to be less protected against physical attacks since they contain less sensitive items like physical hard drives. Protection measures are typically focused on the location of the Virtual machine server, where also other servers and firewalls are placed. This location is, therefore, better protected against physical attacks than any other location.
Entities in the physical environment that would be typically found in an ordinary office of an enterprise are fat clients. Offices in physical environments need additional protection measures in comparison to offices in virtual environments since physical hard drives are attached to the fat clients and not consolidated in a better protected area. Therefore, security measures cannot be concentrated on essential locations like server rooms, which makes these more vulnerable against physical attacks compared to server rooms in virtual environments.
The most significant difference between the digital attack surfaces of both environ-ments is that in the virtual environment, there exists a hypervisor as a core entity. Another notable difference is that in a virtual environment, there are more entities in general that could possibly be attacked.
2.3
Experiment realisation
This section contains the realisation of the attacks that were feasible to perform in the set up test environments. The contents for each experiment will be logically subdivided into the individual realisation of each experiment, followed by its outcome. More information about each attack vector tested can be found in their respective sections under section 3.2
2.3.1
ARP poisoning
In the following experiment, one of the machines for each environment was considered as some sort of server. Theoretically, this could be a simple server such as a web server, or a more elaborate service.
Wireshark [26] was installed in both the attacker’s machine and virtual machine/fat client that was now considered a server. Some sort of traffic had to be generated in order to see which of the machines received it. Therefore, it was decided that another machine in the network would ping the supposed server. Before starting the experiment, each machine in the respective environments that was supposed to initiate the ping had its ARP table cleared to obtain clearer results. Wireshark was run on the supposed servers as well as the attacker’s machine to see which one was receiving the ICMP packets. Once ping was executed, results for the test prior to the attack were recorded. Followingly, the attack was launched, and the same procedure was executed without clearing the ARP table. It was decided not to clear the ARP table to verify that the attack would still work even when having different IP addresses in the table for a single MAC address.
If the supposed server had been receiving ICMP echo requests after the attack’s exe-cution, the attack would have failed. However, if the attacker’s laptop had been the one receiving the ICMP echo requests, then the attack would have succeeded.
Figure 2.3: Configuration for Metasploit in the physical environment
ARP poisoning experiment outcome The outcome for this experiment was somewhat expected but also resulted in some consequences that had not been predicted. Prior to pinging, it was verified that the ARP tables of the machines were cleared for better read-ability.
Figure 2.4: ARP table of the pinging machine before the attack
As seen in the second entry of the ARP table shown in Figure 2.4, the MAC ad-dress (10-82-86-00-D1-05) of the supposed server can be seen alongside its IP adad-dress (192.168.0.253). This was identical in the virtual environment with the respective IP addresses and MAC addresses. When pinging the supposed server from the test machine (192.168.0.12/192.168.1.9 physical and virtual respectively), Wireshark on the server was receiving ICMP traffic, as can be seen in figure 2.5 and Figure 2.6. This behaviour could be reproduced in both environments.
Figure 2.6: ICMP echo request in the virtual environment prior to ARP poisoning Once the attack was run, it could be seen how the ARP tables had changed. In the physical environment, there were now two IP addresses that were bound to the same MAC address. The IP address (192.168.0.253) that was previously matched to the supposed server’s MAC address (10-82-86-00-D1-05), was now being matched to the MAC address (EC-F4-BB-61-60-94) of the attacker’s NIC. This information can be seen in the ARP table in Figure 2.7 and the attacker’s MAC address in figure 2.8.
Figure 2.7: ARP table in the physical environment after the attack
Figure 2.9: ICMP packets intercepted by the attacker’s laptop in the physical environment In the physical environment, there were no visible or noticeable signs of an ongoing attack except for the large amount of ARP packets that could be seen with Wireshark. In the virtual environment, the outcome was slightly different and somewhat unaccounted for. As soon as the attack was run, the remote desktop connection from the thin client to the Windows 10 VM that was being attacked froze. This behaviour is due to the RDP traffic being redirected to the attacker’s laptop rather than the actual virtual machine. Once this happened, it was evident that there was an issue with the network, which could prompt further investigation.
2.3.2
DHCP spoofing
Figure 2.10: Rogue DHCP server using Ettercap GUI
Since the results Ettercap provided were considered doubtful, the same test was per-formed with the DHCP server found in Metasploit, which was configured similarly to the implementation in Ettercap. Metasploit was more configurable than Ettercap since some implied arguments in the latter could be manually specified in the former. For ex-ample, Ettercap would automatically imply that the gateway for the network would be the attacker’s machine, whereas Metasploit allowed this parameter to be changed as can be seen in Figure 2.11.
Ettercap was picked as the tool of choice due to its faster deployment. In order to improve the results of the attack in either machine and to confirm the previous results, DHCP exhaustion was executed prior to running the rogue DHCP server, which improved the results. For each test, all the leases were released from the clients and cleared from each firewall respectively to ensure that no IP addresses were reserved.
DHCP spoofing experiment outcome The initial results with just Ettercap were of about 50% success rate. In order to check whether the attack had succeeded or not, the lease’s gateway option had to be verified. If the gateway’s IP address was still the one of the firewall, the attack had failed and the real DHCP server had been the one to lease that IP. If the gateway indicated the rogue laptop’s IP address, the attack had succeeded.
In the physical environment, half of the computers at a time received an IP address from the environment, and the rest received a lease from the rogue server. This was later repeated with Metasploit to ensure that this was the correct outcome and not caused by the tool in use.
In the virtual environment, the outcome was slightly different. The thin clients some-times received a lease from the rogue server, making them fail to boot since they could not find the PXE server. If they received an IP address from the legitimate server, PXE would succeed. However, when the thin operating system loaded, it would request another IP address over DHCP. This was either be answered by the rogue server or the legitimate server. In this scenario, the machine received two IP addresses in total, one from the le-gitimate server (since PXE succeeded) and the other from either the rogue server or the legitimate server.
In the virtual environment, the Windows 10 virtual machines would always receive an IP address from pfSense. Using Figure 2.1 as a reference, the position of the Windows 10 machines in the network is the explanation for this behaviour. When the OS requested an address, the firewall would always receive the broadcast packet sooner than the rogue server. This behaviour is due to its direct connection to the Linux bridge where the vir-tual machines were connected to. By the time the rogue server received the request and answered, the Windows 10 machines had already received an answer from pfSense. This behaviour would also explain why some machines accepted the lease from one server and not the other. The lease offer that reached the machine first was the one to be accepted.
With this information, DHCP starvation (see section 3.2.6.3) was run first to ensure no IP addresses would be available from the legitimate server. As expected, all the machines, both in virtual environments and physical environments, received an IP address from the respective rogue DHCP servers.
2.3.3
DHCP starvation
The experiment for DHCP starvation was executed against the firewalls since they were in both environments the entities that ran the DHCP service. The attack was performed al-most identically in both environments since all needed was an Ethernet connection within the inside network the DHCP server was running on. In the virtual environment, one of the thin clients was substituted for a rogue laptop identical to the thin clients running Kali Linux. The tool used to perform the test was Yersinia, which can perform a DHCP starvation attack. In the physical environment, the same rogue laptop as in the virtual environment was used by connecting it into an available port in the switch. In both scen-arios, Yersinia was run for one minute to ensure that as many IP addresses as possible were exhausted from the respective firewalls. A screenshot of Yersinia running can be seen in Figure 2.12.
Figure 2.12: Yersinia exhausting available IP addresses
was checked to see whether the lease file was full or not. Figure 2.13 shows what the DHCP lease table of the ASA 5510 looked like.
Figure 2.13: DHCP leases for DHCP server running on ASA 5510
Indirectly, this attack could also lead to a CAM table overflow on the switch since each new MAC address that is registered would imply a new entry in the table.
DHCP starvation experiment outcome The only similarity in the experiment outcome for this attack between the environments was that the machines that had a leased IP ad-dress could still receive that adad-dress with no issues and machines that did not previously have an address leased would fail to receive one.
3
Results
This section will hold the findings of the research. It will first present the scoring sys-tem developed to evaluate the results followed by an explanation of the implemented test environments with their properties. Subsequently, the relevant attack surfaces and attack vectors will be explained and evaluated respectively.
3.1
Scoring system
One of the objectives of this project was to develop a scoring system to evaluate the resiliency of environments. For this reason, this section is under the results section (3) rather than the method section (1.7). The scoring system consists of one resiliency score (RS) for each environment per attack vector. Each attack vector will possess a difficulty score and an impact score both, ranging from zero to three for each environment. A score of zero will represent no impact or a lower relative difficulty, while a score of three will represent a high impact or a higher relative difficulty. A score of one and two will represent a low and medium impact or medium relative difficulty, respectively. The difficulty score measures how difficult it is to perform a specific attack, whereas the impact score indicates how devastating that attack would be.
The values for the difficulty score will not be absolute, but relative to one another. For example, if the difficulty to perform an attack vector is the same in both virtual and physical environments, the scores will stay zero. If the difficulty is slightly higher in one of the environments, that environment’s difficulty score will raise to one or more depend-ing on how big the difference is, whereas the other one will stay zero. This relationship is kept relative to one another since it is not feasible to determine the difficulty based on individual factors, such as configuration, due to the large number of different ways an en-vironment can be set up. Keeping the scoring relative allows the difficulty to be measured using arguments that are more general and less implementation-specific.
The impact score is an absolute score, where zero implies no impact at all and three implies a large impact. This score can be absolute since it is easy to evaluate the outcome of an attack. For example, if a network switch stops working, it can be concluded that ma-chines connected to said switch will not be able to communicate with one another through that switch. This loss might lead to a different impact depending on the environment.
Some attack vectors might not necessarily have an impact. For instance, accessing a room or connecting to a network does not have any impact since neither confidentiality, integrity nor availability have been compromised by these actions. Some attack vectors may need other attack vectors as a requirement, leading to the formation of a chain. For example, stealing a hard drive from a machine has as a requirement getting access to that machine in the first place, which could have a different difficulty score depending on the environment in question. Removing the hard drive itself, which would be the second attack vector in this chain, will also have a difficulty score as well as an impact score.
In case of having a chain of attack vectors, the total resiliency score (TRS) will be the sum of each resiliency score respective to the environment.
number. However, this is not an issue since the values for each environment will still be able to be compared with one another. The higher the resulting number is, the more resilient the environment is.
The general formula for calculating the TRS for each environment is:
T RSenvironment= (DSavx− ISavx) + (DSavx+1− ISavx+1) + ... + (DSavn− ISavn) (1)
Where:
• T RSenvironmentis the total resiliency score of an attack vector chain for an
environ-ment
• DSavx is the difficulty score for the attack vector at position x
• ISavx is the impact score for the attack vector at position x
• x indicates the first attack vector • n is the last attack vector in the chain Which could be simplified into:
T RSenvironment = RSavx + RSavx+1 + ... + RSavn (2)
Where RSav would be the resiliency score of a given attack vector.
The following example, based on the scores found in Table 3.1, will be a calculation of the TRS for the physical and the virtual environments where the attack vector chain is composed of two attack vectors.
Environment (AV1) (AV2) DS IS DS IS Physical Environment 0 0 1 1
Virtual Environment 3 1 0 2 Table 3.1: Example table for the scoring system
The difficulty scores of the first attack vector (AV1) show that relative to the physical environment, the virtual environment has a higher difficulty. Once again, the difficulty score is not absolute, meaning that the virtual environment is regarded as more challen-ging to perform by three points. There is no impact when performing the attack vector in the physical environment; therefore, the impact score is zero. There is a small impact in the virtual environment resulting in a score of one, which leads to a higher impact in the virtual environment. The same logic is repeated with the second attack vector for both scores. In order to calculate the TRS of the physical environment the following operation has to be performed according to the formula:
T RSpe = (0 − 0) + (1 − 1) = 0 (3)
whereas for the virtual environment
T RSve = (3 − 1) + (0 − 3) = −1 (4)
As can be seen, the T RSpe has a higher value than the T RSve, meaning that the
phys-ical environment is considered more resilient against this specific attack than the virtual environment.
3.2
Score determination
Each environment possesses entities that can either be unique to that environment or exist in either of them. Each entity can contain vulnerabilities that can be exploited by one or more attack vectors. These attack vectors will be listed under each entity.
The attack vectors for the project are chosen based on research on the most common attack vectors for each entity, where those attack vectors that did not meet the criteria according to the scope and limitations were filtered out.
3.2.1
Switch
The switch is an entity that can connect multiple devices with one another by forwarding the traffic to its respective physical port [29]. It possesses a physical attack surface and a digital attack surface.
In order to tamper with a switch or disrupt its function in a similar way, physical access is required. It is assumed that the switch being considered in the results is not one located within a server room, but rather one located in a switch room where thin clients or fat clients can be connected for network access. The difficulty required to access one of these rooms would be lower than the difficulty needed to access a server room.
The attack vectors for this entity are the following: 1. Physical Destruction
3.2.1.1 Physical destruction The physical destruction of the switch requires a break-in of its location. Both the theft of a switch and the destruction of a switch would result in the same outcome. There is no other information required to explain the attack. The resulting scores can be seen in Table 3.2.
Environment Break Into Location Destroy Switch
DS IS DS IS
Physical Environment 0 0 0 1 Virtual Environment 0 0 0 2
Table 3.2: Result table for the destruction of a switch This attack vector chain starts by accessing the location of the switch.
Since the switch is assumed to be in the same respective physical location in both environments, there is no difficulty difference between them. The impact score for ac-cessing the location is zero in both environments since just acac-cessing the location is an obstacle and does not have any impact at all.
Once in the premises of the switch’s location, destroying the switch is equally as easy since the same action can be taken in both environments.
Finally, the impact score for destroying the switch varies depending on the ment. For the physical environment, the impact score is 1. Since the physical environ-ment’s fat clients have their own operating system with existing usable software, they do not rely as heavily on the network as they do in the virtual environment. In the virtual environment, thin clients rely more on the network due to their need for services such as network booting or remote control. Without network access, thin clients are rendered un-usable due to the lack of access to these services. The virtual machine server, the storage and other main entities are still functional and have not suffered disruption. Therefore, the impact is medium but not devastating. The resulting TRS values are:
• T RSpe = −1
• T RSve = −2
Since the TRS is higher in the physical environment respective to the virtual environ-ment, it is considered more resilient.
This attack requires access to the switch, which could be obtained by swapping one of the already existing clients with network access with the rogue laptop of the attacker. Performing a CAM table overflow is relatively trivial since any Ethernet frame with a MAC address that does not exist in the table will make the switch register a new entry in it [31]. When the destination MAC address is not in the table, which could occur if the table is full and cannot register more MAC addresses, the switch will output the packet on every other interface that is configured on the same VLAN [31]. Since the entries expire after some time if they are not updated [31], all the devices, including those that were previously registered, would fail to be added to the table as long as the attack is ongoing. When the switch acts as a hub, any frame whose destination is unknown by the switch will be broadcast. The attacker will then be able to sniff some traffic that is meant for other machines [32].
In a physical environment, where switches have a limited space in the table due to memory restrictions, the clients that were previously connected and registered will not be affected by the attack as long as their entries are not removed due to timeout. It is assumed in the physical environment that the CAM table can be overflown before the switch auto-removes unused entries due to its memory limitations. Since the switch will only broadcast the frames it does not know the destination of, the attack will only work for the traffic of the machines that did not manage to get their MAC addresses registered on the table prior to the attack [32].
This scenario for a virtual environment is different since in it, there can be physical switches and virtual switches. For this scenario, it is assumed that the virtual switches are in the form of Linux bridges since they are popular, simple, and have been used for a number of years [33]. The base scenario for a CAM table overflow in the virtual environment is similar to the one in the physical environment with the main difference being that the only traffic flowing to and from the thin clients is remote connection traffic or insensitive traffic.
Environment Access Network CAM Overflow
DS IS DS IS
Physical Environment 0 0 0 1 Virtual Environment 0 0 0 0
Table 3.3: Result table for CAM table overflow
In order to access the network, the difficulty is the same in both environments since the access to the network would be performed the same way. Once more, the impact of accessing the network is negligible. The difficulty to perform a CAM table overflow is also the same in both environments due to the pre-existing network connection. When looking at the impacts of the attack, there is a difference depending on the environment. In the physical environment, the impact score is considered one since the attack could likely successfully sniff some sensitive data. The impact score is not any higher because the attacker would only be able to sniff traffic from devices that have not been registered in the switch’s CAM table prior to launching the attack.
In the virtual environment, the situation is slightly different. Once the physical switch’s table has been overwhelmed, the traffic with an un-mapped destination would also be sent to the virtual bridge, which would cause it to add an entry into its forwarding database, too. However, since the virtual switch holds its database in memory, it is reasonable to assume that it can hold more entries than the physical switch due to the difference in memory size. Unless the attacker could update older forged entries constantly to prevent their deletion, the entries would be removed by the virtual switch before the memory could be exhausted. A consequence of a CAM table overflow in the virtual environment would be a reduced performance caused by the increase of the number of entries in the list. Although the performance might reduced, the switch would still act according to its functions and forward traffic only to the respective destination with negligible effect. The attacker would not be able to receive any traffic that travels in between the virtual machines and the gateway, but only traffic from remote control tools that travels between the overflown switch and the location of the thin clients. The resulting TRSs are:
• T RSpe = −1
• T RSve = 0
Since the values of the physical environment are lower, it is considered less resilient for this attack vector chain.
inappropriate MAC address, which is usually the attacker’s, will be bound to the real IP address in the network, allowing the traffic intended for a specific IP address to reach a different computer. Although first-party and third-party mitigations exist against ARP poisoning, they can require constant maintenance or an economic investment [35].
Based on the experiment, the resulting scores for the ARP poisioning can be seen in Table 3.4.
Environment Access Network Poison ARP Tables
DS IS DS IS
Physical Environment 0 0 0 3 Virtual Environment 0 0 0 1
Table 3.4: Result table for ARP poisoning
For this attack, it is assumed that the machine being attacked in the virtual environment is accessed to by a stateful connection like SSH or RDP. Starting with the first attack vector, as usual, there is no difference in difficulty when accessing the network. Once more, the actual network access has a negligible impact on the network. Therefore, the impacts for both environments are zero. Moving onto the second attack vector of the chain, the difficulty in performing the attack is also equal since executing the attack would be performed the same way in both environments with no differences. The impact scores of this attack vector differ based on the environment they are performed in.
In the physical environment, a man in the middle (MiTM) attack based on ARP spoof-ing is not noticeable in plain sight, makspoof-ing it more difficult for suspicion to arise. Low or no suspicion can be dangerous since the attack could be performed undetected for a long time, allowing a large amount of data to be intercepted. In the virtual environment, where there is a higher dependency on the network and stateful connections play a big role due to remote access, the attack could be detected more quickly, resulting in fewer data avail-able for collection. The importance of availability and confidentiality hinges highly on the specific purpose of the environment. However, in scenarios that do not require an extreme level of availability, it is arguable that a lack of confidentiality could present a higher risk for an environment. Having taken all this into consideration, the final TRS are:
• T RSpe = −3
• T RSve = −1
Once more, since the T RSve is higher than the T RSpe, the virtual environment is
con-sidered more resilient.
3.2.2
Firewall
its intended functions. Since firewalls have a higher meaning for the security of a network, their physical accessibility is usually more impended and more restricted than other net-work devices. Although vulnerabilities that can be exploited exist on the digital attack surface of the firewall, they usually exist due to misconfiguration [37], which renders them out of the scope of the project. Since DoS is not an exclusive threat to firewalls, it will be discussed in section 3.2.6.2.
The attack vector for this entity is the following: 1. Physical Destruction
3.2.2.1 Physical destruction The attack chain of the physical destruction of the fire-wall does not differ from the attack chain of the physical destruction of the switch men-tioned previously, meaning there are no further attack vectors included. The resulting scores can be seen in Table 3.5.
Environment Break Into Location Destroy Firewall
DS IS DS IS
Physical Environment 0 0 0 1 Virtual Environment 1 0 0 2
Table 3.5: Result table for destruction of the firewall
Firewalls are located in areas with higher security measures, like servers rooms. Due to the fact that security measures in virtual environments can be concentrated on less locations, it can be assumed that server rooms in virtual environments are harder to access and better protected than server rooms in physical environments. Therefore, the difficulty score for breaking into the location of the firewall is 1 for the virtual environment and 0 for the physical environment. Since there are no differences for destroying a firewall in either environment, the difficulty score for that attack vector is 0 in both environments. However, the consequences are different. Although the clients in a physical environment have no connection to the Internet anymore, they still can communicate among each other and their local applications can still be used. In the virtual environment, however, the virtual machine would be inaccessible due to the fact that the firewall is an interface between the thin clients and the virtual machines. If the firewall is out of function, the connection is interrupted and although the virtual machines themselves are not affected and still operational, they are of no productive use. The TRSs are:
• T RSpe = −1
• T RSve = −1
3.2.3
Storage
Storage is not equally physically located and the data is accessed in different ways in both environments, making it of relevance to this project. Since fat clients contain local storage, potentially valuable data for an attacker may be present. Furthermore, since fat clients are usually not congregated in one specific location, there is a larger physical distribution of the data that they hold. Although physical environments could make use of storage servers, the local drives of the clients might still contain information that could be misused. In virtual environments, there is no necessity for the thin clients to have local storage. Consequently, all the storage can be located in a single location with enhanced physical security. On the other hand, a single location for the storage also results in a single point of failure for it.
The attack vector for this entity is the following: 1. Storage Theft
3.2.3.1 Storage theft Storage theft would have the same basic implication of physic-ally destroying a drive. If no backups are kept, availability is compromised since the data can no longer be accessed. However, the destruction of a device makes its data unreadable by conventional means while the theft of a drive could additionally lead to a confidenti-ality compromise. With these implications taken into consideration, the resulting scores can be seen in Table 3.6.
Environment Access Storage Location Take Drive
DS IS DS IS
Physical Environment 0 0 1 1
Virtual Environment 3 0 0 3
Table 3.6: Table for the theft of a main storage device
span. For this reason, it is considered that the difficulty in removing the drives is slightly greater in the physical environment.
In both environments, there is a shared impact of storage theft that exists due to the possibility of a data breach. However, there would be a larger immediate impact in the virtual environment since the loss of a small number of drives could result in the loss of all virtualised entities due to failure, which would be devastating. In the physical environment, the theft of one storage device would result in the loss of data for only that device instead of multiple. The resulting TRSs are:
• T RSpe = 0
• T RSve = 0
Since the T RSs are the same in both environments, there is no difference in resiliency.
3.2.4
Clients
This part will include relevant attack vectors for the fat clients as well as the virtualised operating systems. Thin clients will not be considered unless there is an attack vector found that involves them. This can be justified since thin clients do not hold valuable data that could be interesting for an attacker and have a low economic value in comparison to a fat client. Therefore, the physical attack surface is reduced. The minimalism of the software and lack of functionality compared to a fat client allows the digital attack surface of thin clients to stay minimal as well [38].
The attack vector for this entity is the following: 1. Malware
3.2.4.1 Malware Malware is a broad term to describe software made with a malicious purpose. It is usually used to cause damage to data or access different systems and net-works without authorisation [39]. The broadness of the term malware and its implications make it difficult to determine a generalised outcome of the resiliency of each environment. However, there are two important threats that exist only in the virtual environment which are namely VM sprawl and lack of visibility [40]. These threats could have a relevant impact on how malware infects a machine.
Lack of visibility Due to the fact that many virtual environments are not monitored properly, a lack of visibility in virtual environments exists regarding network traffic and other communications such as VM-to-Hypervisor [40]. The lack of monitoring in virtu-alised environments could result in an unauthorised exit of sensitive data from the envir-onment as well as unnoticed attacks within the virtual network [40].
After the consideration of these two threats, the scores are as shown in Table 3.7.
Environment Client Infection Payload Execution
DS IS DS IS
Physical Environment 1 1 0 1 Virtual Environment 0 2 0 2 Table 3.7: Result table for malware in general as an attack vector
The difficulty score of infecting a client in the physical environment is considered slightly higher than the difficulty score of infecting a client in the virtual environment. Although the clients in the physical environment have is a higher level of accessibility that could become an entry point for malware, it makes the clients more visible. A higher level of accessibility and visibility favours the actions of patching and updating machines to reduce the vulnerabilities malware could use to infect the machine. By contrast, the probability of finding a client that is vulnerable to malware is higher in the virtual envir-onment than in the physical envirenvir-onment due to VM sprawl.
The impact of malware infection is considered slightly higher in the virtual environ-ment than in the physical environenviron-ment. As a consequence of VM sprawl, a number of vulnerabilities could be present that would allow specific malware to spread over the net-work within the virtual environment. There is still an impact in the physical environment since at least one client has been infected, but the likelihood of spread is regarded lower, rendering a lower impact. Once a machine is infected, the difficulty to execute the payload is considered equal in both environments.
The final impact score for payload execution is higher in the virtual environment than in the physical environment. In the physical environment, there is a higher visibility that could allow malware to be detected faster than in the virtual environment, where the visibility is regarded to be lower. Once more, due to VM sprawl and the implied higher number of possible vulnerabilities, the malware in question could have a more devastating effect by making use of said vulnerabilities. The scores are the following:
• T RSpe = −1
• T RSve = −4
Since the T RSpe is higher than the T RSve, the physical environment is considered
3.2.5
Hypervisor
As mentioned already in the introduction, the hypervisor is the software to create and host virtual machines. Therefore, it is the heart of the virtual environment whose security is essential. Protection measures against unauthorised physical and digital access are required since its control would allow an attacker to access all virtual machines, including sensitive data on them [25]. For this reason, controlling the hypervisor would be the ultimate goal for an attacker.
The attack vector for this entity is the following: 1. VM Escape
3.2.5.1 VM escape VM escape is a security issue where code that is executed inside a VM manages to exit the trapped premises of a VM and run in the host machine [40]. True VM escape attacks distinguish themselves from other VM escape attacks by the independence of code execution. For true VM escape attacks, the potentially malicious code must only need to be executed in the virtual machine to be successful [40]. Although VM escape has been considered impossible and was purely theoretical in the past [40], it has successfully been performed in very specific systems [42]. VM escape is an attack that generally requires deep knowledge of the underlying hypervisor solution as well as very specialised code that can execute precise instructions to avoid an unwanted crash of the virtual machine [43].
Since there are no unique paths to perform a VM escape attack, just like malware, it is difficult to determine general overall steps to perform the attack as well as arguments to evaluate the resiliency. Despite the evaluation difficulty, VM escape is an attack vector that relies on the existence of a hypervisor, a layer that is inexistent in the physical envir-onment. This can make the evaluation much simpler since there is no comparison possible and exclusive positive or negative effects can be assumed from it. Based on the inform-ation by [43], [42] and [40], it can be concluded that there are three general steps for a successful VM escape and subsequent control of the target, which is the host machine. The results can be seen in Table 3.8.
Environment VM Access/Hijacking VM Escape Code Execution Host Privilege Escalation DS IS DS IS DS IS P.E ∅ ∅ ∅ ∅ ∅ ∅ V.E 2 1 1 3 3 3
Table 3.8: Result table for VM escape as a general attack vector
malware to gain control of the virtual machine. The impact score for hijacking the ma-chine is not zero since the mama-chine could contain sensitive information. In addition to that, a hijacked machine could lead to other attack vectors such as resource exhaustion [44]. The difficulty to execute the code that will allow VM escape is the hardest score to determine. An argument can be made that all the code required for the execution of the attack vector has been tested prior to the attack and is guaranteed to work. However, due to the complexity of the code required and the high risk of damage to the virtual machine [43], a small difficulty score is added to take into account the setbacks that could occur. The impact of executing code resulting in VM escape is very high not only because of its implications, but also the instability the execution could cause in both, the virtual machine and the hypervisor.
In the last attack vector, the difficulty score to perform privilege escalation is highest. This score can be justified since performing VM escape would only allow the inspection of low-level communications between a machine and the host, which exist as CPU instruc-tions and interrupts [43]. These restricinstruc-tions can difficult the action of running successful code for privilege escalation.
Finally, the impact for having full control of the hypervisor and the host is devastat-ing. Once there is full control of the host, data theft, denial of service, and many more attacks could take place since the virtual machine server is arguably the heart of the virtual environment. The resulting TRSs are:
• T RSpe = ∅
• T RSve = −2
Since there is no T RS score for the physical environment, the virtual environment is considered less resilient.
3.2.5.1.1 Physical access to the hypervisor Achieving physical access to the hy-pervisor enables an attacker to perform a large number of attacks. Besides physical de-struction or manipulation, an attack called Hyperjacking would also be possible. In Hy-perjacking, an attacker would install a rogue hypervisor to take over the whole system, including the virtual machines [45]. Everything in layers above the rogue hypervisor is unaware of said hypervisor’s existence. However, there does not seem to be a general agreement on the term hyperjacking, leading to sources with contrasting information.
Although the consequences of an attacker gaining physical access to the hypervisor would be critical, it is unlikely to happen owing to the high levels of difficulty involved in accessing such a room.
3.2.6
Network
where the information processing happens. This dependency is different in a physical en-vironment, where the amount of traffic is in general not as high as in a virtual environment and more information processing happens locally.
The attack vectors for this entity are the following: 1. DHCP Spoofing
2. Denial of Service 3. DHCP Starvation
3.2.6.1 DHCP spoofing Due to the nature of L2 network switches, the broadcast do-main is not separated as long as it has not been split with the use of VLANs [46]. By exploiting the nature of switches, a rogue DHCP server can be launched and configured to listen to all the DHCP requests that are being broadcast over the same broadcast do-main. Such a rogue DHCP server in the network could be used as a baseline for a number of man in the middle attacks such as DNS spoofing or the gateway traffic interception. An experiment was performed for this attack.
The results shown in Table 3.9 take the experiment into consideration.
Environment Access Network Spoof DHCP
DS IS DS IS
Physical Environment 0 0 0 2 Virtual Environment 0 0 0 1
Table 3.9: Result table for DHCP spoofing with gateway redirection
Although DHCP starvation could change the outcome, it is assumed in this attack chain that DHCP starvation was not used. It is also assumed that the network is of a large enough size to allow earlier responses from a DHCP server closer to the victim’s machine. Another assumption is that the default behaviour for the rogue DHCP server is to redirect all gateway traffic through itself and then route it to the legitimate gateway.
For the first attack vector, the difficulty score is zero in both environments. In order to access the wired network as an insider, the attacker would simply need to discon-nect any existing client and replace it with a rogue device. Accessing the network is not resource-intensive and would not result in any impact. Therefore, the impact score for both environments is zero. Running a rogue DHCP server on the network is equally diffi-cult in both environments once there is network access. The diffidiffi-culty could be affected if the network addresses were exhausted priorly with DHCP. However, since this is not the case, the difficulty to run the attack is the same in both environments.
