2.4. Argos

A new kind of virtual high-interaction honeypots has been developed by researchers from Vrije Universiteit Amsterdam, the Netherlands. The tool, called Argos, is capable of automatically detecting zero-day attacks — that is, attacks for which no patch yet exists. They use a technique called dynamic taint analysis to monitor the honeypot: As a first step, all data received via the network is marked. The usage of marked data is then tracked through memory, and once such marked data is used to influence the execution flow (e.g., via a JMP instruction), Argos detects this and generates a memory footprint of the attack.

In the following, we introduce Argos and the concept behind it in more detail. We show how to set up this virtual honeypot and describe how you can use it within your environment.

2.4.1. Overview

Compared to the other virtual honeypot solutions presented up to now, Argos takes a slightly different approach. Instead of just executing the guest virtual machine, it closely monitors it and tries to detect the point in time in which the attacker successfully compromises the honeypot.

Dynamic taint analysis is the heart of the Argos honeypot. This technique is based on the observation that for an attacker to take control of the execution flow of a given program, he must somehow influence it. This can be archived by over-flowing or underflowing a buffer, supplying a malicious format string, overwriting sensitive memory areas, or many other techniques. Thus, the attacker has to send a malformed input to the program, and this data influences the execution flow — for example, by jumping to the attacker-supplied data. At this point the dynamic taint analysis comes into play. All external input of a program is considered tainted by marking it. During the analysis process, the use of all tainted variables is closely monitored and checked. For example, if a tainted variable is used in an addition operation, the result is also considered tainted. Or if a tainted variable is assigned a fixed value, the variable is not tainted anymore. This way it is possible to track the use of external input. Once such tainted input is used to change the execution flow (e.g., as a JMP address), this can be detected and appropriate actions can be started. In the case of Argos, a memory dump is generated that contains information about what caused the deviation from the normal execution flow. Please note that this method detects attacks at the time of use and not at the time the attack overwrites certain memory areas. This results in a higher sensitivity for detecting network attacks. For a honeypot environment this is especially interesting because it allows us to detect an attack without any prior knowledge. We can exactly detect when a compromise happens and with the help of forensic analysis decide what led to the incident.

Argos is based on QEMU, which we have already briefly introduced in the previous section. QEMU itself is an open source system emulator that uses a technique called dynamic translation to emulate a system. The performance is slightly lower compared to other kinds of virtualization software, but nevertheless it achieves a fairly good emulation speed. Argos adds to QEMU the capability for dynamic taint analysis. This enables Argos to be a new kind of honeypot: We can set up a virtual Argos honeypot somewhere on the network, and it will constantly collect information. Since it has the capability to track the usage of external input, it can detect whether it received malicious input that triggered a vulnerability. Thus, we do not need to hide this kind of honeypot, and we can even advertise it. We will clarify this point when we show you how to set up and configure such a honeypot.

The main website of the Argos honeypot project is http://www.few.vu.nl/argos/, where you can download the software and find links to additional documentation. The main documentation is available at https://gforge.cs.vu.nl/docman/?group_id=14. In addition, there is an Argos development mailing list that you can reach at http://mailman.few.vu.nl/pipermail/argos-devel/.

2.4.2. Installation and Setup for Argos Honeypots

This section introduces all the necessary steps to set up Argos and configure the virtual network between the host and guest systems. Please be aware of the fact that using Argos is not a honeypot solution for beginners. You should have some experience in running Linux-based systems, and some practical background on honeypots will also help you to understand all the implications of this setup.

2.4.2.1. Argos System Setup with QEMU

Setting up an Argos honeypot is a bit more complicated than setting up a virtual honeypot running on VMware or UML. We describe all necessary setup options and give you step-by-step guidance to install your own Argos honeypot. In a first step, we set up QEMU on the host system. We have briefly introduced QEMU before to show you how to create a virtual machine for VMware Player on your own. Now we use QEMU as the basic building block for Argos. Once QEMU is installed, we continue to install Argos itself.

As noted earlier, QEMU also offers a kernel accelerator for Linux called KQEMU. This allows QEMU to execute most of the guest system code directly on the host system processor and thus enables a much faster emulation process. Therefore, we will describe how to set up QEMU together with KQEMU. Please note that the installation of some operating systems might fail when you use the kernel accelerator. Take a look at http://www.claunia.com/qemu/ for a summary of supported guest virtual machines.

We cover the installation process of QEMU 0.9.0, the current version at the time of this writing. The easiest way is to simply install QEMU via the package management of your favorite Linux distribution. For Debian and Fedora Core, the package has the name qemu, and you can install it via

$ sudo aptitude install qemu or $ sudo yum install qemu

The kernel accelerator is tightly integrated in the kernel. Thus, you have to install QEMU from a source to be able to use KQEMU. You need to prepare several things in advance before setting up QEMU together with the kernel accelerator:

