Views
5 years ago

April 10, 2011 Salzburg, Austria - WOMBAT project

April 10, 2011 Salzburg, Austria - WOMBAT project

ferent software

ferent software configurations (operating systems, services, etc) that can be used to rapidly deploy customized network configurations within a single computer (req. 4). Also, snapshots allow restoration of the virtual machines used in the experiment to the state they were in before each experiment. All experiments can then be performed under the same initial conditions (req. 5). Finally, the AES Engine automatically conducts the experiments (req. 6). The experimental results (e.g., traffic traces from malware and exploit program execution) are post-processed by BEAVER (BEhavioural Analysis using Virtualization and Experimental Research). BEAVER extracts behavioural information (e.g., HTTP requests made by a malware, IDS events generated) on the experiment subjects, and stores this information in a database that can be accessed through a web portal. Due to space restrictions, the BEAVER analysis system is not presented in this paper. 3.1 AES Engine In this section, we present the AES Engine. Section 3.1.1 presents the language we developed to specify experiments. Section 3.1.2 describes how an experiment is conducted by the AES Engine. Section 3.1.3 describes the documentation process of the experiment results. 3.1.1 Experiment Language The AES Engine module (programmed in Java) is used to automatically conduct the experiments provided by the user, and to gather the results. These experiments are either generated manually or generated by a script from a template based on the experimental hypothesis (ECS step 1). These experiments are specified in XML files using our own experiment language. The experiment language specifies (1) the network topology and (2) an Experiment Execution Graph (EEG). The network topology specifies the virtual machines required by the experiment and how these virtual machines are connected together. Note that the network topology is not limited to a LAN. More complex topologies can be used as long as the network infrastructure (e.g., routers) can be virtualized. The virtual machines that are part of an experiment are called actors. Each of these actors has a set of network interfaces identified by a unique label. Each interface is connected to a specific LAN. Thus, the actors and the network interfaces specify the network topology in which the experiment will take place. The EEG specifies the different steps of the experiment and the order in which they are to be executed. The EEG is composed of labeled steps, each separated by an operator. The EEG supports two operators: a sequencing operator (i.e., .) and a concurrency operator (i.e., |). • Sequencing (.): The sequencing operator specifies an ordering of the steps. For example, the EEG S1.S2 specifies that S1 has to be performed first and then S2 can be performed. The sequencing operator also specifies that S2 cannot be performed before S1 is completed. 3 19 • Concurrency (|): The concurrency operator specifies that two steps can be performed in parallel. For example, the EEG S1.(S2 | S3).S4 specifies that S1 has to be performed and completed first, then S2 and S3 can be performed concurrently and finally S4 can be performed when both S2 and S3 are completed. 12 Figure 1 shows a simplified example of an experiment used to study the exploit program jill against Windows 2000 Server. Lines 2 to 10 specify the network topology. There are three actors: VMWin2000ServerTarget (i.e., the target system), VMLinuxRH80Attack (i.e., the attacker system) and VMWin2000ServerDNS (i.e., the Domain Name System used to resolve computer names). Each actor is powered on on a specific snapshot and all network interfaces are connected to the virtual network (i.e., vmnet) 1. This network topology is shown in Figure 2. Line 1 specifies the EEG and lines 11 to 15 specify each step of the EEG. Each step is associated with an actor (e.g., actor="VMLinuxRH80Attack") that has to execute a specific command (e.g., cmd="jill 10.92.39.14 80 10.92.39.3 30"). Step S1 and S2 (lines 11 and 12) are used to check whether the attack system (i.e., VMLinuxRH80Attack) is able to communicate with the target system and the Domain Name System (DNS). To accomplish this task, the attacker system uses the command ping −c 4 with the target system (S1) and DNS (S2) IP addresses in parallel. Thus, the Step S3 will only begin when both S1 and S2 are completed. Step S3 (line 13) instructs the VMLinuxRH80Attack actor (i.e., the attacker system) to start capturing the network traffic that will be generated by the exploit program on the interface eth0. Step S4 (line 14) specifies to execute jill against the target system and to keep the output of this command in a file called jill.res.txt. Step S5 (line 15) instructs the actor to stop capturing the network traffic; and to keep the output of the sniffer in a file called jill.res.pcap The step specification in our experiment language is more expressive than what is shown in the simplified example presented in Figure 1. For instance, the experiment steps have to be resilient to problems occuring during the experimentation (e.g., a blue screen or an actor reboot caused by a malware). Here is the description of other parameters that can be used in the step specification. • id: The identifier of the step (e.g., S0) which is used by the EEG. • description: A string describing the step (e.g., ”Capture Network Traffic”) which provides a human readable description of the step. • actor: The actor executing the step. • cmd: The command to execute. This field can contain any command that can be executed in a command prompt or shell. Thus, this field can be used to execute batch files, shell scripts, and AutoIt 13 scripts to control the graphical interface of applications. Finally, it can contain AES predefined commands (Table 1). 12 The concurrency operator will be implemented when it is needed to support some future experiments. 13 www.autoitscript.com

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 • output: The name of the file where the output of the command cmd will be stored. • keepoutput: A Boolean value that specifies whether or not to keep the file specified by the output field as one of the results of the experiment. • timeout: A numerical value that specifies in milliseconds the maximum amount of time allocated to the command cmd to complete. For example, if the timeout is 2000, the command has a maximum of two seconds to complete. If not, the AES Engine will kill the process and continue to the next step. A value of 0 for the timeout field specifies that the command cmd has no restriction for its completion time. Note that the timeout can also be used on the experiment itself (not only on a step) to specify the maximum amount of time allocated for the entire experiment. • mandatory: A Boolean value that specifies whether or not this step is essential (mandatory) to the success of the experiment. For instance, the ssh daemon used to communicate with a given actor of the experiment might become unresponsive (either because it has been shutdown by malware, a blue screen has occurred, or whatever other reason), thus causing the download of some log files to fail. If the step is mandatory, then the experiment will be aborted, all the files gathered up to this point will be deleted, and the experiment will eventually be re-attempted. If the step is not mandatory, then the step will simply be marked as failed in the log file. The AES Engine offers a set of predefined commands, the list is shown in Table 1. Note that the AES predefined command SCREENSHOT is useful when the subject of the experiment (e.g., a malware or an exploit programs) causes damages (e.g., blue screen) or generates errors (e.g., missing library errors) that can be visually noticed by users. For example, we post-process these screenshot images after the experiment to automatically identify what went wrong by searching for sub-images (e.g., a missing library pop-up window) within the screenshot image. Also note that one could use standard commands to start and to stop a snif- Figure 1: XML Experiment File Example. 4 20 AES Command Description RECEIVE_FILE filename Send the file filename to the actor. GET_FILE filename Get the file filename from the actor. SCREENSHOT Take a screenshot (i.e., capture the screen) of the actor. SLEEP n Sleep for n millisecond(s). START p Start process p. STOP p Stop process p. START_SNIFFER interface Start capturing traffic on interface. STOP_SNIFFER interface Stop capturing traffic on interface. Table 1: AES Predefined Command. 4 Attacker Target Network Services 3, 5 Coordinators 2 1 Virtual Machine Templates Experiments Figure 2: Automated Experimentation System fer such as Windump 14 , Tcpdump 15 or WireShark 16 . However, we noticed that using our AES predefined commands, START_SNIFFER and STOP_SNIFFER, provide in some situations more reliable experiment results since they execute a series of commands and checks, that are sometimes essential to the quality of the traffic traces. 3.1.2 Experimentation In this section, we present the sequence of actions that the AES Engine has to accomplish to fulfill a set of experiments. 14 www.winpcap.org/windump/ 15 www.tcpdump.org 16 www.wireshark.org

D06 (D3.1) Infrastructure Design - WOMBAT project
6-9 December 2012, Salzburg, Austria Social Programme
D I P L O M A R B E I T - Salzburg Research
D I P L O M A R B E I T - Salzburg Research
D I P L O M A R B E I T - Salzburg Research
Communication Plan for EGU 2011 April 3-8, 2011, Vienna, Austria
ECCMID meeting Vienna, Austria 10-13 April 2010 - European ...
8th Liquid Matter Conference September 6-10, 2011 Wien, Austria ...
8th Liquid Matter Conference September 6-10, 2011 Wien, Austria ...
April 10, 2011 - University of Cambridge
Top 10 Project Management Trends for 2011 from ESI International