Sebek came about as an answer to the desire to capture an attackers actions without them knowing they were there. Sebek is based on the concept of kernel rootkits, with it’s origins coming from linux with influence from the adore rootkit. Sebek is a data monitoring tool which provides capabilities to: record keystrokes of a session that is using encryption, recover files copied with SCP, capture passwords used to log in to remote system, recover passwords used to enable Burneye protected binaries and accomplish many other forensics related tasks. Data capture is accomplished with the use of a kernel module. With this module we gain access to the kernel space of the honeypot. Using this access, we then capture all read() activity / data. Sebek does this by replacing the stock read() function in the System Call Table with a new one. The new function simply calls the old function, copies the contents into a packet buffer, adds a header, and sends the packet to the server. The act of replacing the stock function involves changing one function pointer in the System Call Table. When a process calls the standard read() function in user space, a system call is made. This call maps to an index offset in the System Call Table array. Because Sebek modified the function pointer at the read index to point to its own implementation, the execution switches into the kernel context and begins executing the new Sebek read call. Data that remains encrypted is of little use; to view the data or act on it in some way it must be decrypted. In the case of an SSH session the keystrokes are decrypted and send to the shell to have actions performed. This act typically involves a system call. By collecting data in kernel space, we can gain access to the data within the system call, after it has been decrypted but before it has been passed to the process that is about to use it. This allows sebek to bypass encryption and capture the data without having to try to break the encryption.

Since one of the objects of Sebek is to avoid attackers knowing it’s there, its obvious that it should be hidden. In the linux version, a second kernel module is included that is called cleaner. This module manipulates the linked list of installed modules in such a way that Sebek is removed from the list. This is not a completely robust method of hiding and techniques for detecting such hidden modules do exist. In Windows, the installer hides the system driver that is in the \etc\drivers directory. It also cleans up and hides registry keys pertaining to sebek.

Once data has been recorded it needs to pass it off to a central monitor. If Sebek were to do this via normal packet transmissions it would be possible for the attacker to see the data via sniffing. Sebek sends data over UDP, but before it sends it the kernel is modified so that the attacker can not see it. First it modifies the kernel such that system is unable to see Sebek Packets, not just the packets generated by the local host, but any appropriately configured Sebek Packet. Next, when Sebek transmits data onto the network, it ensures that the system cannot block the transmission or even count the packets transmitted. For every read() request, Sebek generates one or more log packets. Each packet contains a bit of information about the context of the call made and the data that was accessed with the call. Each packet contains one Sebek record. After each packet is built, it is sent directly to the device driver, bypassing the raw socket code path as well as the packet filtering code path. Since packet sniffers are libpcap based and libpcap uses the raw socket interface to collect packets, sniffers installed on a host running Sebek are unable to see the Sebek packets generated.

So Redpill uses a SIDT instruction and gathers the return from the Interrupt  Descriptor table to tell whether its in the “matrix” or not. As was seen in the study by val smith and Danny Quist there are sometimes issues with the detection, especially when it comes to multiple processors being present on the machine. I’m not going to get into their tests I will leave the reader to his own devices to go read the results. However, I’d like to take that opportunity to introduce another utility that aids us in the detection of virtualization.

Scoopy_do written by Tobias Klein not only does IDT detection like redpill but also looks in the local and Global descriptor tables. Essentially you get three checks so you can make your educated guess. Seeing as how there are three tests performed Scoopy is almost always (at least in my testing) accurate in detection of virtual instances. Running it against my windows honeypot running on VMWare 6 we get the following:

C:\>scoopy.exe

####################################################

::        scoopy – A VMware Fingerprinter         ::

::              Windows version v1.0              ::

[+] Test 1

IDT base: 0xffc18000 -> should be VMware (but unknown version)

[+] Test 2

LDT base: 0xdead4060 -> should be VMware (but unknown version)

[+] Test 3

GDT base: 0xffc07000 -> VMware version 4 (100%)

::                   by tk,  2003                 ::

Although Scoopy_do detected the incorrect version of VMWare, it detected it none the less.

Tobias Klein also wrote Jerry, which works by analyzing the processor to see if it has any characteristics of a virtual machine. Two VME processor anomalies are used today to identify VMEs: looking for support for non-standard VME machine language instructions, and identifying a guest-to host communication channel. Jerry didn’t lie to me either Here’s a screenshot!

Programmatic checking is most likely the best method of VMWare detection but configuration issues should not be left out. VMWare has some remenence it leaves behind for certain components of the O.S such as hard drivers, network drivers, display drivers and in windows it leaves behind registry keys.

So in Linux there were a few configuration issues that I noticed. First /proc/scsi/scsi displayed the device as being VMWare. Further, grepping dmesg I was able to locate pcnet32 and BusLogic BT-958. These are both common signs that the operating system is in a virtual machine. Additionally, I’ve read that /proc/iomem, and  /proc/ioports both display instances of VMWare,  but my testing did not turn up anything for these. With windows, you can enumerate the registry and test for certain keys. The only one I found to work was similar to the linux detection with /proc/scsi/scsi. Remember I am using VMWare 6 so it could be possible that other keys still work, just not for this version. The key that worked for me in detecting VMWare was:

HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi\Scsi Port

0\Scsi Bus 0\Target Id 0\Logical Unit Id 0\Identifier

Other suggested keys are:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\

