使用虛擬化偵察以強化核心虛擬機器的雲端平台 - 政大學術集成

全文

(1)國立政治大學商學院資訊管理學系研究所碩士論文 Graduate Institute of Management Information Systems College of Commerce National Chengchi University Master Thesis. 使用虛擬化偵察以強化核心虛擬機器的雲端平台 Securing KVM-based Cloud Systems via Virtualization Introspection. 研究生：李聖瑋 Master Student: Sheng-Wei Lee. 指導教授：郁方博士 Advisor: Fang Yu, Professor, Ph.D. 中華民國 104 年 6 月 June, 2015.

(2) 摘要. Linux 核心虛擬機器 (KVM) 在雲端運算生態系統內的基礎建設即為服務平台 (Infrastructure as a Service) 上是最熱門的虛擬化管理程序 (Hypervisor)。Linux 核心虛擬機器提供了全虛擬化的環境，包含虛擬化的 CPU，網路卡及主機板上的晶片，在 Linux 核心虛擬機器上面可以安裝異質的作業系統在虛擬主機裡面。我們提出了新的虛擬化偵察系統 (Virtualization Introspection System)，可以保護虛擬主機以及運作虛擬化管理程序的實體主機，儘管虛擬主機是運作在各種不同的虛擬化管理程序，虛擬化偵察系統可以保護虛擬主機與實體主機不被惡意的駭客攻擊。虛擬化偵察系統蒐集虛擬主機的動態及靜態資料來偵測及攔截惡意攻擊。我們使用了虛擬主機重現了各種不同的惡意攻擊，然後使用非監督的人工智慧學習技術來產生偵測規則。我們的虛擬化偵察系統也整合了雲端運算系統平台像是 OpenStack 和 OpenNebula。. 關鍵詞：雲端運算、資訊安全、虛擬化、惡意行為偵測. I.

(3) ABSTRACT Linux Kernel Virtual Machine (KVM) is one of the most commonly deployed hypervisor drivers in the Infrastructure as a Service (IaaS) layer of cloud computing ecosystems. The KVM hypervisor provides a full-virtualized environment that virtualizes as much hardware as possible, including CPUs, network interfaces and chipsets with KVM, where heterogeneous operating systems can be installed by Virtual Machines (VMs) in an homogeneous environment. We have proposed a new Virtualization Introspection System (VIS) to protect the host as well as VMs running on various hypervisors of cloud computing structure from malicious attacks. VIS detects and intercepts attacks from VMs by collecting their static and dynamic status. We then replay the attacks on VMs and utilize artificial intelligence derived from unsupervised learning techniques to derive effective decision rules. VIS can be further integrated with common cloud middleware, such as OpenStack and OpenNebula.. Keywords: Cloud Computing, Cybersecurity, Virtualization, Malicious behavior detection. II.

(4) Contents 摘要 .............................................................................................................................................................................. I ABSTRACT ................................................................................................................................................................ II CHAPTER 1.. INTRODUCTION ................................................................................................................................... 1. 1.1. NEW ATTACK THREAT IN THE CLOUD COMPUTING PLATFORMS ........................................................................................ 2. 1.2. TRADITIONAL ATTACKS .............................................................................................................................................. 3. 1.3. OBJECTIVE OF VIS .................................................................................................................................................. 12. CHAPTER 2.. RELATED WORK ................................................................................................................................. 13. 2.1. CLOUDBURST ATTACK BY VIRTUNOID – ATTACKING THE HYPERVISOR ............................................................................... 13. 2.2. MALICIOUS BEHAVIOR DETECTION ............................................................................................................................ 13. 2.3. VIRTUALIZATION INTROSPECTION .............................................................................................................................. 14. CHAPTER 3.. VIS ARCHITECTURE ............................................................................................................................ 18. 3.1. VIS ARCHITECTURE ................................................................................................................................................. 18. 3.2. VIS INTEGRATED WITH CLOUD HYPERVISORS .................................................................................................. 21. 3.3. MONITORING VM’S STATUS .............................................................................................................................. 28. 3.4. VIS DEFENSE OPERATION ........................................................................................................................................ 29. CHAPTER 4.. EVALUATION ...................................................................................................................................... 34. 4.1. THE EXPERIMENTAL TRADITIONAL ATTACK ................................................................................................................. 34. 4.2. EXECUTING AND RESULT OF THE EXPERIMENT .............................................................................................................. 39. 4.3. DRIVING DEFENSE AND RECOVERY RULES BY USING CLUSTERING TECHNIQUES ................................................................. 45. 4.4. DECTECTION .......................................................................................................................................................... 57. 4.5. DETECTING A CLOUDBURST ATTACK........................................................................................................................... 64. 4.6. THE EXPERIMENT OF A CLOUDBURST ATTACK .............................................................................................................. 66. CHAPTER 5.. CONCLUSION ..................................................................................................................................... 68. 5.1. CONCLUSION ......................................................................................................................................................... 68. 5.2. LIMITATIONS ......................................................................................................................................................... 68. REFERENCES ............................................................................................................................................................... 69. III.

(5) List of Figures and Tables Figure 1.1 Setting the openss1_heartbleed Scanner Exploit Module ......................................... 4 Figure 1.2 Using openss1_heartbleed Scanner to Dump Memory Content of the Victim ......... 5 Figure 1.3 Using openss1_heartbleed Scanner to Dump Private Key of the Victim .................. 5 Figure 1.4 Shellshock Manual Attack (no Metasploit) .............................................................. 6 Figure 1.5 cgi-bin settings of /etc/apache2/sites-available/default ............................................. 7 Figure 1.6 Content of test.cgi ...................................................................................................... 7 Figure 1.7 The Shellshock Vulnerability Scanner Settings ........................................................ 8 Figure 1.8 Shellshock Scanner Execution Result ...................................................................... 8 Figure 1.9 Shellshock Exploit Settings and Execution Result .................................................... 9 Figure 1.10 Architecture of VIS with Software and Hardware’s Relation ............................... 11 Figure 3.1 VIS Architecture ...................................................................................................... 18 Figure 3.2 Connected with KVM.............................................................................................. 22 Figure 3.3 Connected with VMware ESX ................................................................................ 22 Figure 3.4 Connected with VMware ESX via ssh .................................................................... 23 Figure 3.5 Connected with VMware Workstation .................................................................... 23 Figure 3.6 Connected with VMware Player ............................................................................. 24 Figure 3.7 Connected with Xen ................................................................................................ 25 Figure 3.8 Connected with VirtualBox ..................................................................................... 25 Figure 3.9 Connected with OpenVZ ......................................................................................... 26 Figure 3.10 Script of Checking the Type of Hypervisor .......................................................... 27 Figure 3.11 The strace command .............................................................................................. 28 Figure 3.12 The qemu-monitor command ................................................................................ 28 Figure 3.13 Monitoring VMs status .......................................................................................... 29 Figure 3.14 VIS Defense Operation.......................................................................................... 30 Figure 3.15 The Traditional Attack in the Cloud ...................................................................... 31 Figure 3.16 Migrating the VM into a sandboxed host .............................................................. 33 Figure 4.1 Period Attacking - Hacker VM................................................................................ 39 Figure 4.2 Period Attacking - Victim VM ............................................................................... 40 Figure 4.3 Period Normal - Hacker VM ................................................................................... 40 Figure 4.4 Period Attacking - Normal VM ............................................................................... 41 IV.

