Cloud Computing: Insider Attacks on Virtual Machines During Migration .... 2013 12th IEEE International Conference on Trust, Security and Privacy in Computing ...
2013 12th IEEE International Conference on Trust, Security and Privacy in Computing and Communications
Cloud Computing: Insider Attacks on Virtual Machines During Migration Adrian Duncan, Sadie Creese, Michael Goldsmith Cybersecurity Group, Department of Computer Science, University Of Oxford, Oxford, UK, OX1 3QD {firstname.surname}@cs.ox.ac.uk
Jamie S. Quinton Flinders Centre for Nanoscale Science and Technology, Flinders University, SA 5042, Australia {firstname.surname}@flinders.edu.au
Abstract—The use of Virtual Machines (VMs) and Infrastructure-as-a-Service (IaaS) has risen dramatically and, according to Gartner, is set to continue rising with a compound annual growth rate predicted to be 41.7% over the four years to 2016. By using Cloud providers, organisations are reducing their capital expenditure on hardware, software and support, however, these same organisations are putting a great deal of trust in the provider offering a safe and secure platform for their data and resources. One of the biggest benefits of IaaS to the customer is the rapid elasticity of their provision. This elasticity can require relocation of a VM from one physical machine and / or one hypervisor to another. Whilst such migration is transparent and potentially seamless, it may also introduce vulnerability. We explore here the potential for a malicious insider to exploit vulnerabilities associated with mobile VMs to obtain large volumes of cloud-user data, and consider the possibility of detecting such attacks using current digital forensics and systems administration techniques.
rate predicted to be 41.7% over the four years to 2016. This emphasises the sheer volume of customer data being located with cloud providers. To a malicious insider, there is potentially great worth in obtaining copies of a VM or extracting information from a given VM. This is analogous to an intruder making a complete copy of one of your personal computer devices, for their own use and without your knowledge. This data can be harvested maliciously in a wide variety of ways, but to date no methods have been published that leave no forensic evidence and bypass all systems-administration detection techniques. Therefore it can be suggested that an insider attack aimed at obtaining copies of virtual machines is always detectable. The ideal scenario would be to detect attacks as early in the kill-chain as possible, either predicting an attack or detecting it in the early stages, since this minimises costs and actual exposure. Before we can hope to achieve this, we need to know what sort of attacks can be performed, how we can detect them and what measures we can implement to prevent their future use. We consider here the potential for insider attacks on VMs while they are mobile, the possible harm to security of VMs, and how useful existing digital-forensics and incident-response techniques would be in detecting such attacks.
Keywords: VMWare, VMotion, Insider Attack, Packet Sniffing, Unauthorised Cloning, Hostile VM Capture, Malicious Insider. I. I NTRODUCTION According to Carnegie Mellon’s CERT [3], the cloudrelated insider threat has three different perspectives: the rogue cloud-provider administrator, the employee in the victim organisation that exploits cloud weaknesses for unauthorised access, and the insider who uses cloud resources to carry out attacks against the company’s local IT infrastructure. We described a fourth actor in a previous paper [4]: Acid Cloud, where the cloud provider, itself, is the malicious actor, however, this paper focuses on the first of these types of insiders: the rogue cloud-provider administrator. Insiders in Cloud Computing environments potentially have access to an unparalleled amount of other organisations’ data. With Infrastructure as a Service (IaaS), customer data is housed in their virtual machine (VM), which is in the possession of the cloud provider. The provider can legitimately create copies and backups of a VM, delete VMs and, with service-level-agreement acceptance, login to a customer’s VM for administrative purposes. According to Gartner [7], the number of companies using IaaS is set to continue rising with a compound annual growth 978-0-7695-5022-0/13 $26.00 © 2013 IEEE DOI 10.1109/TrustCom.2013.62
The identification of methods to compromise a VM without any current method of detection would not be terminal for IaaS as a technology, but the use of IaaS in environments where sensitivity is very high would instantly become inappropriate without further development. The rest of this paper is organised as follows: Section II discusses existing research in this and similar areas; in Section III we describe our research method and process, then in Section IV we make our observations of the traffic that can be captured, and discuss the resultant attack vectors that we have identified based on these observations in Section V. In Section VI we discuss the process of packet sniffing, current detection methods and a proposed method of detection and future work on preventing packet sniffing. We then conclude in Section VII with our findings related to the initial hypothesis and discuss future work in Section VIII. 493
II. R ELATED W ORK
example [9], which illustrates that this is becoming more important as cloud take-up increases.
The authors have been unable to locate much published research on attacks on mobile VMs, let alone insider attacks in particular. However, in 2008, the topic of passive and active snooping of VM migration was discussed in a paper by Oberheide et al [11]. The paper focuses on active snooping using VMWare version 3 and Xen 3.1 and alters the contents of the VM as it passes the sniffer. The paper demonstrates a successful ssh attack on the compromised VM. This attack vector would be very difficult to detect on a live migration (see section III-B2) as a hash is not possible while the machine state is still changing. The attacks presented in this paper are extremely difficult to detect, but may still leave a forensic trail. If the VM is powered off or suspended, a hash can be taken of the disk image file before and after the migration. If the hashes are not the same, as they would not be in one of the examples presented in the paper, then the contents of the VM were altered in some way during migration. If the contents were altered on a migration of a running VM, detection would be much more complex. No examples of passive-snooping attack vectors were presented, however. Shetty et al expand on this work in [13], with five attack vectors identified: denial of service (disabling a hypervisor), internal attacks (compromising the hypervisor or other guest VMs), guest VM attack (gaining control of a VM), false resource sharing (attracting migration to a compromised or malicious hypervisor), and inter-VM attack (attacking a sibling VM). They suggest four ways to secure the VM in transit. The first is to use a VLAN for each VM. While this would offer an increase in security, they point out that the complexity of this mechanism, once the number of VMs grows, is too great to make it practical. They then discuss a special hypervisor known as the Network Security Engine Hypervisor (NSE-H) and role-based migration. The paper does not discuss whether this has been implemented in any of the major hypervisors yet, and it is unclear what types of attack it would protect against. The last option discussed is a Virtual-TPM-based migration protocol. They point out that this protocol doesn’t support live migration, which makes it incomplete for current Cloud environments. The paper concludes by saying that there isn’t currently an approach that addresses Trust Establishment, Confidentiality and Integrity of migration data, Authentication and Authorisation of migration operations, which is necessary for secure migration and that a framework that addresses these security aspects of live migration of virtual machines is still needed. It is clear that the topic of how to prevent or detect harm to mobile VMs requires further consideration. Despite the lack of direct work on detecting insider attacks at the cloud provider, there is an increasing amount of work on examining cloud- computing-oriented forensics, for
III. T HE P ROCESS Prior to identifying migration as a key source of exposure to attack, we examined both low-technology and hightechnology methods of attacking a VM to obtain customerdata without being detected. We examined ways that a variety of attackers could use to compromise a VM to see whether there were any ’low-hanging fruit’ that were available for an insider with a relatively low level of technical ability or knowledge. However, we are seeking to identify methods of attack which are not detectable: this rules out most (if not all) of these methods. We then progressed on to more sophisticated approaches that would be within the ability of support staff with a greater technological knowledge or within the capacity of an insider to perform using a set of detailed instructions. A. Low-Technology Attacks Initially we examined some of the more simple methods of compromising a VM, which are achievable by a variety of insiders. An obvious method of obtaining a virtual machine’s data would be to make a duplicate, then boot that duplicate either on the same hypervisor or on a hypervisor in a remote location. Making duplicates using the hypervisor however, will leave audit trail entries on the hypervisor making it easy to discover that a VM has been compromised. One could copy the datastore of a VM using the Datastore Browser in VMWare. This would have the effect of looking like a backup was made and therefore might fit in with the established modus operandi of the provider. The actions carried out using the datastore browser are all logged and this log can be monitored in real time using scripts to detect such events. This form of attack would be detectable as it happens making it highly overt. One can access the datastore server directly, for example by iSCSI or USB connections to the Network-Attached Storage (NAS) storage location. Connections via iSCSI and USB are logged by the NAS and often this facility for USB must be manually enabled, making this an easily detectable action in a well run network. If USB access to the NAS is not needed, this can be manually unplugged by systems administrators, further reducing the opportunity for unauthorised access. Additionally, the NAS could be assigned a VLAN which is available to a limited number of computers, which are configured based on specific need. By restricting the access to the NAS to the servers that specifically require it, the opportunity for this type of attack is minimised. If one were to copy a Virtual Machine’s configuration files and datastore on a Windows machine, link (.lnk) files are made detailing the duplication with its source and destination [14]. In addition to the link files, Windows records
494
serial numbers of external memory attached to the operating system. With these two techniques, a file that is copied can be traced back to the originating machine, user account and destination media together with the date and time that it was copied. Although a user can delete these link files, there will still be a forensic trail, potentially for years. As the link files are generally under 10kB, they are unlikely to be overwritten at the byte level for some time after deletion. The malicious insider would have to install a program, such as Eraser [2] to make it impossible for deleted space to be recovered. The malicious insider could also FTP or use a cloud storage account to transfer the upload the files to another server, from where they can be downloaded and accessed at a later date. The use of outgoing FTP or cloud server access can be monitored by the systems administrators who can terminate transfers of certain file types, or lengths. Linux can also easily record system events, such as file copy and FTP commands. One of way of achieving this is the central recording of shell history entries. This makes it extremely difficult for an insider to copy individual files or a VM without leaving evidence, which is ideal for the owner of the VM and the security auditors of the provider. Alerts can be created to detect these commands as they are entered to allow system administrators to intercept these attacks as they happen. At the operating system level, most actions that a malicious user can perform can be traced using existing system administration and forensic analysis techniques. Depending upon the security policy of the provider, simply plugging in a USB memory stick may be enough to alert the security staff to a planned attack, which can be prevented before it is executed. If a user wants to compromise a VM without leaving easily detectable clues, they will need to approach the attack from another perspective.
because it was felt that it would be more, or less, vulnerable than other hypervisors. Software Windows XP Professional Ubuntu Wireshark ESXi Server VCentre Server VSphere Client VMotion
Version V2002 Service Pack 3 10.04 LTS W32 1.6.6 5.0.0 Build 469512 5.0.0.3324 Build 472350 5.0.0 Build623373 as above
Table I V ERSIONS OF ALL SOFTWARE USED IN TEST SYSTEM .
The setup is outlined below using the last octet of their IP address as a reference. • Cisco Catalyst 3560 switch. • Two ESXi servers (101 and 102) were set up on dedicated computers. • A windows XP machine (103) was created with VSphere Client installed. • A VCentre server (104) was created on 101. • A Windows XP (105) and an Ubuntu 10 (106) VM were created using the VCentre machine 104 called xp1 and ubuntu1 respectively. • The datastores were located on two iSCSI servers (130 / 140). • The entire network is switched. Port mirroring was setup on the switch to allow WireShark (running under Windows XP on 103) to receive packets with minimal packet loss. The port being mirrored could be altered to reflect the machine being monitored. 2) Method: The migration of virtual machines has three options. One can migrate the host files, the vmdk file (the datastore), or the two together. This last option is simply a combination of the former two, but requires the OS to be powered off: the former two can be done while the machine is powered up and being accessed. Live-migration facilitates the moving of the guest OS without it being powered down. The user of the VM can continue to use the VM as if migration is not taking place. The hypervisor creates a cache of events that occur, which is then used to update the VM in its new location. The benefit to this type of migration is that the user does not experience any down-time. Although most of the data of interest to an attacker resides in the hard-drive image in the datastore or in memory, we tested the three variations to see if an attacker could gain meaningful information from any of the three options. Using the VSphere client, the XP and Ubuntu virtual machines were migrated from 101 to 102 and back again with the traffic being analysed each time looking for information within the packet capture files that will be of value to malicious insiders. Extensive examples and specifics of the captures were not important to the identification of attack vectors. We did not set out to identify byte offsets, or hex-
B. Higher-Technology Attacks By their very nature, Virtual Machines require flexible storage and adaptive physical locations. A VM may require additional disk space or memory, which it may not be possible to be facilitate on the physical machine on which it currently resides. To accommodate this, the VM’s datastore or host files must be moved to a new physical machine. An attacker with a higher level of technological knowledge may use the network to attack a VM while it is in transit, thus removing the possibility of host-based detection. To test our hypothesis further, we wanted to test whether it would be possible for a VM be detected in the network datastream and its information captured using a packet sniffer. If so, what information can be extracted, how easily can this be achieved and can this attack be detected? 1) The Test Environment: The test setup used the latest versions of VMWare software available at the time (see table I.) VMWare was chosen for practical reasons and not
495
whether they could be harnessed by a malicious insider in order to compromise a VM. Several attack vectors can be identified however, which was sufficient for us to determine that the monitoring of network traffic is a very real risk for the security of VMs.
adecimal values that precede individual contents of interest within the VMs. Once an attack vector was identified, it was documented, we then sought to define the attack, determine its impact and whether we could detect that attack. To this end, we did not seek to replicate the attack on alternative operating systems as would be required for an actual attack. To aid detection of specific information during transit, a file was created on the xp1 desktop with the following contents:
V. R ESULTING ATTACK V ECTORS Some of the information observed presented clear opportunities for a malicious insider to harvest customer data. These are set out below.
this is a test file. the file is called test dot txt and is saved in the root of c
A. Clipboard With the contents of the clipboard obtainable in clear text, a malicious insider can monitor the movements of virtual machines and capture the contents of the clipboard. It is also not uncommon for people logging in to many systems to copy their password to the clipboard for rapid re-use, indeed several password programs offer this functionality. Whole images or documents may also be copied to the clipboard, which will now be accessible to the malicious insider. With each additional migration, more information can be obtained by the attacker. The potential for cascading attacks from the contents of the clipboard is very real.
In addition, the following text was saved to the clipboard: this text is on the clipboard
IV. O BSERVATIONS The following observations were made after several migrations: • The contents of the clipboard were seen in the captured file. Although the contents were separated by a null (0x00) byte between each character, the information is easily detectable (see Figures 1 and 2). The null byte could be due to there being space allocated for a UTF16 character, but a UTF8 character was present. • The contents of the VM’s log files were also sent and visible in the capture files with no padding between characters present. • Guest OS configuration files are present in plain text. • Installed programs on Ubuntu were listed together with their version numbers. • Magic number fields were seen in the capture files. • The entire contents of the VM’s configuration files were seen in plain text (vmdk, vmx and vmxf.) • The SSL certificate settings and whether the default certificate was still being used. • BIOS details, in this case Phoenix Bios, can be seen. • Website URLs that were visited on the VM were seen.
B. VM Cloning By capturing the configuration files during migration, an attacker can bypass command logging systems and forensic systems for detecting file access. The attacker have will now access without any current method of detection. The detection of the VM’s configuration files suggested a possible attack vector via making an unknown copy of the VM and accessing the target’s datastore. • The configuration files were saved out to new files and a new virtual machine was created on the same datastore and the same ESXi and iSCSI server. • The vmx file had several entries updated: displayName and extendedConfigFile were changed to the new VM’s name and ide0:0.fileName was changed to the full path of the target vmdk file (/vmfs/volumes/504db7b3-29fae1d7-a3a900218501d922/XP/XP.vmdk). • The vmxf file had one entry updated: vmxPathName was changed to point to the above file name. • The captured configuration files were uploaded to the datastore to override the newly created ones. • An attempt is made to power-up the newly created VM. VMWare detects that there is an issue with the vmdk file not being in the same directory. The user is prompted to say whether they moved it or copied it: the Copied option was selected. The boot terminates. • The new VM now uses the original VM’s vmdk file, which is detectable, so a clone of the new VM is
......K.’...t.h.i.s. .t.e.x.t. .i.s. .o.n. .t.h.e. .c.l.i.p.b.a.o.r.d...
Figure 1.
The raw view of the clipboard contents.
0077003B 00 00 00 00 00 00 00 00 09 00 4b 00 27 01 0c 00 ........ ..K.’... 0077004B 74 00 68 00 69 00 73 00 20 00 74 00 65 00 78 00 t.h.i.s. .t.e.x. 0077005B 74 00 20 00 69 00 73 00 20 00 6f 00 6e 00 20 00 t. .i.s. .o.n. . 0077006B 74 00 68 00 65 00 20 00 63 00 6c 00 69 00 70 00 t.h.e. . c.l.i.p. 0077007B 62 00 61 00 6f 00 72 00 64 00 00 00 00 00 00 00 b.a.o.r. d.......
Figure 2.
The hex view of the clipboard contents.
We then tasked ourselves with identifying attack vectors based on these observations. Not all of these observations have been translated into attack vectors as yet. There is still work to do on several observations in order to determine
496
made, which copies the new configuration files and the original vmdk file to a new location.
To test whether this attack vector was possible, we migrated one XP VM’s vmdk file to a new datastore and captured the traffic with Wireshark. The capture file was then moved via an unused USB memory stick to a Linux machine with the Photorec [6] file carving utility installed. Photorec processed the memory stick looking for magic number sequences to recover data. Photorec recovered over 2600 of the 8400+ files that were on the XP VM. To confirm that the files were from the VM and not already present on the new USB memory stick, the Linux strings command was run across all of the extracted files with the results piped to grep looking for the contents of the test text file located on the root of the c drive. The string “test dot txt” was found in a 200+ MB dll file. This illustrates that more files were present than were extracted and alternative and future versions [1] of file carving tools will produce additional files. This confirmed that files from the VM were extracted, and validated this mechanism as an attack vector. This attack would leave no trace since the files are being extracted from an unknown copy of the data. This process could be used to attack a single VM or simply monitor all VM traffic and parse the capture files looking for specific terms (rival political or religious organisation names or phrases) username or password information within files, or specific file formats (xls for accounts information or mdb for customer lists etc.) While the processing of the files is undetectable, the attack vector will only negate the hypothesis if the packet sniffing is undetectable.
This process creates a complete clone of the original. There is some access needed to the original vmdk file, which is the only link from the new VM to the original. As the log files are recorded for each machine, the only log trace of the copy is on the new VM. A check of the main log file (viclient) logs after the above process reveals no trace of the cross-VM link, although, there were traces of earlier unsuccessful attempts to perform the cloning. Once the insider has perfected this attack, the viclient log file will show no trace of the cross-VM link. This attack vector does require a new VM to be created in order to access the target VM datastore, which by its very nature leaves evidence. However, it is questionable whether this will be linked to an attack on a specific VM as the logs reveal only that a new VM being created and cloned. In a detailed audit, an explanation may be required to explain this new VM. This attack therefore, is at the bounds of the hypothesis. The process of creating and cloning a new VM in a highly populated hypervisor may be a highly common event and therefore may go completely undetected or unquestioned. The stealth element of this attack is only possible by the capturing of configuration files during migration. Once the malicious insider has a complete, and unknown, copy of the virtual machine they can recover data in a variety of ways. The most obvious method being to use software tools to compromise the administrator account, affording access to the virtual machine in its entirety. By disconnecting the network, the malicious insider will circumvent any client-installed software that could report the computer as active. Once compromised, the malicious insider can use brute force to recover encrypted data, or obtain user credentials for use in cascading attacks on other systems.
VI. PACKET S NIFFING A malicious insider could easily configure a switch to mirror traffic in and out of the hypervisor or ESXi server, but for the purposes of this document we are assuming that this would be detected via traditional means such as monitoring the switch’s log files. To conform with the null-hypothesis, the packet sniffer would have to be connected to the network without being detected by network administrators. One method to sniff traffic is a machine-in-the-middle attack. Machines A and B have their ARP configuration poisoned by C so that their traffic is routed through C and forwarded on to their destination [8]. If this method is used, the attacking computer will show in switch logs. Another drawback to using this method of attack is that ARP and ping can be used to trick a packet sniffer that is registered on the network into revealing itself [10]. One way to avoid this is for the packet sniffer to not be connected to the network in any way and eavesdrop on an existing wire. To test this, we split an ethernet cable and exposed the inner wires. While the cable was still connected to a live machine and the switch, the Transmit (green, and white with green stripe) and the Receive (orange, and white with orange stripe) wires were punched down into separate RJ45 terminator sockets, creating a t-piece for each, thus
C. File Carving Although the VM had a relatively small datastore size, we were not able to completely capture the 4-gigabyte files during their migration without packet loss. With migration over longer distances, one will expect slower speeds and lower packet loss in the captures making a full capture possible. We surmise that a malicious insider may also find it difficult to capture, complete datastore files on a local network. While extracting the configuration files, we noticed magic numbers [1] in the capture files, which reduced the impact of this problem. This suggested that other complete files inside the capture file could be detected using file carving techniques. This attack vector would be significantly easier than attempting to capture a large disk images reliably without packet loss, but would still yield a significant number of files from the guest OS.
497
creating a passive ethernet tap. This can also be achieved using a patch panel. The switch was being monitored during this process and showed no connection loss. Although this process is visible at the time of attack, the ethernet cable can replaced afterwards and taped back together with minimal visual clues that an attack took place. An insider is likely to be able to obtain the physical access needed with relative ease. The next step was to connect the new sockets to a computer with two ethernet cards, both being monitored using WireShark in promiscuous mode. In promiscuous mode, the WireShark machine will not attempt to register on the network. Should it try, this will be visible at the switch and alert system administrators that an unknown device is present. In order to ensure that the switch reports anything suspicious, the port-security settings on the monitored port were increased. The maximum connections was set to 1 and the mac address set to sticky. This means that the first network card that connects to a port, continues on that port even if a new machine gets physically connected to that same port. Any subsequent connection attempts will be refused and will be recorded in the switch logs. These settings were saved and tested to be functioning as desired. The computer running Wireshark was then connected to the t-pieces while the switch was being monitored. The switch did not display any error messages and Wireshark began to receive packets. This confirms that the packet sniffing can take place with the switch not being able to detect the presence of the machine attacked to the t-piece. We were then able to monitor all traffic on the chosen pair using the passive ethernet tap.
a paper by Sanai [12]. As outlined there, and in several subsequent papers, a special ARP packet can be created that deceives an OS running a packet sniffer in promiscuous mode into responding to the ARP request even though it shouldn’t. Using the settings for the ARP packet from the above paper, we tested whether this mechanism would still work using current operating systems. By creating an ARP request with a header that has an incorrect destination ethernet address field, the operating system processes the ARP request and replies to it, but only when the network card is in promiscuous mode. We successfully repeated the test using Windows XP. We then set the Windows XP machine to listen to the two ports set up with the wire taps and repeated the tests. The ARP packets were seen, and responded to, by the sniffing machine, due to a manually set IP address. However, because the Tx and Rx connections were on separate network cards, no actual reply was sent. This method of sniffing successfully defeated the published method of detection. The result was the same for the ping version of the test since it uses the same mechanism. C. Detection Using TDR The passive ethernet tap was not visible using conventional hardware or software detection methods. The only weakness in its method is the physical interference of the tap itself. In the communications industry, breaks and failures in underground wire cables have been a longstanding and expensive problem. This is due to the fact that the failure could occur anywhere along a cable that can often be many kilometres in length, and underground. A common method of detecting these faults is time-domain reflectometry (TDR). Time-domain reflectometry involves sending very short electrical signal pulses with very fast rise times down the faulty line (or light pulses in the case of optical fibre cables), and if the pulse reaches a point where any impedance mismatch occurs, then a ghost ’echo’ signal is reflected back towards the source (with a signal strength that depends upon the extent of impedance mismatch, thus open and short circuits provide the largest echo signals). It is, of course, for this reason that network cables and devices need to be impedance matched to the network to prevent loss of data integrity. Through timing how long it takes for the pulse’s reflection to return, multiplying that time by the speed with which the pulse travels down the line, and then dividing by two (there and back again) we can calculate the distance to the point of failure. Depending upon the electronic circuitry used to discriminate the reflected pulse from the background electrical noise, this occurs to within a rather small error margin and typically better than one part in 106 (1m in 1000km). In many respects, TDR is just like radar, sonar and the network ping facility [5]. A passive tap on any cable in the network will provide an open circuit (and thus a point for impedance mismatch)
A. Current Packet-Sniffing Detection Methods In a paper on network sniffing [10], three ways to detect the presence of a packet sniffer were presented. They were the Ping method, the ARP method, and the decoy method. The decoy method is to detect the use of stolen credentials, which were set up as a honeypot. Although this would be an effective method of determining a compromised system, it won’t necessarily indicate the presence of a packet sniffer and more importantly, won’t tell one where the sniffer is located. The ping and ARP methods at face value won’t work in this scenario as we do not register an IP address, however, we tested these methods to be sure. B. Detection Using ARP Using the setup described at the beginning of this section, we monitored both tapped pairs of cables, i.e. the Tx and Rx pairs of the machine generating the ping requests. The monitoring machine was able to see all of the ping request traffic on one ethernet card and the reply traffic on the other. A ping request was sent to the IP address of the sniffing machine, however, it did not respond on either network card. The ARP packet method mentioned above was based on
498
and can then, in principle, be detected by TDR. In order to determine whether the sniffer using a passive tap was detectable using TDR, we devised a set of tests using a dedicated TDR device for measuring (100-ohm impedance) Cat5 ethernet cables, the JDSU Validator Pro, and the TDR facility in the switch. In order to determine the tap’s detectability, we chose a 20 metre cable (as measured with a tape measure!) We then exposed the wires at 5, 10 and 15 metres along the cable to allow for measurements with the passive tap. Three cables (0.5, 2.5 and 20 metres) were then added to the tap and measurements taken to test whether the TDR or the switch could detect the existence of the tap and if so, how far long the cable it was located. The results of this study are shown in table II. The TDR unit reported a constant value from the default measurement for the untapped pairs of cables of 21 metres. The switch reported the default measurement +/- 1 metre in all cases except in test A, which reported 22 metres. The results show that the TDR unit recognises an issue with the cable in all cases. There were interesting variations in the results however, with it reporting a length of 5.5m for one pair and 22.5m for another pair along the same cable. The switch was not however, able to accurately detect all patches. The 0.5 metre cable patched in 5 metres from the switch and all cases of the 20 metre cable were detected. However, both of the 0.5 and 2.5 metre cables were either undetectable or within the normal tolerance of the switch’s ability to report in all other cases. A key drawback to this method of detection is that it can drop the connection to the host. Moreover, the tests sometimes showed a brief loss of connection while the TDR test was being performed. This could disrupt critical services to such an extent that the test is seen as counter-productive. This brief disconnect could also make the malicious insider aware of tests being performed to detect their presence. Based on the results below, the tap can be implemented so that it is effectively undetectable using the TDR that is builtin to the Cisco switch.
Test Case
Break Dist
Tap Cable Len
Main Cable
None
None
20m Cable
None
None
Small Cable A
None
None
5
0.5
B
5
2.5
C
5
20
D
10
0.5
E
10
2.5
F
10
20
G
15
0.5
H
15
2.5
I
15
20
Pair A B C D A B C D A/B C/D A B A B A B A B A B A B A B A B A B
Length Reported By TDR Unit Switch * Non NonTerm’d Laptop Term’d Laptop 22 20 21 20 21 20 21 20 22 20 21 21 21 21 21 20 1 0 0.5 0 22 5.5 21 5 21 22.5 21 5 23.5 5.5 20 20 22.5 24.5 23 20 46 5.5 4 24 44 22.5 5 24 21.5 23 21 21 21.5 22.5 21 20 22 23.5 25 21 22.5 22.5 25 20 21.5 24.5 32 32 21 22.5 32 32 22 18 19 22 21 17 20 21 23.5 18 36 20 22.5 24.5 35 21 45.5 18 39 36 44 24.5 16 37
* All values are reported with an error tolerance of +/- 4 metres.
Table II R ESULTS OF TESTS USING VALIDATOR TDR SWITCH .
TESTER AND
C ISCO
cables carry migrating VMs exist would be an adequate space in which to install and hide a dedicated computer such as this. A visual inspection is unlikely to detect a wellhidden instance and the device could be installed, executed and removed in a small time period. In order to visually detect this kind of device, a constant check would have to be performed on all cabling, which is highly impractical. One method of preventing the installation of such a device is to protect the cabling where it is not easily visible. One can use metal trunking of sufficient diameter to house a series of ethernet cables to protect them from being tampered with. Although this comes with a cost, the protection offered might be sufficient to guard against such attacks in areas of low/no visibility.
D. Mitigation Depending upon the level of access and technicalknowledge the malicious insider has, encrypting the data can keep it protected during transit. However, if the malicious insider has access to the encryption key, or if they can use social engineering to bound the number of choices, they can decrypt the traffic that is captured. Encryption therefore can have a positive effect on limiting most malicious insiders effect on the security of the data. A computer such as a Raspberry Pi could be installed in the smallest of spaces, 10cm2 and can be battery operated. Such a device would be sufficiently powerful to perform the passive ethernet tap and the attacks discussed in this paper and would be almost invisible in any server room, wiring closet, wall cavity or loft space. Anywhere that data
VII. C ONCLUSION In this paper, we have illustrated a variety of methods of attacking virtual machines, with the low-technology methods detectable by current network administration and computer forensics methods. We empirically demonstrated that packet sniffing can be used to extract a significant amount of valuable information from a virtual machine and highlighted several methods of achieving this. This is significant enough to flag migration attacks as a very real threat to the security and integrity of customers’ data.
499
We have argued that in all but one of the attack-vectors (the ethernet tap), packet sniffing, would be detectable in a perfectly run network. Of course, there are countless examples of networks that are not well run, and the cloud customer may not be able to determine which of these categories their provider belongs. A cloud provider operating without auditing and security checks would facilitate all of the attack vectors for the malicious insider, all of which would be undetectable by the customer. A malicious insider attaching a packet sniffer via a passive tap is a serious issue for a cloud provider due to the sheer volume of data that can be harvested and the difficulty of detecting it. The only way to detect such a device would be a visual inspection of the cabling, which in many cases will be impractical, and also may not be perfectly reliable. From a network-technological perspective, this attack is undetectable using current tools and confirms the null hypothesis. We assert that there is a real benefit in publicising the fact that digital-forensic techniques can be used to trace attacks in cloud-computing environments. The knowledge of this information may deter many potential malicious insiders from carrying out such attacks and may prompt cloud providers to perform additional checks on their systems.
R EFERENCES [1] L. Aronson and J. van den Bos. Towards an engineering approach to file carver construction. In Computer Software and Applications Conference Workshops (COMPSACW), 2011 IEEE 35th Annual, pages 368 –373, July 2011. [2] Olle Axelsson. Eraser. Online, 2008. http:// www.forensicswiki.org/wiki/Eraser Last Accessed 04 October, 2012. [3] William R Claycomb and Alex Nicoll. Insider threats to cloud computing: Directions for new research challenges. In Computer Software and Applications Conference (COMPSAC), 2012 IEEE 36th Annual, pages 387–394. IEEE, 2012. [4] A.J. Duncan, S. Creese, and M. Goldsmith. Insider attacks in cloud computing. In Trust, Security and Privacy in Computing and Communications (TrustCom), 2012 IEEE 11th International Conference on, pages 857–862, 2012. [5] Barry Duncan. Lecture notes: Incident and reflected waves. Unpublished, Dec 2007. [6] Richard Galpin. Photorec. Online, 15, July 2011. http:// www.cgsecurity.org/wiki/PhotoRec Last Accessed 6 September, 2012. [7] Gartner. High-tech Tuesday webinar: Gartner worldwide IT spending forecast, 2q12 update: Cloud is the silver lining. Online, 1 August 2011. http://www.gartner.com/resources/ 237700/237715/hightech tuesday webinar gar 237715.pdf Last Accessed 14 August, 2012.
VIII. F UTURE W ORK A. Additional Attack Vectors For some of the observations in Section IV, more work needs to be done in order to determine whether the information retrieved can be used effectively as an attack vector. The SSL certificate, BIOS information, guest OS and VM log files are prime examples.
[8] T. King. Packet sniffing in a switched environment. SANS Institute. August 4th, 2002. [9] Ben Martini and Kim-Kwang Raymond Choo. An integrated conceptual digital forensic framework for cloud computing. Digital Investigation, 9(2):71 – 80, 2012.
B. Detecting Passive Cable Taps
[10] A. Mathur, S.K. Sharma, and A. Mishra. Sniffing: A major threat to secure socket layer and its detection. In IJCA Proceedings on International Conference on Computer Communication and Networks CSI-COMNET-2011, number 1. Foundation of Computer Science (FCS), 2012.
One potential way to guard against passive ethernet taps is to improve accuracy and functionality of a switch’s TDR facility. We wish to perform more detailed assessment at the hardware level of current levels of detectability. With this knowledge, we can determine whether better TDR accuracy with a lower error tolerance will give the user improved detection of cabling attacks. If the switch can perform this monitoring automatically at a user-defined interval, error reports would be able to be monitored automatically, allowing greater security with minimal input from the systems administrators.
[11] J. Oberheide, E. Cooke, and F. Jahanian. Empirical exploitation of live virtual machine migration. In Proc. of BlackHat DC convention, 2008. [12] Daiji Sanai. Detection of promiscuous nodes using ARP packets. A white paper from http://www.securityfriday.com, 2002. http://securityfriday.com/promiscuous detection 01. pdf Last Accessed 25 February, 2013.
ACKNOWLEDGEMENTS [13] J. Shetty, M.R. Anala, and G. Shobha. A survey on techniques of secure live migration of virtual machine. International Journal of Computer Applications, 39(12), 2012.
The work reported here was partially supported by a doctoral training award from the UK Engineering and Physical Sciences Research Council (EPSRC) and by Lockheed Martin Corporation.
[14] A. Svensson. Computer forensics applied to windows NTFS computers. Stockholm’s University, Royal Institute of Technology, 2005.
500