{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\DriverDesc

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\

{4D36E968-E325-11CE-BFC1-

08002BE10318}\0000\ProviderName

There are tons of other way’s of detecting VMWare and virtualization, this is by no means an exclusive posting of methods. I could go on, but in the interest of conserving space I will stop here. So what’s the final verdict on detecting vmware and virtualization? Well… The lower you go the better off we seem to be. Definaately the easier and more complete method of detection would be with scoopy_do or redpill. You have however seen the downfall to redpill, if the OS has stack protection it will segfault. So it is in your best interest to KYE and if you don’t… well, your gonna get got!

Just because honeyd.org states that in general high interaction honeypots are physical machines doesn’t mean they are correct. I’m sure there are plenty of low budgets out there. Not to mention the awesomeness of virtualization. When it comes to virtualization you can revert back to snapshots. Granted, in order to revert back to a snapshot you have to take them! Why is this feature great? Well, if an attacker breaks into a honeypot and runs rm –rf / your honeypot is pretty much gone. Aside from that, after attackers obtain their foothold, they have a tendency to do some patch work and make the system more secure so others can not tread upon their domain. If a researcher wanted to they could “revert” their images after each break in.

One of the fundamental reasons I began this research was to identify and counter honeypots. In order to start our journey we start at the detection of virtualization. Detection of virtualization is important because many honeypots are in fact running in a virtual machine. If we detect virtualization there is a very good chance the victim machine is a honeypot and caution should be taken from there on out. From yesterdays post we recall that attacking a honeypot is useless and only burns any custom tools an attacker may have. By detecting virtualization we can start poking further for evidence of sebek or other monitoring.

The first method is using redpill by Joanna. The heart of which is the SIDT instruction in the c code “which stores the contents of the interrupt descriptor table register (IDTR) in the destination operand” As Joanna points out the interesting aspect of this is that it can be accessed from ring 3, and it returns sensitive data. The functionality is best explained by Joanna in her write up on her site. I have to say that MC led me into a route of research this morning on the IDT. I have to admit that before this morning I had no clue what it was nor did I have the ability to explain how redpill worked. I don’t think I can explain it right now if you caught me on the street! Anyhow I digress. Redpill was tested on VMWare 4 and Virtual PC. I tested it on a windows xp SP0 box running in VMWare 6 and received the following result:

There are a few nuances about Redpill though! The first nuance of redpill is its inability to run on an OS with some type of stack protection such as PAX, X^W, grsecurity. In the code there is a variable called rpill, this variable is not marked as executable. There are about three methods of bypassing the stack protection outlined on invisiblethings.org I won’t go into them. I actually learned this aspect about redpill the hardway. I was attempting to detect virtualization on fedora core 6 inside vmware 6 and redpill segfaulted. Thus beginning a side step in research!

Additionally, the second nuance I will discuss is something that was discovered by danny quist and val smith in a paper titled “Detecting the Presence of Virtual Machines Using the Local Data Table.” Through their research they discovered that “49.64% of the time a piece of software implementing the SIDT VM signature technique (redpill) will incorrectly detect that it is running inside of a virtual machine.”

Ref:

http://www.invisiblethings.org/papers/redpill.html

http://www.offensivecomputing.net/files/active/0/vm.pdf

We start off by defining what a honeypot is. We can go into a verbose and elaborate definition but what it comes down to is; a tool for research. Honeypot’s help researchers and whitehats to study attack methodologies of attackers. Since the monitoring is done on multiple tiers it is more effective. The advantage of honeypot monitoring over NIDS is that monitoring can take place at the endpoint. This allows researchers to obtain key strokes, and binaries used by the attacker. Why are honeypots interesting to us and why would we want to avoid them? Well, from an attacker perspective any good hacker will have custom code, custom exploits and such. Encrypting channels can only do us so good, but if we compromise a honeypot we are jeopardizing a lot of our binaries and code. Beyond that, most hackers attack with an objective. A honeypot is a rather useless jump point since some honeynets alter shellcode, probes and other traffic leaving the network. All that would be accomplished is burning a few binaries thus having to recreate everything!

Honeypots come in different flavors. They can run any operating system, and any service that an operating system can run. The two flavors of honeypots are high interaction and low interaction. High interactions honeypots are harder to detect because they simulate a full out operating system. Low interaction honeypots on the other hand only simulate parts of an operating system such as the network stack. Exploitation and escalation on a high interaction honeypot is feasible and likely. Low interaction honeypots on the other hand is not since they only simulate services, but not completely. Low interaction honeypots are mostly used to learn and detect network probes and worm activity. The high interaction honeypots on the other hand are the traps for attackers.

When it comes to installation devices for honeypots there are two flavors again. They are virtual and physical. Virtual honeypots exist in the sense that a physical machine is hosting the honeypot on a virtual server such as VMWare. Low interaction honeypots from what I’ve read at honeyd.org take the form of a virtual machine. High interaction honeypots however are (again from honeyd) mostly physical.

I have embarked on a new topic for research. The topic is nothing new but it has been in the back of my head for the past few weeks and I finally decided to devote a few weeks to it. The topic mainly has to do with detection and evasion of honey pots. Like I said the topic is nothing new but it interested me. I have found quite a bit of information on the topic unfortunately the majority of the information I’ve found is old and I can’t be sure it still works. So, my goals for my research are as follows:

1. Obtain a better understanding of honey pots and honey nets.
2. Obtain a firm understanding of specifically; honeyd and sebek
3. Discover ways to identify/detect the presence of honeyd
4. Discover ways to identify/detect the presence of sebek
5. Discover a way to disable current versions of sebek.

One thing outlined in the KYE article on Sebek from http://www.honeynet.org is the fact that sebek works in a very similar fashion to the adore root kit. Sebek is basically a loadable kernel module which is then hidden via unlinking of the linked list. The article from the KYE paper says that it is possible to discover the presence of sebek via root kit detection methods; however this paper was last modified in 2003. Since then many versions of sebek have been released. PHC also wrote quite a few articles on detecting honey pots/nets but these were also written a long time ago and were for the most part specific to versions of sebek. I’m hoping to achieve my objectives as well as release a paper on the subject.