(6) Figure 4.5 Period initial Normal VM ........................................................................................ 41 Figure 4.6 Initial Period - Hacker ............................................................................................ 42 Figure 4.7 Attack period – Hacker ............................................................................................ 42 Figure 4.8 Initial Period – Victim ............................................................................................. 43 Figure 4.9 Attacking Period – Victim ....................................................................................... 43 Figure 4.10 Attack Setting Period – Hacker ............................................................................. 44 Figure 4.11 GHSOM Analysis Result ...................................................................................... 45 Figure 4.12 973 Files in the GHSOM Analysis Result ............................................................. 46 Figure 4.13 Detailed Summary in System Call ........................................................................ 47 Figure 4.14 Class No. 11, 18, 23............................................................................................... 48 Figure 4.15 Classified Data of Class 11.................................................................................... 49 Figure 4.16 Classified Data of Class 23.................................................................................... 49 Figure 4.17 Classified Data of Class 18_2................................................................................ 49 Figure 4.18 Upper Bound Calculator ........................................................................................ 50 Figure 4.19 Attack and Recovery Rules ................................................................................... 51 Figure 4.20 The Formula to Calculate Run-time Data with the Mean ..................................... 51 Figure 4.21 Data from Rule 47_2 ............................................................................................. 54 Figure 4.22 Data from Rule 33 ................................................................................................. 54 Figure 4.23 Data from Rule 65_4 ............................................................................................. 54 Figure 4.24 Reaction Rules of Each Detection Rule and Recovery Rule ................................. 55 Figure 4.25 Attacks Detected by Rule 11 ................................................................................. 58 Figure 4.26 CVE-2013-0431 Java Applet JMX Attack Detected by Rule 23 .......................... 58 Figure 4.27 SET-Web-Java-Applet Attacks Detected by Rule 18_2 ....................................... 59 Figure 4.28 CVE-2014-0160 Heartbleed Attack Detected by Rule 18_2 ................................ 60 Figure 4.29 CVE-2014-6271 Shellshock Attack Detected by Rule 18_2 ................................ 60 Figure 4.30 Rule 65_4 Detects a Compromised VM ................................................................ 61 Figure 4.31 Rule 47_2 Detects a Compromised VM ................................................................ 62 Figure 4.32 Rule 33 Detects a Compromised VM .................................................................... 63 Figure 4.33 The Second Timer ................................................................................................. 64 Figure 4.34 Rebuild the Attack VM ......................................................................................... 65 Figure 4.35 PIIX4 Chip Being ”unplugged”............................................................................. 67 V.

(7) Table 1 Rules of Period of Attacks for the Hacker ................................................................... 52 Table 2 Mean and Upper Bound of Rules for the Hacker VM ................................................. 53 Table 3 Rules by Period of Attacks for the Victim VM ........................................................... 53 Table 4 Mean and Upper Bound of Rules for the Victim VM ................................................. 55 Table 5 All Detection Rules ..................................................................................................... 57 Table 6 Rules and Detectable Attacks ...................................................................................... 61 Table 7 Rules and Detectable Compromised Machines ........................................................... 63. VI.

(8) CHAPTER 1.. INTRODUCTION. In the era of cloud computing [ 1], security threats are a major stunning block. Cloud computing environments are usually multi-customer platforms. If a hacker takes control, they have access to information about numerous customers and providers served by this platform, rather than single users in a desktop environment.. If an attacker compromises a cloud computing platform, it may be quite costly to repair and recover important data both server side and for end users. Customers may bill their losses when cloud services are unavailable, especially since most cloud service providers have service-level agreements (SLA) with their customers. An even larger problem results from personal information exposure, including contacts and credit card information, may cause additional economic impact. So VIS is an implementation for those concerns descripted above.. There's an open source cloud computing platform called OpenStack which can be driven by various virtualization hypervisors, either by using open source hypervisors such as Linux Kernel Virtual Machine (KVM), Xen, OpenVZ and VirtualBox, or by commercial ones such as VMWare. The features of it include monitoring different hypervisor VIS using virtualization API communicating with cloud computing platform such as OpenStack and OpenNebula, and controlling the Guest OS (Virtual Machine). Due to the integration with cloud computing platforms and hypervisors, we suppose VIS is a very valuable cloud computing platform security protection, no matter for detection of attacker VM or attacked VM. A supplementary research about Security Issues in Cloud Computing [ 37] mentioned that virtualization is crucial in order to organize and share geographically distributed resources as a resource pool.. We can describe several types of attack on the cloud computing platforms, such as: . Attacking the hypervisor: Attacker can gain host privileges via vulnerability of host from a guest.. . Attacking guest VMs from another VM: Attacker can crack another guest in the same cloud. environment.. 1.

(9) . Attacking VMs from the outside: Attacker can crack a guest from outside of the cloud. environment.. One common technique is a social engineering attack, where hackers exploit known/unknown software defects, e.g. certain JAVA vulnerabilities (e.g. CVE-2013-0422, CVE-2013-0431), Adobe Flash vulnerabilities (APSA13-01, APSB13-01, APSB12-24, APSB13-02), and Windows vulnerabilities (ms08067) to hack the VMs on a cloud computing platform. Another way is directly exploiting the cloud computing platform’s vulnerability. These attacks can be initiated from the outside.. Similar to attacks from outside cloud computing platforms, threats can come from within, particularly through a public cloud. When a hacker has a VM in the same cloud deployment, it is easier for one to discover the network environment and hypervisor settings of this particular cloud deployment. The hacker can use tools such as “traceroute,” “nmap” and “nessus” to find vulnerabilities in other customers’ VMs and exploit them. One can then detect the hypervisor’s environment settings.. Furthermore, compromised VMs can be used in a pivoting attack. If a VM has been compromised, even if said VM has no sensitive data itself, it can still be used as a jumper to enable the hacker to perform further pivoting attacks against hypervisors and VMs of the cloud deployment and beyond. After the compromised VM has been compromised, the hacker is able to add the subnet and routing table of the compromised VM into the “Metasploit [ 23]” framework, upload tools such as “nmap” and “backdoor” to scan the VMs in the same subnet, and ultimately control it.. VMs are running in the cloud, in which there are many cloud computing platforms using KVM as a hypervisor to drive each VM running the cloud computing platforms. The role of KVM is to virtualize each device, such as the mother board, CPU, RAM, hard drive, network interface card, system timer, and even a virtual network. On the host, every VM is running as a KVM process, so VIS can use debug tracing tools and a VM device monitor (qemu-monitor) [ 3] to monitor each VM .. 1.1. New Attack Threat in the Cloud Computing Platforms In 2011, a new attack on cloud systems, presented by Elhage, used bug CVE-2011-1751 and. Virtunoid [ 8] to break into KVM and take control. This bug makes KVM unable to check the 2.

(10) virtualization of PCI devices, and makes it unclear if the device is unplugged. KVM fails to omit the guest machine users’ request to unplug the device that does not support an unplugged status. This means when VM unplugs such a device, KVMs may not clean up and disconnect themselves, leaving some mistakes behind, like pointers.. On the other hand, when I replay this attack and monitor the VM’s device, one can then use that data to protect the cloud environment from being attacked by Virtunoid. VIS is an aggressive, real-time monitoring mechanism. If we use a non-real-time protection, like SWADR, it will be useless in the face of Virtunoid. VIS expects to achieve efficiency, precision and transparency. This cloudburst attack can be used on cloud middleware such as OpenStack [ 31], Eucalyptus [ 6], RHEV, OpenECP [ 25], and others.. 1.2. Traditional Attacks Typically a hacker would use tools including Social Engineering Toolkit (SET) to launch an attack. such as a social engineering attack. For example, one can utilize a website attack vector via Java Applet method to cheat an unexpected victim, tricking them into clicking on a malicious link on a website or in an email. Other viable attack methods could include new JAVA vulnerabilities (e.g. CVE-2013-0422, CVE-2013-0431), employed by a hacker who uses a “Metasploit” during Oracle’s patch delay. These two attacks are negative attacks. First, a hacker would setup the attack function in his own VM. Next, after setting the desired attack period, the hacker would then start sending malicious links to the victim. There are several ways this could be done. Posting the malicious links on Facebook or other social networking websites, sending them to the victim via email, or posting the links in a public forum are all viable methods for this type of attack.. In early 2014, an information disclosure vulnerability of OpenSSL library was disclosed. OpenSSL is a cryptographic library for secure sockets layer toolkit. It has an information disclosure caused by improper handling of Heartbeat extension packets in the TLS/DTLS heartbeat functionality. A remote attacker can exploit this vulnerability by sending specially-crafted packets to trigger a buffer over-read, which allows an attacker to read system memory contents of a remote HTTPS server with any authentication and authorization. By reading the system memory, an attacker can obtain cookies, private keys and other sensitive information. This Open SSL vulnerability is dubbed “Heartbleed,” with a 3.