• Download the QEMU and KQEMU package from the official website (http://fabrice.bellard.free.fr/qemu/).

• Have ready a CD-ROM or an ISO image with the operating system you want to install.

• You need at least 4GB of free disk space on the host system to install a virtual machine. The amount of free disk space needed may vary with the guest system you plan to install.

• Install the Simple DirectMedia Layer (SDL) development libraries and headers. Normally, your Linux distribution will have these files as a package ready for you to install — for example, on Debian libsdl1.2-dev. If your distrbution does not offer a package, you can download and build the library yourself from the sources provided at http://www.libsdl.org.

• Currently, QEMU still needs a C compiler from the 3.x branch of GCC. You can also install this with the package management from your distribution or from sources. If necessary, in the configure file change the variables cc and host_cc from gcc to gcc-3.4 or the appropriate version for your environment.

• Make sure that your host system has support for bridging and the TUN/ TAP device. Check your kernel configuration, which is typically available at /boot/config-VERSION, and check whether it has the entries CONFIG_BRIDGE and CONFIG_TUN set to either m or y.

Once all these prerequisites are fullfilled, simply follow these steps to set up QEMU together with KQEMU:

$ tar xzvf qemu-0.9.0.tar.gz
$ mv kqemu-1.3.0pre11.tar.gz qemu-0.9.0/
$ cd qemu-0.9.0
qemu-0.9.0/ $ tar xzvf kqemu-1.3.0pre11.tar.gz

qemu-0.9.0/ $ ./configure --prefix=/opt/argos
qemu-0.9.0/ $ make

qemu-0.9.0/ $ cd kqemu-1.3.0pre11
qemu-0.9.0/kqemu-1.3.0pre11/ $ ./configure --prefix=
/opt/argos
qemu-0.9.0/kqemu-1.3.0pre11/ $ make

qemu-0.9.0/kqemu-1.3.0pre11/ $ sudo ./install.sh
qemu-0.9.0/kqemu-1.3.0pre11/ $ cd ..
qemu-0.9.0/ $ sudo make install

The install.sh script of KQEMU inserts the module in the running kernel and also creates the device /dev/kqemu, which is needed by the tool. You should now have a running QEMU set up together with the Linux kernel accelerator KQEMU. You can also load the module by hand via $ sudo modprobe kqemu. In case of problems when compiling from source, please consult the online documentation available at http://fabrice.bellard.free.fr/qemu/user-doc.html.

Setting up Argos is very similar to setting up QEMU. For the sake of brevity, we just list all the commands necessary to install Argos:

$ tar zxvf argos-0.2.1.tar.gz $ cd argos-0.2.1/ argos-0.2.1/ $ ./configure --prefix=/opt/argos argos-0.2.1/ $ make argos-0.2.1/ $ sudo make install

Now you have under /opt/argos/ all the files necessary to run Argos together with QEMU. Next we create a virtual hard disk image that can then be used to install the guest virtual machine. This is similar to the approach from Section 2.2.4, in which we used QEMU to prepare a hard disk image for VMware Player. QEMU provides the utility qemu-img for this purpose. With the following command you create a 4GB hard disk image named ARGOS-HP, which uses QEMU's COW format, which offers smaller images, optional AES encryption, and optional zlib-based compression:

$ qemu-img create -f qcow ARGOS-HP.img 4G

Within this new virtual hard disk, we can now install the guest system. If you have a CD-ROM with the guest system you wish to install, issue the following command:

$ qemu -m 256 -localtime -hda ARGOS-HP.img -cdrom /dev/cdrom -boot d

The option -m corresponds to the amount of virtual RAM in megabytes that QEMU assigns to the virtual guest. With the option -localtime, you configure QEMU to use the local time clock instead of UTC. The primary hard disk will be the image we have created in the previous step, and the CD-ROM is available via /dev/ cdrom. Make sure that you can access your CD-ROM drive via /dev/cdrom or change the path accordingly. If you have an ISO image of your guest virtual machine, substitute the path to /dev/cdrom in the preceding example with the path to the ISO image.

Keep these operating system caveats in mind when installing QEMU to use with Argos:

Once you have installed and configured your guest virtual machine, you do not need the boot options -cdrom and -boot d. Simply start QEMU without these options. You should use the option -snapshot to enable the snapshot mechanism of QEMU. This forces QEMU and Argos to open the disk image in read-only mode, and all changes are written to temporary files. This way you do not risk corrupting the disk image.

2.4.2.2. Argos Network Setup

After setting up the guest virtual machine, we must now configure the network in such a way that the honeypot can access the Internet. Therefore, we need to configure the virtual network according to the requirements by Argos. We need Ethernet bridging and the Linux TUN/TAP driver be able to configure the network. As noted in the previous chapter, please make sure that your kernel fullfills this requirement. You can check this either with the help of the command noted or by just trying to load the two kernel modules:

$ sudo modprobe bridge tun

If this command returns with an error, consult the documentation of your Linux distribution on how to install the additional modules. You can compile your own kernel and configure it accordingly. For Linux 2.6 kernels, enable the Universal TUN/TAP device driver located under Device Drivers, Network Device Support and the 802.1d Ethernet Bridging option available under Networking, Networking Options. To use the netfilter/iptables subsystem of Linux, you must enable the network packet filtering under Networking, Networking Options, Network Packet Filtering, IP: Netfilter Configuration. Moreover, you can configure firewalling options for the Ethernet bridge under Networking, Networking Options, Network packet filtering, Bridge: Netfilter Configuration. Then compile the kernel, install the new version, and reboot your system. Then the modprobe command should be able to successfully load the bridge and tun modules.

In addition, you need to install the bridge-utils package, which is available via either the package management or at http://sourceforge.net/project/showfiles.php?group_id=26089. You can compile the source package with the usual configure && make && sudo make install. We will not go into more detail here.

In the rare case that you only wish to enable outgoing connections from the Argos guest, you could set up iptables and use NAT to forward connections from the guest OS to the Internet but not the other way around. In this case you will not need the bridge utilities, but you will still need TUN/TAP support for your Linux kernel.

All necessary requirements to configure the virtual network for the Argos honeypot are now ready, and thus we can now configure the various options. First, copy the file qemu-ifup from the Argos source package directory to /etc/argos-ifup and make sure that it is executable. This shell script is executed to configure the network adaptors of each guest virtual machine of Argos. This scripts executes two commands: First, it adds the virtual interface $1 to the default Ethernet bridge br0. Then it enables the virtual interface:

#!/bin/sh sudo /sbin/brctl addif br0 $1 sudo /sbin/ifconfig $1 0.0.0.0 up

Next we must set up the network at the host system itself. We need to set up an Ethernet bridge and configure it in such a way that the default network interface eth0 also belongs to this bridge. This implies that all interfaces that you normally use to access the Internet (e.g., eth0 or eth1) cannot be used anymore, but you can access the network via the bridging interface br0. The following script can be used to set up such a concept, but you may have to adjust these commands to your environment:

#!/bin/sh sudo /sbin/ifconfig eth0 down sudo /usr/sbin/brctl addbr br0 sudo /usr/sbin/brctl addif br0 eth0 sudo /sbin/ifconfig eth0 0.0.0.0 promisc up sudo /sbin/ifconfig br0 <YOUR IP> up sudo /sbin/route add default gw <GATEWAY IP> dev br0

On a Debian-based system you can, for example, use the following configuration file /etc/network/interfaces to configure the Ethernet bridging during host system bootup:

# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface #auto eth0 #iface eth0 inet dhcp auto br0 iface br0 inet static address 192.168.42.22 netmask 255.255.255.0 broadcast 192.168.42.255 gateway 192.168.42.1 bridge_ports eth0 bridge_fd 1 bridge_hello 1 bridge_stp off

As a last step we must configure the virtual network for the guest virtual machine: our honeypot system, Argos. This is rather simple compared to the previous steps. Since the virtual network is completely transparent for the guest system, just configure it as you would normally do. The MAC address of the virtual interface used by the guest is fixed. If you want to change it, you can do that via the command line parameter -net nic,macaddr=00:11:22:33:44:55 -net tap when starting Argos.

Once you have finished all these steps, your virtual high-interaction honeypot running Argos is finished. You can start it via

$ /opt/argos/bin/argos -m 256 -localtime -hda ARGOS-HP.img -snapshot

and connect it directly to the Internet. Argos will analyze the network traffic and use dynamic taint analysis to trace the usage of network input. Once it detects a buffer overflow or another kind of exploit, it will generate a memory dump, which you can then analyze. Analyzing this memory dump is not an easy task, since currently not much tool support is available. Nevertheless, it is interesting to analyze the dumps because it allows you to detect new kinds of attacks. Because Argos is — at least from a network point of view — not different from a real system, all exploits will be successful. Thus, it is also possible to detect zero-day attacks with this kind of honeypot. To understand the memory dumps, we refer to the official documentation available at https://gforge.cs.vu.nl/docman/view.php/14/15/logs.html.

As an example, we take a quick look at an actual attack. The RPC DCOM exploit (referred to by Microsoft as MS03-039) is famous for its use in botnets, and we will discuss it in more detail in Chapter 11. Several exploits exist for this vulnerability, so it is quite likely that your honeypot will be hit by this exploit if it is not patched. Argos will detect this kind of attack and generate an alert together with a memory dump:

[ARGOS] Attack detected, code <JMP>
[ARGOS] Log generated <argos.csi.1155364418

This is the typical logging message you see when Argos detects an overflow. In this case, the external input is used to jump to another address — that is, the execution flow is influenced by external input, a clear sign of exploitation of a vulnerability. We can also look at the memory dump and try to find out to which exploit it belongs:

$ hexdump -C argos.csi.1155364418 00000620 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 * 000006c0 90 90 90 90 eb 19 5e 31 c9 81 e9 89 ff ff ff 81 000006d0 36 80 bf 32 94 81 ee fc ff ff ff e2 f2 eb 05 e8 000006e0 e2 ff ff ff 03 53 06 1f 74 57 75 95 80 bf bb 92 000006f0 7f 89 5a 1a ce b1 de 7c e1 be 32 94 09 f9 3a 6b 00000700 b6 d7 9f 4d 85 71 da c6 81 bf 32 1d c6 b3 5a f8 00000710 ec bf 32 fc b3 8d 1c f0 e8 c8 41 a6 df eb cd c2 00000720 88 36 74 90 7f 89 5a e6 7e 0c 24 7c ad be 32 94

When searching for the exploit, you will quickly find the RCP DCOM exploit coded by oc192, which is, for example, available at http://www.milw0rm.com/exploits/76. A closer look at this exploit reveals that the shellcode used during the compromise is exactly what Argos detects:

Code View: unsigned char sc[]= "\x46\x00\x58\x00\x4E\x00\x42\x00\x46\x00\x58\x00" "\x46\x00\x58\x00\x4E\x00\x42\x00\x46\x00\x58\x00\x46\x00\x58\x00" "\x46\x00\x58\x00\x46\x00\x58\x00" "\xff\xff\xff\xff" /* return address */ "\xcc\xe0\xfd\x7f" /* primary thread data block */ "\xcc\xe0\xfd\x7f" /* primary thread data block */ /* bindshell no RPC crash, defineable spawn port */ "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" "\x90\x90\x90\x90\x90\x90\x90\xeb\x19\x5e\x31\xc9\x81\xe9\x89\xff" "\xff\xff\x81\x36\x80\xbf\x32\x94\x81\xee\xfc\xff\xff\xff\xe2\xf2" "\xeb\x05\xe8\xe2\xff\xff\xff\x03\x53\x06\x1f\x74\x57\x75\x95\x80" "\xbf\xbb\x92\x7f\x89\x5a\x1a\xce\xb1\xde\x7c\xe1\xbe\x32\x94\x09" "\xf9\x3a\x6b\xb6\xd7\x9f\x4d\x85\x71\xda\xc6\x81\xbf\x32\x1d\xc6" "\xb3\x5a\xf8\xec\xbf\x32\xfc\xb3\x8d\x1c\xf0\xe8\xc8\x41\xa6\xdf" "\xeb\xcd\xc2\x88\x36\x74\x90\x7f\x89\x5a\xe6\x7e\x0c\x24\x7c\xad" "\xbe\x32\x94\x09\xf9\x22\x6b\xb6\xd7\xdd\x5a\x60\xdf\xda\x8a\x81" [...]

So without knowing the signature of an attack or having any additional information, the Argos honeypot system can detect an attack and also reveal more information about the procedures of the attacker. In the future, when more tool support is available for analyzing Argos memory dumps, it will be easier to understand them, and using this honeypot solution will become more suitable for end users and not only researchers.

2.4.2.3. Argos Control Socket

It is also possible to interfere with a running Argos system via a network socket. This optional features allows you to retrieve status reports from Argos or send commands to a running honeypot instance. Thus, it allows you to remotely control your honeypots. Per default, this feature is turned on, and Argos listens on TCP port 1347. You can customize to which address Argos should listen via the option -csaddr listening_address and also change the control socket port with the option -csport listening_port when running Argos. Up to now, the control socket does not provide any authentication or secure data transmission options. Therefore, you should control who can access the control socket and, for example, limit access to it via an additional firewall within your network.

Using the control socket is very easy. Simply connect to the TCP port configured earlier with a tool like netcat / nc. Once connected, Argos will send you a listing of the current working directory of the Argos process, encoded as a string terminated by a new line symbol. You will also receive all alerts generated by Argos on this control socket. There are two different kinds of alerts generated:

You can also issue various commands over the control socket. Commands consist of a string followed by a new line. At the moment, the following commands are supported by Argos:

• RESET: The virtual machine is reset (rebooted)

• SHUTDOWN: The virtual machine is shut down

• PAUSE: The virtual machine is paused and all executions stopped

• RESUME: The virtual machine is resumed from a previous paused state

These few simple commands allow you to automate the whole observation process of your high-interaction honeypot. Argos tells you once it has detected an intrusion and generates a memory dump. You can then reset the system and begin to manually analyze the dump.