(11) corresponding CVE number of CVE-2014-0160. This Heartbleed vulnerability not only affects the HTTPS server side, but also the client side. WE can call this a ‘reverse’ Heartbleed, where an attacker can setup a malicious HTTPS server to read system memory of clients by sending malicious heartbeat packets to the target client.. I reproduced the Heartbleed attack by using the Turnkey Linux WordPress virtual machine (Turnkey VM). Turnkey VM is based on Debian wheezy, turnkeylinux.org provides a .vmdk virtual machine file. For this experiment I used the qemu-img tool to convert a .vmdk image file to a .qcow2 image file for KVM. After a simple installation, the vulnerable environment was setup. I used Metasploit to execute the Heartbleed exploit “openss1_heartbleed,” where the Metasploit command is seen below.. Figure 1.1 Setting the openss1_heartbleed Scanner Exploit Module. At first, I use the openss1_heartbleed scanner to test if a victim is vulnerable. As you can see in the figure above, there is only one exploit module option, RHOST is required, but for a successful attack, I have to setup other module options, such as FORCE_EXPLOIT and VERBOS AND ACTION, as seen in the figure below.. 4.

(12) Figure 1.2 Using openss1_heartbleed Scanner to Dump Memory Content of the Victim In this example, RHOST is needed to set as the victim’s IP, FORCE_EXPLOIT is needed to set for force attack the victim, VERBOS sets as true, and ACTION is set as DUMP to dump the victim’s memory content. Then the exploit can be executed. As you can see above if we setup the ACTION as dump, Metasploit will directly dump memory content of the victim as the figure shows below.. Figure 1.3 Using openss1_heartbleed Scanner to Dump Private Key of the Victim 5.

(13) If we set ACTION as KEYS, the Metasploit will show you the victim’s private key and save as a .txt text file.. In 2014, one of the biggest vulnerabilities of bash was discovered by Stephane Chazelas, referred to as CVE-2014-6271. The bash through 4.3 is vulnerable, which caused a wide range impact on Linux and Unix distribution including Mac OS X. It allows a remote attacker to execute malicious commands on the system because there’s no proper validation on the exported instance functions of shell when using an environment variable. Since bash can be used as a parser for CGI scripts on a web server, the vulnerability can be triggered by sending specially-formatted request using environment variables like ‘() { :; };’. This vulnerability is commonly dubbed Shellshock, with the CVE number of CVE-2014-6271. An attacker can thus use privileges of a web server such as www-data to perform malicious behaviors, for example, using a copy of setuid bash to steal ssh private key/public key on the target system by using ‘() { :; }; ’ environment variable (i.e. () { :; }; cat /root/.ssh/id_rsa), using hping3 to perform SYN flood denial of services attack (i.e. () { :; }; -S --flood –V <target IP>), and viewing the /etc/passwd file from the target server (i.e. () { :; } cat /etc/passwd), the example of Shellshock for viewing /etc/passwd file is shown below.. Figure 1.4 Shellshock Manual Attack (no Metasploit). 6.

(14) Moreover, there is a functional Metasploit exploit that allows an attacker to use linux/x86/meterpreter/reverse_tcp as the payload, embed a backdoor, and further take over the control right.. Here is how I reproduce the Shellshock. At first, for preparing a vulnerable environment we use the Metasploit2 for experiment, where the Apache web server service has been activated on Metasploitable2. By checking the default configuration file /etc/apache2/sites-available/default in the subsection of /cgibin/, it shows I can put my .cgi file in the /usr/lib/cgi-bin/ directory, as the figure below demonstrates.. Figure 1.5 cgi-bin settings of /etc/apache2/sites-available/default. I made a simple .cgi file on the victim and named it test.cgi, the content is shown below.. Figure 1.6 Content of test.cgi. After this setup I can start to use Metasploit framework on the Kali Linux, in the following figure I will show you the attack command of Shellschock. Before attacking the target victim (IP is 192.168.126.139), let’s use the Shellschock scanner to test if the target is vulnerable. In this example, there are some module options needed to be setup, such as RHOST, LHOST, HEADER, METHOD, PATH, TARGETURI and RPORT, for RHOST needed to set as victim’s IP, LHOST is needed to set as the Attacker’s IP, HEADER set as User-Agent, METHOD set as HTTP GET, PATH set as /bin and RPORT is the Apache web service default port 80 as the figure shows below.. 7.

(15) Figure 1.7 The Shellshock Vulnerability Scanner Settings After the setup, I used the ‘exploit’ command to execute ‘apache_mode_cgi_back_evn’ vulnerability scanner as shown below.. Figure 1.8 Shellshock Scanner Execution Result As shown in the figure above, the ‘apache_mod_cgi_bash_evn’ exploit successfully scanned the target victim, as showing in the result of www-data user account has uid 33 displayed on the system.. 8.

(16) Figure 1.9 Shellshock Exploit Settings and Execution Result After I confirmed that victim is vulnerable, the ‘apache_mod_cgi_bash_env’ exploit can be used for Shellshock attack, as the figure shows above. These are almost same module options needed to be setup, and as the result of the attack you can see the hacker is using Meterpreter to control the victim and list the system information by using the ‘sysinfo’ command.. In 2015, a fundamental GNU C library (glibc) had a serious vulnerability is vulnerable to a buffer overflow. The reason for this is because there is not proper validation on the gethostbyname() and gethostbyname2() functions. This vulnerability does not affect IPV6 because of the above mentioned functions do not support IPV6. To satisfy the vulnerable environment, the FCrDNS is required on the client side (hacker). Moreover, to trigger this vulnerability, one must send a malicious request with a specially-crafted host name, one that only uses “.” at the beginning and without “.” at the end of the host name. A remote attacker could attack this vulnerability to overflow a buffer. Thereafter, they could execute an arbitrary code on the victim system. This vulnerability is also dubbed GHOST, the CVE number is CVE-2015-0235 assigned for this vulnerability. Because this vulnerability is not easy to be triggered, I didn’t produce the vulnerability, but it can be reproduced by using Metasploit.. 9.

(17) In addition to a social engineering attack, DoS/DDoS attacks and active attacks that would use a Windows vulnerability, such as ms08_067_netapi or ms12-020, are ways in which a hacker can set the payload as a meterpreter. The meterpreter can first take a screenshot of the target, then the “ps” command can list running processes in the target. The “migrate” command can then be used to transfer the payload to another running process to prevent the payload from being deactivated. The “shell” command can provide a command prompt in the meterpreter, where you can then add an account in the victim’s name. Another method of intrusion is by utilizing a command prompt, such as “use priv”, to upgrade account privileges to administrator, then by activating the “run persistence” command, the hacker can inject an agent of the meterpreter to ensure that after the target system reboots the backdoor still remains open.. In this paper we have two mechanisms that ideally protect the entire cloud computing platform from both traditional attacks and cloudburst attacks. The first is a termination of the VM, for some attacks would directly penetrate a host server by monitoring the simulated device of the VM using the ‘shutdown’ or the ‘destroy’ command. Second is an isolation of the malicious and compromised VM by monitoring its run-time status via the ‘migration’ command.. For monitoring cloudburst attacks, VIS uses the qemu-monitor-command to monitor all VM devices virtualized by KVM. This is another way to monitor VMs in our work. In a cloud environment, the cloud provider doesn’t typically allow customers to change devices on their own VMs, just like cloudburst attack can unplug VM’s PXII4 chip. Thus, VIS can detect changes in each VM device.. In addition to cloudburst attack [ 8], there are also traditional attacks that can be launched within the VM and let the hacker attack another VM in the cloud implementation. In this case, a VM can be examined monitoring its runtime status. There are two kinds of run-time status: The first is when a VM is running within a KVM environment and is simultaneously running as a process by way of qemuKVM. Thus, the VM run-time status can be monitored by VIS using “strace”.In this case the VM’s owner doesn’t know their VM is being monitored. In the second case “qemu-monitor” is used to monitor hardware virtualized by KVM for each VM.. 10.

(18) To know when a VM is running a malicious program, we need to replay the attack in the cloud environment, then collect data of VMs during several events. Examples of such events include all VMs idling, a hacker launching an attack, a hacker who already has a backdoor and is sending a keystroke, taking a screenshot, launching a pivoting attack, etc. VIS can then collect the data and simultaneously record the VM’s ID. After data has been collected, VIS will run it through an analyzer for training, learning to distinguish between the run-time status of the VM (running a malicious code, idling etc.) Simultaneously, VIS will use a training model in an analyzer to derive decision rules by using clustering techniques, such as GHSOM [ 12] or k-means clustering [ 13]. Based on these decision rules, VIS can detect and prevent attacks by termination and isolation functions.. VIS focuses on IaaS layer protection. IaaS is the most basic cloud service model, as cloud providers offer fundamental resources directly, such as server, storage space, or through VMs. Through the IaaS model, cloud providers can reach economies of scale and the consumer has no need to supply their own server or to manage the cloud system themselves. The infrastructure layer may be the most important layer in the cloud computing environment because the applications of other two services are essentially based on the infrastructure layer, so securing this layer is extraordinarily important.. Figure 1.10 Architecture of VIS with Software and Hardware’s Relation. 11.

(19) VIS can be deployed on most cloud operating systems based on KVM such as OpenStack and OpenNebula [ 24]] as in Figure 1.10. 1.3. Objective of VIS. 1.3.1. Detect VMs that attack Hypervisor:. VMs which directly attack a hypervisor protected by VIS’s Termination function will be destroyed or shutdown to prevent the sensitive hypervisor data from theft.. 1.3.2. Detect VMs that attack other VMs:. For a malicious VM wanting to attack another VM in the same cloud computing platforms, VIS will use the isolation function to migrate the malicious VM into a sandboxed host with this kind of VM can still running, and unable attack another VM in the same cloud computing platform. The purpose of this is to enable the administrator to trace the hacker.. 1.3.3. Detect VMs that have been compromised:. Compromised VMs will also be migrated to the sandboxed host to await the cloud administrator or VM owner to determine which VM snapshot is clean, and then restore this VM snapshot for the cloud customer.. 12.

(20) CHAPTER 2. RELATED WORK 2.1 Cloudburst attack by Virtunoid – attacking the hypervisor Virtunoid is a special malicious program that runs inside a VM and can take over a host. We use a VM in response to this attack and allow the VM to acquire host privileges after the attack. From monitoring the VM’s run-time status, by especially utilizing virtualized hareware devices of VM by qemu-KVM, VIS can determine that there has been a ‘unexpected’ change, since usually the VM owner is not permitted to modify virutalized hardware. VIS can use this information to determine if the VM should be migrated to a sandboxed host or shutdown to prevent similar attacks. This kind of attack attack is called cloudburst.. When simulating the cloudburst attack we use the virtunoid exploit, first published at BlackHat/DEFCON 2011 by Nelson Elhang [ 8]. We installed Ubuntu [ 17] 14.04 on the host and use KVM, libvirt [ 18] to build up a simulated environment.. 2.2 Malicious Behavior Detection A running VM employs virtualized hardware and one of the VMs on the host. It is a process is executed by KVM, where we use another physical host as a “SandBoxed-Host” [ 29] and execute the malicious program in a VM. In this way we decide to use “strace” and “qemu-monitor” to collect the dynamic data from VM and compare a VM’s malicious behavior to models. Using “strace” this can be viewed as “black-box testing”, as the vector from which the VM can request the needed system call from the host . This system call then can be collected from the running VM for analysis. On the other hand, qemu-monitor can observe the integrity of virtualized hardware and determine if it is normal or being used inappropriately. The execution of a malicious program may come in several phases, such as vulnerability scanning, executing the attack, or embedding a backdoor. We separate these periods and record the data for analysis, much like TTAnalyze [ 15]. On the other hand, we classify the data collected by VIS from strace by period and role. Borrowing from I. Santos et al. [ 30], we use static analysis to disassemble the program and expose some suspicious “opcode”, in order to use several different kinds of analysis models to analyze the malicious software, as well as already known and classified normal software. Next, unknown software is put into the analysis model. The analysis model 13.

(21) then determines if the unknown software is malicious or normal. We also use this method to do a dynamic analysis: VIS uses the statistical result from data collected by “strace” to find out the status of the VM during the execution of a malicious program, as well as the the system call used at that time. Simultaneously we use these sequence system calls to reanalyze and classify again by doing a similarity analysis as a reference basis of a malicious program.. There are two ways to extract software behavior models that could provide alternative solutions for analyzing a virtual machine’s behavior model. One is to retrieve properties of data values [ 5] [ 23] such as constraints on legal values in the form of a Boolean expression. The second way would be to examine the properties of interaction patterns such as possible interaction sequences in the form of final state machines [ 9]. However, neither of these models account for their mutual interplay. Even when one takes both analysis models into consideration, it is hard to see their intricacies clearly.. Thus, in the future we will adopt a new analysis method, GK-trail, which would produce models in the form of extended final state machine [ 19]. These models were designed to represent the properties of the data values, interaction sequences, and provide insight into the interplay between the two. The extended final state machine shows itself to be a reliable model because it does not depend on the size of the analyzed systems, but rather the complexity of the interplay within the system's components. This makes the GK-trail quite flexible in analyzing different types of systems effectively. However, as this model is still being tested (at least at the time of the paper), there may be uncertainties that come with it, and thus we have yet to incorporate it.. 2.3 Virtualization Introspection There are many research papers on the cloud environment working on defending from malicious programs or hackers such as the security risk evaluation of the cloud computing presented in detail by Enisa [ 7] . In Siebenlist [ 33], a number of security issues are discussed. There are also many interesting and worthwhile surveys about cloud security presented by Armburst [ 10]. However, all of these papers are discussing primarily attacks coming from guest machine users who turned said guest machine in the cloud computing environment into a malicious machine.. 14.

(22) A cloud attacker may use a virtualization environment’s vulnerabilities to break into another VM when they detect the target machine in the cloud environment. In order to guard against the attack method stated above, most approaches use Virtual Machine Monitor (VMM) isolation properties to secure VMs by leveraging different levels of virtual introspection [ 16]. Virtual introspection [ 2] allows user to observe a VM’s state through this process. In previous papers surveyed, there are some useful approaches catching our attention. For example, SecVisor [ 32] Lares [ 26] and KVM-L4 [ 27], CUDACS [ 21], among others, leverage virtualization to monitor the integrity of a guest kernel code from a privileged virtual machine or from the VMM, or a hypervisor. One research Security Analysis of Cloud Management interfaces [ 34] focuses on the XSS security on Amazon Cloud’s cloud management interfaces which can control VM instance. but we use another commodity open source virtualization management interface called virsh. Advanced Cloud Protection System (ACPS) [ 22] is one mean of improving the security of cloud nodes. ACPS is an extension of the KvmSec [ 20] and KvmSma [ 22] which are also known as extensions of the Linux KVM. ACPS is a protection system that is totally transparent to cloud environments and can also monitor the cloud component, both locally and via remote, to protect the whole cloud. However, none of these papers mentioned how to protect cloud computing platforms from cloudburst attacks and have no mechanism, like migration, in this paper.. The component of Virtualization is a native tool for monitoring a VM, such as QEMU-monitor and VMM. VIS is using the QEMU-monitor to monitor the hardware components of a VM. EagleEye [ 36] changed the QEMU device in the hypervisor instead of using QEMU-KVM or QEMU-monitor, and EagleEye is only for Xen hypervisor which is only for para-virtualization. Most of the virtualization monitoring mechanisms needed to modify the hypervisor or VMM, which makes monitoring mechanisms more difficult to deploy in the real cloud ecosystem, prove more difficult to fix a bug if it is not a mainstream cloud computing platform which is supported by companies or large open source users.. Another work about botnet profiling [ 14] and detection, uses VMM directly to collect information without installing an agent in the guest OS, and analyzes the behavior patterns of bots from the API calls. It has both passive detection and active detection. Passive detection is based on a modified QEMU hypervisor (VMM) to examine data by a bot to check bot behavior profiles. Active detection is the active fingerprinting on bots to detect different bots performs it’s malicious jobs, by utilizing specific stimuli to examine if bots perform expected behavior, through bot profiling, 15.

(23) fingerprinting and distinguishing bot families. One upside is that it can profile bot families and use the specific stimuli to examine known bots. The downside, however, is that it needs to modify the Virtual Machine Monitor (VMM) as a bots detection system. On the on hand, passive detection can only observe particular bot activities and then trigger the security alarm. It can only detect the bot or backdoor behavior. This work has no intrusion prevention mechanism, however, after the bots are detected, the hacker has already successfully hacked the system.. Nitro [ 28] is a VMI-based system for system call tracking and monitoring supports in Linux, Windows 64/32bit system, but only works on Intel x86 hardware architecture. It also utilizes machine learning to classify the system calls or API calls (actions) of malicious process in the guest OS, as some sandboxing environments (honeypot environments) will be monitoring the particular system calls or API calls. Nitro also needs to modify the KVM by adding new commands called Nitro Commands and send those new commands to the KVM kernel module and the I/O control interface. The outputs are then sent to the proc filesystem by creating a node in the proc filesystem. The strength about Nitro is that it has a Hardware-based tracking system that performs well while simultaneously providing transparency that guest OS will not award itself in being monitored. On the other hand, Nitro only works on specific hardware and is not easy to replace current popular cloud hypervisor drivers, such as VMware Workstation/Player, VirtualBox and OpenVZ. Nitro only supports KVM.. There is another related work about virtualization inspection by using periodically integrity check on the state of VMs. The key advantages of VMI IDS (Livewire) [ 11] include: being an isolated VM and using a modified VMM for monitoring purpose. Given no VM can avoid being monitored by VMM, Livewire is able to conduct inspection on a VM by using VMM.. Livewire periodically compares the integrity of the state of a VM via a modified VMM of VMWare. When monitoring a VM, Livewire needs to copy the state of a VM first which interrupts the monitored VM. Because of this, Livewire is a costlier monitoring system, and easier to be discovered by intruders of the malicious VM.. Comparing to VIS, Livewire only checks the integrity of VMs, while VIS has several more features as following. VIS doesn’t need to interrupt monitored VMs while monitoring them, so it is less 16.

(24) possible to be discovered by hackers or intruders. Also, VIS doesn’t need to modify the VMM, and is able to support different cloud hypervisors other than VMWare, which is good for the deployment in the cloud system. It also has an online migration feature. Moreover, VIS can distinguish differences between different malicious behaviors and further recover compromised VM by using snapshots of VM images.. 17.

(25) CHAPTER 3. VIS ARCHITECTURE 3.1 VIS architecture In this section, we will introduce how the monitor in VIS dump, store and compare the VM runtime state data, and determine how to detect an abnormal VM runtime state data. The architecture of VIS is shown in Figure 3.1.. Figure 3.1 VIS Architecture. 3.1.1. Introspection Engine:. The introspection engine consists of the introspection modules (mean of rules), behavior log DB, policy table, behavior analyzer, behavior checker, behavior collector and controller. The following are the main components of VIS :. . Logging and storage component : Behavior collector, Behavior Log DB. . Analysis component: Behavior Analyzer, Policy table 18.

(26) . Introspeciton rules component: Introspection Modules, Behavior Analyzer, Behavior. Checker . Part of control component: Controller, Virtualization API. We collect two kinds of data from different types of VMs: “qemu-monitor” output and “strace” output. We need to collect these two kinds of data from different runtime states of VMs to crosscompare and establish introspection modules. We use “strace” and “qemu-monitor” to monitor the runtime state of VMs. However, “strace” and “qemu-monitor” monitor the VMs in different ways. In our case, we use “strace” to monitor what kinds of system calls that VMs use in a given runtime, and use ”qemu-monitor” to monitor the hardware state of the VMs. By comparing the states of each VM, any abnormal hardware state or any unusual use of system calls will be apparent and we may regard them as malicious attacks from VMs and react accordingly. In order to build up the introspection modules, we design four kinds of experimental VM conditions and compare the states of each VM as mentioned above. We then store the data which we consider is abnormal in the policy DB as introspection modules. At the VIS startup, the policy framework will load those introspection modules from the policy DB.. The monitor is a stand-alone process able to load all introspection modules from the policy DBs and provide continuous monitoring. VIS will classify the data collected into several kinds of attack models and react accordingly. For example, in the event of a cloudburst attack, VIS will destroy or shutdown the VM; if it’s a traditional attack, then it will migrate the malicious VM to sandbox host, as in Figure 3.16.. 3.1.2. Upper Bound Calculator. After we’ve put all collected data from each attack method into cluster analysis, the data is then reclassified by VM behavior. So we choose several class analyzed by clustering techniques that we can use to recognize it as a malicious VM attacking other VM or a compromised VM. After an upper bound 19.

(27) calculator calculated each data from each class, the maximum number of data will be set up as an upper bound and put into the policy table.. 3.1.3. Policy Table This component stores the security policy for introspection module for behavior’s checker to. compare.. 3.1.4. Behavior Log Database The behavior DB stores runtime states of all VMs. The program running on the VM will. determine the system call and subsequent classification. For example, I usually classify the data by attack method. After attack method, the role of the VM will be used, i.e. hacker, victim, and normal. Then they will be classified by time period, the attack method employed or program used, and system call. Thus, the classification is done in the following order: Attack Method  Role  Period  Program  System call.. 3.1.5. Behavior Analyzer The behavior analyzer will analyze the data stored in the behavior database to build the. introspection modules. This will be mentioned in Section Implementation.. 3.1.6. Behavior Checker The behavior checker will import the introspection modules from the policy DB. The. introspection rules are stored in the introspection module to enable the behavior checker to do a comparison immediately to determine which VM is executing the malicious program.. Once the attacks are confirmed, the monitor will pass the domain action message to the controller, such as “domain destroy” or the “domain shutdown”, to respond to the attack. In the example domain [action] message could look like “SVM-01 [destroy]”.. 20.

(28) 3.1.7. Monitor The responsibility of the monitor is collecting data from the VM, such as the run-time system. calls of VM and “qemu-monitor” output from the VM, then they are categorized in the order of “Attack Method  Role  Period  Program  System call” and stored in the behavior database , and from there can be visualized as a bar graph.. 3.1.8. Controller The controller mainly receives commands from the behavior checker. The behavior checker. determines which domain (VM) which action the controller will take, such as allow, destroy, shutdown, migrate etc. The controller will pass the message to the cloud middleware and record the message in cloud middleware’s database (unrelated to the policy DB of VIS) so that the cloud middleware can record the whole state of the cloud. Additionally, cloud middleware can directly use libvirt, virsh to control the compromised VM.. 3.2 VIS INTEGRATED WITH CLOUD HYPERVISORS VIS is compatible with various hypervisors, such as VMware Workstation/Player, VMware ESX, Xen, VirtualBox and OpenVZ using virsh and libvirt [ 18]. The virsh program is an interface for managing virsh guest domains (VM) as long as virsh connects to hypervisors, and it can be used to create, pause and shutdown a VM or virtualized network. Libvirt is a C toolkit which targets to provide a stable C API for the virtualization of the Linux Operating System. VIS controls VMs through virsh in order to further utilize Libvirt.. After installing various hypervisors in different hosts, VIS needed to auto detect the type of the hypervisor that was installed in the host, as seen in examples below. Following the examples shows how to connect to remote KVM via ssh using virsh in VIS “virsh –c qemu+ssh://[email protected]/system”. 21.

(29) Figure 3.2 Connected with KVM The following example shows how to connect to localhost’s VMware ESX using virsh in VIS “virsh –c esx://esx-node”. Figure 3.3 Connected with VMware ESX The following example shows how to connect to remote VMware ESX via ssh using virsh in VIS 22.

(30) “ virsh –c esx+ssh://example-esx.com/?no_verify=1”. Figure 3.4 Connected with VMware ESX via ssh. The following example shows how to connect to remote VMware Workstation via ssh using virsh in VIS “virsh -c vmwarews+ssh://[email protected]/session”. Figure 3.5 Connected with VMware Workstation 23.

(31) The following example shows how to connect to localhost’s VMware Player using virsh in VIS “virsh –c vmwareplayer:///session”. Figure 3.6 Connected with VMware Player. The following example shows how to connect to remote Xen via ssh using virsh in VIS “virsh –c xen+ssh://[email protected]/system”. 24.

(32) Figure 3.7 Connected with Xen. The following example shows how to connect to remote VirtualBox via ssh using virsh in VIS “virsh –c vbox+ssh://[email protected]/session”. Figure 3.8 Connected with VirtualBox 25.

(33) The following example shows how to connect to remote OpenVZ via ssh using virsh in VIS “virsh –c openvz+ssh://[email protected]/system”. Figure 3.9 Connected with OpenVZ. Before connect to the hypervisor, VIS will test the type of hypervisor at the beginning as the script shown below.. 26.

(34) Figure 3.10 Script of Checking the Type of Hypervisor. As there are different hypervisors, there are different ways to check the type of hypervisor. Figure 3.10 shows the way to check KVM hypervisor by using the lsmod command to list the kvm linux kernel module has been loaded. The way to check VMware ESX/Workstation/Player, VirtualBox and OpenVZ hypervisor is by the list of processes in the operating system. On the other hand, to check the Xen hypervisor one must use the Xen command xl to check that Domain-0 is running.. 27.

(35) 3.3 MONITORING VM’s STATUS To monitor the run-time status of a VM, first, VIS must determine the VM's run-time system call using “strace” to collect VM’s underlying system calls of KVM from the host, as in Figure 3.11. Figure 3.11 The strace command Second, to monitor the VM’s run-time virtualized device, VIS uses “qemu-monitor” to check simulated device of VMs, as Figure 3.12. Figure 3.12 The qemu-monitor command. As mentioned above, VIS uses strace to monitor the KVM process of the VM, while simultaneously using qemu-monitor to monitor virtualized QEMU devices of the VMs, as in Figure 3.13.. 28.

(36) Figure 3.13 Monitoring VMs status. 3.4 VIS Defense Operation Here, we describe how VIS guards against cloudburst and traditional attacks. When VIS detects a cloudburst attack from a malicious VM, it will be shut down and offline-migrated to a sandboxed host (see Figure 4.4). On the other hand, when VIS detects a traditional attack, VIS will online-migrate compromised and malicious VMs, as well as Redirect iptables and virtual networking settings. For traditional attacks, we have more time to trace the attacker without the attacker realizing they are being monitored by VIS. VIS Defense operates as in Figure 3.14.. 29.

(37) Figure 3.14 VIS Defense Operation. 3.4.1. Termination-Shutdown of malicious VMs. Every abnormal behavior is regarded as malicious, thus enabling VIS to intercept a cloudburst attack. For example, if the VM uses a system call abnormally, VIS may use virtualization API libvirt or a virtualization management user interface such as virsh to intercept the attack and shutdown the malicious VM, as in Figure 3.15. If a cloudburst attack is detected, the monitor will pass "domain [shutdown]" or “domain [destroy]”as a message to shut down the malicious VM, yet the VM image will not be deleted immediately. Instead, it will be offline-migrated to sandboxed host.. 3.4.2. Isolation-Migrattion of Malicious VMs and Redirect iptables. If the attacker is using known traditional attacks, such as using the Metasploit Framework to find other VMs that can be attacked, then VIS will online migrate the VM to the sandboxed host, as in Figure 3.16 VIS can monitor the running VM in real time. 30.

(38) a) When. a traditional attack is detected: When the monitor detects a traditional attack, the. monitor will use online migration to migrate malicious VMs to specific sandboxed hosts. By resetting the iptables of the malicious VM, the malicious VM is physically separated from the cloud, but continues running, making it possible to trace the attacker and has no effect on the original cloud. Because the relative setting has been changed, the malicious VM can not perpetrate any attacks on the cloud infrastructure or other VMs.. Figure 3.15 The Traditional Attack in the Cloud. b) Migration:. The first step is to translate the memory of the compromised or malicious VM to. the sandboxed host, then hosts on both sides will check whether the translation is complete. Next, the original host translates the VM’s IP to the sandboxed host. In order to sever the connection between compromised/malicious VM to original host, the original host will cut the connection, while configuring the compromised/malicious VM's VLAN and the related “iptables” configuration after the checking the migration is complete (see Figure 3.16). In this way, the compromised/malicious. 31.

(39) VM will not discover it is been migrated. We use this way to track attacker and intercept attack, as in Figure 3.16.. For example, before the VIS migrates the VM to the “SandBox-Host”, it will be connected to the sandbox-host by following command: “virsh –c qemu+ssh://soslab@SandBox-Host:999/system” The command “virsh” is a virtualization support management user interface, and the "-c" option is use to specifies the URI parameter with which to connect to the hypervisor. In our case we use the “qemu+ssh” to connect with “sandbox-host” and the account is “soslab” that hostname is “SandBox-Host” on port 999.. 32.

(40) Figure 3.16 Migrating the VM into a sandboxed host. 33.

(41) CHAPTER 4.. EVALUATION. 4.1 The Experimental Traditional Attack In this experiment environment, we divided the VM into three different roles: Normal (do-nothings, the VM image is same as the hacker’s and it is used for comparison), Hacker (which uses different attack methods to attack the Victim), and the Victim (the VM being attacked by the Hacker). These three different roles of the VM will be used to do a cross comparison. Using the experiment results we can build the introspection modules. VIS collects two different kinds of data output: 1. “qemu-monitor” output and 2. “strace” output. We model and analyze the data output, but the traditional attack would not change the VM’s QEMU device, so with a traditional attack VIS will only collect the output of “strace”. Output results of “strace” will be categorized by VIS in the following order: Role  Period  Program  System call. Then the output will be restored in the behavior database. In VIS, we need these different VM’s run-time system calls. The experiment scenario is shown below:. 4.1.1 Attack Method 1 : Java Applet JMX 0-day, CVE-2013-0422 (Analysis Code : C1) 1). Hacker VM: this VM image is based on Backtrack and it will execute the exploit called. “java_jre17_jmxben”. a). Period 0: All VMs does nothing.. b). Period 1(setup attack):When java_jre17_jmxben is being executed, it will set up a malicious web. site and the web server settings. c). Period 2 (attacking): after Period1, as soon as the Victim clicks the malicious link from browser. created by the Hacker. The web page containing malicious Java program will show words like “Loading, Please wait..”, where then “reverse_tcp” (backdoor) will be launched as the Payload. d). Period 3: Takes the Victim VM’s screenshot with “screenshot” command.. e). Period 4: It also can get the system information of Victim with “sysinfo” command.. f) Period. 5 (list processing in Victim): The “reverse_tcp” can let the Hacker see what processes are. running in the Victim VM by utilizing “ps” command . g). Period 6: To prevent the backdoor being killed by the Victim, we use the “migrate” command to. migrate the backdoor from the browser to another program, for example, explorer.exe. 34.

(42) h). Period 7: Do the keyboard recording with “keylog_recorder”.. i) Period. 8: Get an interactive shell interface inside the VM with “shell”.. j) Period. 9: To prevent the backdoor from being killed by the Victim, turn the browser that use the. “migrate” command to migrate the backdoor to another program, for example, explorer.exe. Victim VM: Given that the operating system is Windows 7, during the experiment period the. 2). Victim will click the malicious link provided by the Hacker VM. The IE browser will automatically open a web page containing malicious Java program. Normal VM: VM image is the same as the Hacker’s, but after booting it also records the system. 3). call for comparison and analysis.. 4.1.2. Attack Method 2 : Java Applet JMX 0-day, CVE-2013-0431(Analysis. Code :C2) Hacker VM: this VM image is based on Backtrack and it will execute an exploit called. 1). “java_jre17_jmxben_2”. a). Period 0: All VMs does nothing.. b). Period 1 (setup attack): When the java_jre17_jmxben_2 being executed, it will be setup a. malicious web site first and then the web server settings. c). Period 2 (attacking): After Period 1, the attack allows the Victim click a malicious link from a. browser created by the Hacker. When the Victim clicks the malicious link, the web page will execute a malicious Java program and will display“Loading, Please wait..” After, the “reverse_tcp” (backdoor) will be launched as the Payload. d). Period 3: Take the Victim’s VM’s screenshot with the “screenshot” command.. e). Period 4: Can also achieve system information of the Victim with “sysinfo” command.. f). Period 5(list processing in Victim): The “reverse_tcp” can let the Hacker see what processes are. running in the Victim VM with the “ps” command . g). Period 6: To prevent the backdoor from being killed by the Victim, we use the “migrate”. command to migrate the backdoor from the browser to another program, for example, explorer.exe. h). Period 7: Get keyboard recording with “keylog_recorder”.. i). Period 8: Access an interactive shell interface inside VM with “shell”. 35.

(43) j). Period 9: To prevent the backdoor from being killed by the Victim, turn the browser that use the. “migrate” command to migrate the backdoor to another program, for example, explorer.exe. Victim VM: Given that the operating system is Windows 7, during the experiment period the. 2). Victim will click the malicious link provided by the Hacker VM. The IE browser will automatically open a web page containinga malicious Java program. Normal VM: VM image is same as the Hacker’s, but after it is booted, it also records the system. 3). call for comparison and analysis.. 4.1.3. Attack Method 3 : Denial of Service(DoS) attack , by hping3 (Analysis. Code : D) Hacker VM: this VM image is based on Backtrack and it will execute the attacking tool called. 1). “hping3”. a). Period 0: All VMs does nothing.. b). Period 1 (setup attack/attacking): When the linux command “hping3 <Victim IP> -p 80 -i u100”. is executed the DoS attack will commence. Victim VM: Given that the operating system is Windows 7, during the each period it does nothing,. 2). waiting for the attack. a). Period 0: VM does nothing.. b). Period 1 (setup attack/attacking): In the Victim’s VM we use the linux command “NetCat (nc)”. to open port 80 to simulate port 80 opened as the webserver with the command “nc –lv 80”. 3). Normal VM: VM image is the same as the Hacker’s, but after booting it also records the system. call for comparison and analysis.. 4.1.4. Attack Method 4 :Microsoft Windows “Remote Desktop Protocol. Vulnerability”, MS12-020 (Analysis Code: M). 1). Hacker VM: this VM image is based on Backtrack and it will execute an exploit called. “ms12_020_maxchannelids”. 36.

(44) a). Period 0: All VMs does nothing.. b). Period 1 (setup attack): When the “ms12_020_maxchannelids” is executed, it will be prepare for. the attack. After using the command “SET RHOST <Victim IP>” this attack will be ready. c). Period 2 (attacking): Execute the “exploit” command that the Victim VM will be attacked and. will crash.. Victim VM: Given that the operating system is Windows 7, during each period it does nothing and. 2). awaits attack. After it is attacked, it will reboot. Normal VM: VM’s image is the same as the Hacker’s, but after booting it also records the system. 3). call for comparison and analysis.. 4.1.5. Attack Method 5: Social Engineering, Website attack, Java Applet. Attack Method (Analysis Code: S) Hacker VM: this VM image is based on Backtrack and it will execute the social engineering. 1). attack (Program). a) Period. 0: All VMs does nothing.. b) Period. 1: After setting the Java Applet attack method, the social engineering element is executed.. It will setup a phishing web site, then the related web server setting. c) Period. 2: After Period 1, it will wait for the Victim to click the malicious link from the browser. created by the Hacker. When the Victim clicks the malicious link, the malicious Java Applet called “Secure Java Applet” will be executed. Thereafter, the backdoor SE toolkit will be executed as the Payload. d) Period. 3: Get an interactive command line interface after calling the “SE Toolkit Interactive Shell. designed for SET. ” This allows the Hacker to run malicious commands on the Victim VM. e) Period. 4: The “SE Toolkit Interactive Shell designed for SET” can list which processes are. running on the Victim with “tasklist” command. f). Period 5: The “SE Toolkit Interactive Shell designed for SET” can kill processes running on the. Victim, for example, killing the “cmd” and “IE” program with “kill” command. g) Period. 6: Keyboard recording with “keystrokes_start” and “keystrokes_dump” commands. 37.

(45) Victim VM: Given that the operating system is Windows 7, during the experiment period, he. 2). malicious link provided by the Hacker’s VM will be clicked, the IE browser will automatically open the web page containing a malicious Java Applet. Normal VM: VM image is same with the Hacker’s, but after booting also records the system call. 3). for comparison and analylsis.. 4.1.6. Attack Method 6 : Heartbleed openssl_heartbleed, CVE-2014-0160. Hacker VM: this VM image is based on Kali Linux and it will execute an exploit called. 1). “openssl_heartbleed” Scanner. a) Period. 0: All VMs does nothing.. b) Period. 1 (setup attack): When setting up the openssl_heartbleed exploit, there are some module. options needed to be setup, such as FORCE_EXPLOIT, VERBOS AND ACTION. c) Period. 2 (attacking by DUMP action): Using the DUMP action option to dump memory content of. a victim. d) Period. 3 (attacking by KEYS action): Using KEYS action option to dump private key of a victim.. 2). Victim VM: Given that the operating system is Turnkey Linux WordPress virtual machine.. 3). Normal VM: VM image is same with the Hacker’s, but after booting also records the system call. for comparison and analysis.. 4.1.7. Attack Method 7 : Shellshock apache_mod_cgi_bash_env, CVE-2014-. 6271 Hacker VM: this VM image is based on Kali Linux and it will execute an exploit called. 1). “apache_mod_cgi_bash_env”. a). Period 0: All VMs does nothing.. b). Period 1 (setup attack): When setting up the apache_mod_cgi_bash_env exploit, there are some. module options needed to be setup, such as RHOST, LHOST, HEADER, METHOD, PATH, TARGETURI and RPORT. c). Period 2 (attacking): After Period 1 executes this exploit, the “reverse_tcp” (backdoor) will be. executed as the Payload. d). Period 3: Take Victim VM’s screenshot with “screenshot” command. 38.

(46) e). Period 4: Can also get system information of Victim with “sysinfo” command.. f). Period 5 (list processing in Victim): The “reverse_tcp” it can let Hacker to see what processes are. running in the Victim VM with “ps” command. g). Period 6: To prevent the backdoor from being killed by the Victim, uses the “migrate” command. to migrate the backdoor from the browser to another program, for example, explorer.exe. h). Period 7: Get keyboard recording with “keylog_recorder”.. i). Period 8: Access an interactive shell interface inside VM with “shell”.. 2). Victim VM: Given that the operating system is Metasploitable2.. 3). Normal VM: VM image is same with the Hacker’s, but after booting also records the system call. for comparison and analysis.. 4.2 Executing and result of the experiment In this subsection, I use Attack Method 1: Social engineering, Website attack, Java Applet Attack Method CVE-2013-0422 as example to explain. After executing this attack, we observed the bar graph of system calls. We see Period 0 that the Hacker’s VMs’ and Normal VMs’ system calls are very similar because of similar numbers of system calls and call/error ratio. Of particular interest are the three most commonly used system calls. See Figures 4.1, 4.2.. Figure 4.1 Period Attacking - Hacker VM. 39.

(47) Figure 4.2 Period Attacking - Victim VM. On the other hand in the scenario of attack, each system call being used in the Hacker VM and Victim VM are related, as shown in Figures 4.3, 4.4. Figure 4.3 Period Normal - Hacker VM. 40.

(48) Figure 4.4 Period Attacking - Normal VM. This attack can be used on the Victims running Java SE 7 Update 10 and below. Another form of social engineering attack, as the experiment result in the Normal VM’s system call statistics in each period is very similar, letting the Normal VM’s system call as the standard, as in Figure 4.5. In this way we can see when the Hacker VM is starting to attack there are two system calls. This would be different and not exist in Normal VM, as in examples such as “recvfrom” and “sendto”, in Figures 4.5, 4.7. Figure 4.5 Period initial Normal VM. 41.

(49) Figure 4.6 Initial Period - Hacker. Figure 4.7 Attack period – Hacker From the data of the attack by the hacker VM, the number of system calls “recvfrom” and “sendto” increase. With “recvfrom” increasing from 400 calls to 935 calls and “sendto” from 400 calls to 914 calls (see Figure 4.6 to Figure 4.7, from original to attacking).. 42.

(50) Figure 4.8 Initial Period – Victim. Figure 4.9 Attacking Period – Victim. The chart below shows the increase in system calls "recvfrom" and "sendto" when the victim is being attacked. "Recvform" jumps from 5 to 761 alls and "sendto" jumps from 5 to 580 calls. There is a. 43.

(51) relative relationship between the hacker and victim. Their system calls "recivfrom" increase concurrently.. Figure 4.10 Attack Setting Period – Hacker Figure 4.10 illustrates during the attack preparation of “Attack Method 2”, that there will be a new system call in use: “fdatasync”. As we mention above, druing the period from initial to attacking, “recvfrom” jumps from 400 to 935 calls and “sendto” from 400 to 914. See Figure 4.6 and Figure 4.7. VIS can set a rule such as: “recvfrom” > 930 calls & “sendto” > 910 calls to defend against a hacker using Java Applet JMX 0-day (CVE-2013-0422) to attack other VMs and migrate this malicious VM into a sandboxed host. Additionally, a victim being attacked will see a jump in “recvform” and “sendto” system calls, “recvfromm” from 5 to 761 calls and “sendto” from 5 calls to 580 calls. See Figure 4.8 and Figure 4.9. VIS can set a rule such as: “recvfrom” > 750 calls & “sendto” > 570 calls and then notify the cloud customer their VM may be compromised so they can take action, such as using VIS to restore a snapshot from before the attack occurred. 44.

(52) 4.3. Driving Defense and Recovery Rules by Using Clustering Techniques. In this section, we will explain how to derive rules from GHSOM results. We also discuss the defense rules used to defend against attacks from the hacker VM, as well as the recovery rules that we can use to recover compromised VMs. After “strace” and “qemu-monitor” output is collected, VIS uses the training model in the analyzer to derive decision rules by using clustering techniques, such as GHSOM or k-means. In this paper we use GHSOM to explain. The analyzer can sort data as different periods and record the VM running the malicious program data.. Figure 4.11 GHSOM Analysis Result. As shown in Figure 4.11, we run one set of data collected via Attack Method 1 through GHSOM to analyze. As you can see each collected data set has been classified based on the behavior of the VM. In the top-left of the figure, we have one file, “normal-Victim.txt”, which refers to the victim’s VM during a period of “does nothing (Normal VM)” and has been put into this class. In the top-right corner, each file is both the hacker and victim’s VMs during the period when the hacker perpetrates malicious 45.

(53) behavior and then sorts it into this class. In the lower-left corner, each file is in an inactive state and has been classified as “normal-normal.txt”. Specifically, the “normal VM” is a period of inactivity, and “atking-victim.txt” indicates that the victim’s VM has been attacked.. In the lower left of the figure, the top-left corner of the white square has the data classified as the “hacker’s VM” engaged in malicious behavior, such as killing a process within the “victim’s VM” or running “key_stroke” to record user names and passwords. In the top-right corner of white square, we have the classified “normal VMs” during idle periods. In the lower-left corner is the “normal VM” while the hacker’s VM is setting up the attack and during the attack, but the “normal VM” itself is still idle. Up to this point, we have only run data from a single attack though GHSOM for analysis.. After this first test, we will demonstrate five different kinds of attack (in the form of 973 files) analyzed via GHSOM, given in the figure below.. Figure 4.12 973 Files in the GHSOM Analysis Result 46.

(54) In Figure 4.12, we’ve put all collected data from each attack method into GHSOM for analysis. Data has again been classified by VM behavior. The names assigned within GHSOM shown in this figure, such as “DP2H32”, are assigned based on the following key: “Hacker VM” (H) during the “Period 2” (P2) of “DoS” (D) attack. The last number indicates the number of readings taken. Since readings are taken every ten seconds, 32 would indicate that the hacker’s VM had been running for 320 seconds. Highlighted in blue in the figure consists only of data collected from the hacker’s VM during DoS attacks (attack method 3). Data collected from the hacker’s VM during the “attack” period has been sorted into items of this class so that VIS can use the mean of these classes to calculate the run-time status of each VM for reference to prevent similar DoS attacks. Unfortunately, this figure is not very clear, so we’ll examine data from the “Hacker VM” during the period when it perpetrates malicious behavior in summary. In Figure 4.13, each “system call” is displayed as a box. Figure 4.12 is not easily understood at first glance. In the figure below, we’ve taken each class and colored it based on frequency of usage, arranged in the same pattern as Figure 4.13. White indicates the most frequently used classes, gray less used, with black being the least used.. Figure 4.13 Detailed Summary in System Call 47.

(55) Figure 4.14 Class No. 11, 18, 23. Another Figure above shows after analysis and classification, we can clearly see in the summary which class is dominated by the “Hacker VM” running malicious programs or by a “Victim VM” that is under attack. Those classes are dominated by a malicious behavior VIS that can use it to drive the attack detection rules. On the other hand, for those classes that are dominated by victim VM, the VIS that is under attack can use it to drive the recovery rules. Some examples have been highlighted in red in the Figure 4.14. On the other hand, as in Figure 4.15 below, you can see how each file is classified. This figure (Figure 4.15) is Class No. 11.. 48.