View
79
Download
0
Category
Preview:
Citation preview
Honeynet Height Interactive Tool Sebek3 Detecting
Techniques
Dr.Farraj Aizzden, Mohammed Almehdhar, Mohammad Ismail Amro King Fahd University of Petroleum and Mineral
fazzedin@kfupm.edu.sa , g200804340@kfupm.edu.sa ,mamro@kfupm.edu.sa
Abstract
It is usually assumed that new versions of SEBEK are hard to detect and
solve all the problems in the previous version that attempts to detect them
can be unconditionally monitored. we focused on creating a virtual
honeynet using VMWARE as proof of concept of honeynets, and
scrutinize this assumption and applying methods that attackers used to
detect the previous version of SEBEK (version 2) and applied them on
the new version of SEBEK (version 3) and check also if there are any
new methods to do the same on SEBEK 3.
I. Introduction :
Sebek is the main capture tools in the honey projects that has been
detected by several ways ,the new version of sebek(sebek3) should solve
all problems with the previous version .In this term paper we build a
virtual honeynet to check if the sebek3 still have the same problems as
old version and if there are new ways to detect it .
The Honeynet Projectis an international volunteer organization dedicated
to computer security
research. It was founded in 1999 and holds non-profit (501c3) status in
Illinois, USA. Membership is drawn from active chapters in over 25
countries, which helps to provide a global research perspective, and the
organization is strongly committed to the ideals of the Open Source
movement[1] .The goal of the Honeynet Project is to learn about “the
tools, tactics and motives involved in computer network attacks”, which
is primarily carried out through the use of honeypots and honeynets
(networks of honeypots). A honeypot has been defined as “a security
resource whose value lies in being probed, attacked, or compromised"[2].
Honeynets
are one type of honeypot. A honeypot is a resource who's value is
in being probed, attacked or compromised. A Honeynet is a high-
interaction honeypot, meaning it provides real operating systems for
attackers to interact with. This high interaction can teach us a great deal
about intruders, everything from how they break into systems to how they
communicate and why they attack systems..
A virtual Honeynet
is a solution that allows you to run everything you need on a single
computer. The term virtual because it all the different operating systems
have the 'appearance' to be running on their own, independent computer.
These solutions are possible because of virtualization software that allows
running multiple operating systems at the same time, on the same
hardware. Virtual Honeynets are not a radically new technology, they
simply take the concept of Honeynet technologies, and implement them
into a single system. This implementation has its unique advantages and
disadvantages over traditional Honeynets. The advantages are reduced
cost and easier management, as everything is combined on a single
system[3].
A Self-Contained Virtual Honeynet
is an entire Honeynet network condensed onto a single computer. The
entire network is virtually contained on a single, physical, system. A
Honeynet network typically consists of a firewall gateway for Data
Control and Data Capture, and the honeypots within the Honeynet. Some
advantages of this type of virtual Honeynet(s) are:
Portable, Virtual Honeynets can be placed on a laptop and taken
anywhere. The Honeynet Project demonstrated this funtionality at
the Blackhat Briefings in August, 2002
Plug and Catch, You can take the one box and just plug it in to any
network and be ready to catch those blackhats. This makes
deployment much easier, as you are physically deploying and
connecting only one system.
Cheap in money and space, You only need one computer, so it cuts
down on your hardware expenses. It also has a small footprint and
only takes one outlet and one port! For those of us with very
limited space and power, this is a life saver.[4]
There are some disadvantages:
Single Point of Failure, If something goes wrong with the
hardware, the entire honeynet could be out of commission.
High Quality computer, Even though a Self-Contained Honeynets
only require one computer, it will have to be a powerful system.
Depending on your setup, you may need a great deal of memory
and processing power.
Security, Since everything might be sharing the same hardware,
there is a danger of an attacker getting at other parts of the system.
Much of this depends on the virtualization software, which will be
discussed later.
Limited Software, Since everything has to run on one box, you are
limited to the software you can use. For instance, its difficult to run
Cisco IOS on an Intel chip.[4]
Honeypot taxonomy
There are two primary categories of honeypots, research and
production. Additionally, there are two types of honeypots, high-
interaction and low-interaction, depending on what they allow attackers
to accomplish. Lastly, there are honeynets, or groups of honeypots,
designed to look like a network (Gen I and Gen II). This subsection will
discuss honeypots and the next subsection will discuss honeynets
generations.
Honeypot Categories
A research honeypot is deployed to collect information on new
attacks and the blackhat community. Usually, detecting an attack is very
difficult and a time-consuming work. However with a honeypot, since it
does no actual work, any activity on the honeypot machine is
immediately assumed to be malicious. Therefore, if an administrator
suddenly sees traffic going into the honeypot, he can begin to inspect that
traffic and determine exactly what its purpose is. If the traffic is deemed
to be malicious, the administrator must then decide when enough data has
been collected and the honeypot can be shut down for analysis.
A production honeypot is deployed (usually in a business setting)
for the purpose of mitigating security risks in an organization. Production
honeypots protect a network as follows. First, a honeypot does not only
detect threats from the Internet, but if deployed on an internal network, it
can also detect insider threats (because insider criminals will access the
honeypot to obtain information). Second, a honeypot can be a good
barometer of threats against the network. Third, by making a honeypot
seem very valuable to an attacker, a good administrator can lure in a
hacker, and have them spend their resources exploiting the honeypot
when they would otherwise be compromising the general network.
Honeypot Types
High-interaction honeypots are honeypots that do not emulate the
operating systems. Instead they are full operating systems and
applications found in many homes and organizations today. These
solutions are more time consuming than low-interaction solutions, but can
potentially capture more types of information and in greater depth [11].
Low-interaction honeypots are honeypots that emulate computers,
services, or functionality. These are easier to deploy, but may be limited
in the amount or type of information they can collect. Examples of this
type of honeypots include Nepenthes, honeyd, and honeytrap.
Honeynet Generations
Generation I
Gen I Honeynets were developed in 1999 by the Honeynet Project
(Figure 1). The purpose of Gen I Honeynets was to capture the maximum
amount of attacker activity and give them a feel of a real network. The
architecture of Gen I Honeynets is uncomplicated. The approach used for
data capture and data control is simple, which makes it detectable by
attackers sometimes. However, it can capture large amount of
information and even can help in capturing unknown attacks. [12]
Figure 1. Gen I honeynet architecture [2]
The ability of this architecture to control and capture attacks makes
it very effective in capturing known, automated, and beginner level
attacks. However, it is not effective in capturing advance attacks because
it can be easily detected by advanced attackers. Data Control is done by
putting a layer three firewall in front of Honeypots. The firewall works as
a gateway in NAT (Network Address Translation) mode and controls all
the inbound and outbound connections. It allows all inbound connections,
but limits outbound connections. The firewall keeps track of all the
outbound connections an attacker makes, and when a certain limit is
reached, it blocks all outgoing connections from the Honeynet. [12]
As we know that the purpose of data capture is to log as much
information as we can without attackers knowing it. In Gen I Honeynets,
data logging is done on multiple layers to avoid single points of failure.
The first layer of data logging is a firewall. We do not get detailed
information through firewall logs but any information available is helpful
in the case of a Honeynet. Firewalls give information about the
source/destination IP address, source/destination port, protocol, and
date/time. The second layer of data logging is the IDS. An Intrusion
Detection System (IDS) is deployed on the gateway, which logs every
packet and its payload traveling on the wire. IDS logs provide most
useful information about every packet traveling to and from the
Honeynet. IDS also raise an alert when it catches any suspicious activity.
The third layer of data logging is the system logs which log the attacker’s
activity on the Honeypot itself. The keystrokes and screenshots are
captured by installing a modified version of bash or a kernel module. The
logs are securely forwarded to a remote server over the network to
analyze them. The disadvantage of transferring the logs over the network
is that it can be easily detected by an advanced attacker. [16]
Generation II
Gen II Honeynets, shown in Figure 2, were developed in 2002 by
the Honeynet Project after identifying the problems and issues in Gen I
architecture. The problems in Gen I were solved by changing the
architecture of Gen II Honeynet. In Gen I architecture, the firewall works
on layer three which is easily detectable. This problem is addressed by
deploying a layer two gateway device, which makes it harder to detect.
[12]
The firewall works in a BRIDGE mode and controls all the
inbound and outbound connections as in Gen I architecture. This
connection control mechanism allows only a predefined number of
connections to be initiated from the honeynet to the honeynet
administration stations. The new ability added to the gateway in Gen II is
the IPS (Intrusion Prevention System). Basically, IPS is similar to the
IDS but has also the capability to block and modify the attacks. As we
know, most of the IDSs have a signatures database of known attacks. So,
if the packet traveling on the wire matches the signature, the IPS can
block or even modify that packet. This capability helps in distinguishing
between legitimate and malicious activity. If an attacker would try to run
an exploit against a non-Honeypot system, the IPS would be able to block
or modify the attack with known signatures even if the number of
connections initiated is still bellow the allowed limit. The IPS mechanism
works with known attacks only, so unknown attacks can bypass this
technology. For that reason, the IPS is combined with a connection
control mechanism. Using the connection control mechanism, unknown
attacks will be blocked after a certain limit of connection trials even if it
does not match any signature. The mechanism of using L2 bridge firewall
in honetnets Gen II instead of L3 firewall that were used in honeynets
Gen I makes the Honeynet harder to detect as the bridges are very hard to
identify. [13]
Figure 2. Gen II honeynet architecture [12]
The data capture mechanism in Gen II is somehow similar to the
mechanism used in Gen I. Data logging is done on three layers: firewall
layer, network layer (IDS) and system layer (SysLog). The most difficult
part is to capture the attacker’s activity on the Honeypot itself. Sebek is
the newest and greatest development that has been done for data
capturing during Gen II. A data Collection and Alerting mechanism is
also introduced in Gen II Honeynets. The data Collection mechanism
allows the collection and analysis of the data from distributed Honeynet
deployments. The alerting mechanism notifies if someone breaks into the
Honeynet, which helps in keeping track of the activity. [12]
Generation III
Gen III honeynets were released in the end of 2004 [13]. Gen III
has similar architecture to that of Gen II. The only difference between the
two architectures is that Gen III has more improvements in the
deployment and management [13].
In our term project, we deployed virtual homemade high
interaction honeypots with the honeywall gateway version 1.4 which is
the latest version of honeywall CDROM. This version of honeywall was
distributed to meet the requirements of deployment and management for
Gen III honeynets. There are no major changes between Gen II and Gen
III. For that reason, we designed our honeynet on the basis of Gen II.
Sebek
is a new way to capture the activities of an intruder on an Linux
and Windows systems was developed: A kernelbased Sebek [2] is able to
record all data accessed by users via the read() system call on the
honeynet. It replaces the normal read() system call with a new entry in the
system call table pointing to its own versio of this system call. It is then
able to record all data accessed via read() [3]. Because Sebek lives
entirely in kernel-space and has access to all data read, this rootkit is able
to access most communication unencrypted and it can for example log
SSH-sessions, recover files copied with SCP
and record all passwords used by intruders. The recorded data is
sent via UDP to the Sebek server, the other part of Sebek’s client/server
architecture. This transmission is done by modifying the kernel in order
to hide these packets such that an intruder can not see them. In addition,
all network counters and data structures have to be readapted in order to
make detecting these changes more difficult. Further information about
Sebek and its architecture can be found in [3].
In this paper we reuse that a qualified attacker ways to detect
Sebek2 and apply them on Sebek 3 , to check weather these problems
has been solved in the new version of Sebek(sebek 3) and if there any
new method to detect sebek 3. The paper is outlined as follows: Section II
gives an overview of , related work in the field of detection of honeynets.
Several ways to detect Sebek, , an overview of our honeynet and
methods to detect sebek , are presented in section III. Directions of
further work areoutlined in section IV and we conclude this paper with
section V.
II. Related work
Unfortunately, there is little scientific literature on the topic of
honeynets and none on detecting Sebek 3. The only related work was
published for Sebek 2 such as two fake issues of Phrack [4], a Hacker
magazine that is famous for its articles in the blackhat community. In
Phrack 62 [5] an article entitled “Local Honeypot Identification” was
published. It describes a method to disable Sebek by just overwriting
Sebek’s read() system call in the system call table with the original value
and thus disabling Sebek. detect the existence of Sebek on a host were
also presented in the article Another idea to defeat Sebek was published
in issue 63 of the Phrack magazine [7]: The article “Advanced Honey Pot
Identification” describes a way to search through memory and look for
characteristic symbols used by Sebek. Issue 61 of the Phrack magazine
contained an article on detection of hidden kernel modules in its
“Linenoise” section [8]. The article describes a brute force method for
detecting hidden modules by looking for what appears to be the key
module structure. This method was able to locate a hidden Sebek module.
There also is a tool named chkrootkit which “is a tool to locally check for
signs of a rootkit” [9]. While the documentation claims that the tool is
able to detect Sebek, this is only true for very old versions of Sebek.
Detecting is accomplished by searching /proc/ksyms for the string several
ways to detect and circumvent Sebek.
Detecting Sebek
Sebek is a kernel module, so it leaves several traces of its existence
in memory. We now describe ways to track down those traces, thus
leading to the detection of Sebek. One of our first experiments originally
was aimed at making logging by Sebek unreliable. An easy way to detect
Sebek which can be used even by unprivileged local users:
user@honey:~ dd if=/dev/zero of=/dev/null bs=1
This simple command results in backward running packet and byte
counters of the network interface, so even an unprivileged user was able
to detect Sebek by checking the output of ifconfig. To understand why
using dd should lead to unreliable logging by Sebek, one has to take a
closer look at the logging process: As explained above, Sebek replaces
the normal sys read() call in the system call table with its own version and
is thus able to record all data accessed via read(). The logging data is then
transfered in a covert way via UDP over the network[3]. Therefore, if we
are reading a single byte via a read(1), Sebek has to transfer nearly 100
Bytes of data including all the network headers over the network to the
host doing the logging. So if we are able to do a read(1) some tens of
thousands of times per second, this will lead to a congested network and
finally to dropped packets. And we are able to identify a congested
network with the help of the ping command.
This leads to another way to detect Sebek, which we call the dd-
attack, since it can accomplished with a simple command like dd, as
shown above. To detect Sebek on a host, we first ping a local IP-address
(e.g. the gateway) in order to get an overview of the current performance
of the network. Then dd is started in the background and we rerun the
ping command. If Sebek is installed on a host, this leads to an enormous
increase in the average round-trip time. In practical tests of this attack the
average round-trip time grew from 0.7 milliseconds to over 4800
milliseconds.
published in Phrack 63 [7]: Sebek is a kernel module and it has to
use some kernel memory in order to be able to store its variables like
magic number and source or destination port. Version 2.1.7 uses some
randomization and other stealth techniques in order to prevent easy ways
to find these variables, but Sebek leaves some traces in memory that can
be found: • Since Sebek by default chooses a random number below
1000000000 as the module name it is easy to create heuristics to detect
the Sebek module purely by its name in the lists of modules generated by
the methods outlined in [8]. A small obstacle in doing so is that there are
legitimate modules with purely numeric names like 8390, a driver for a
generic Ethernet chipset. Helpful in the detection of Sebek symbols is the
knowledge that all it’s symbol names start with a letter, followed by a
number with up to three digits. Also helpful is the fact that a conversion
table to translate IP addresses into integers is left in memory. In addition
to falsify /proc/net/dev output, Sebek has to keep more than 200 bytes of
strings in memory, which can be located without great effort. The hidden
Sebek module still has a complete module header structure in memory.
This structure can be found with very little effort[8] and used to locate
Sebek’s code (e.g.its cleanup function) and variable storage. While the
placement of variables in Sebek’s variable storage block is different every
time Sebek is compiled, it is still possible to locate the variable storage
block via the module header. That information can be used to
successfully guess most variables like magic number, source and
destinationport with a few tries. All these traces can be found by
traversing memory an looking for appropriate structures and thus leading
to a way to detect hidden kernel modules, identify the Sebek kernel
module and extract secrets from the module. In [5], a way to detect the
changes in the system call table for Solaris is proposed. When Sebek
installs its read() monitoring function, it replaces the function pointer in
the system call table at NR read with a pointer to its own function,
declared in the module. While on a system without Sebek, the system call
pointers are close to one another in memory, this changes if Sebek is
loaded into memory. The address of Sebek’s function does not lie near
the address of sys write, the successor of sys read in the system call table.
Thus, if the addresses of sys read and sys write lie far apart (e.g. more
than 4096 byte), we conclude that the system call table was modified by
some rootkit. Furthermore, there is another similar way to detect Sebek:
After Sebek has replaced the function pointer in the system call table, sys
read points inside the memory range of a module. This is a clear sign that
the system calls were changed and a rootkit is present. We wrote a
program that searches through memory and finds both of these anomalies.
Approach:
In this paper , we introduce methods that used to detect sebek2 and
apply them in sebek3 . Specifically. We tried to detect sebek with direct
command line in Linux and Windows based,write a program to check
system call table ,we also use an API programs to check the existence of
sebek.
Our homemade honeypots as virtual machines. Honeypots have
been installed with VMWARE Workstation. VMWARE allows different
machines that run different OSes to run on the same computer system
[14]. We deployed four virtual machines as honeypots. One machine runs
Windows-XP. The other machine runs Ubuntu-8.1. All systems placed
within the honeynets are standard production systems. These are real
systems and applications. These honeypots are meant to be probed and
attacked. Figure 1 shows a scheme.
figure3:Virtual Honeynet Architecture()
We have configured the honeywall and put it on VMWARE
machine with the honeypots in a virtual team.We started our mission with
DD attack method (see Detecking sebek A) this method has applied for
both systems win32 and linux .In windows we have opened two
command line the first one to measure the round –trip time using ping
command before copying files and during copying process ,and we found
that :
Stat Round Trip
Time (millisecond)
Before
copying
0.4
During copy
(1)
60
During copy
(2)
15
Linux
Before
copying
0.7
During copy
(1)
45
During copy
(2)
20
Table 1
As shown in table 1 that sebek3 has solved the problem of
generating the huge traffic (due DD attack) which reduced the TTL from
about 7200mms to 60mms .and even this it will give some sing to the
existence of sebek but it will not much clear as which in sebek2.
The second method we applied is In [5], a way to detect the
changes in the system call table we carried this idea forward and
implemented it: When Sebek installs its read() monitoring function, it
replaces the function pointer in the system call table at NR read with a
pointer to its own function, declared in the module. While on a system
without Sebek, the system call pointers are close to one another in
memory, this changes if Sebek is loaded into memory. The address of
Sebek’s function does not lie near the address of sys write, the successor
of sys read in the system call table. Thus, if the addresses of sys read and
sys write lie far apart (e.g. more than 4096 byte), we conclude that the
system call table was modified by some rootkit. This is a clear sign that
the system calls were changed and a rootkit is present. We wrote a
program that searches through memory and finds both of these anomalies.
As an example, table 2 shows the places of two system calls in memory
before and after Sebek is loaded. One can clearly see that the system call
table was modified and something malicious is happening.
System
Call
Address Before Address After
Read C014C91C F8BEE8840
Write C014C97F C014C97F
Table (2)
Detecting Sebek Useing Anti Rootkit Software:
Rootkitrevealer:
The term rootkit is used to describe the mechanisms and techniques
whereby malware, including viruses, spyware, and trojans, attempt to
hide their presence from spyware blockers, antivirus, and system
management utilities. There are several rootkit classifications depending
on whether the malware survives reboot and whether it executes in user
mode or kernel mode. Because Sebek is a rootkit-style kernel module we
use new anti Rootkit open source software to detected sebek in its register
record figure show the sebek hidden register key, figure 4 show the
traffic that sebek send to sebek server when this tool do the scan, we can
solve this problem by hooking the cmd and rewriting the output that
contain sebek string.
Show Kernel Active Process List
Sebek can also be identified on Windows looking at loaded drivers,
we use the KProcCheck with -d parameter that will print a list of all
loaded drivers by tranversing the PsLoadedModuleList ,the result show
Figer 4 sebek hidden register key
that sebek 3 solve this problem by give new name other than sebek to its
module in configuration step .
IV. Conclusions
From all the methods used in this paper we conclude that, Sebek 3
has been solving some problems that presented in sebek 2, but on the
other hand we have shown that Sebek 3 can be detected. An
unsophisticated attackers might not be able to circumvent Sebek 3 or not
even try to do so, we assume that sophisticated attackers can detect
honeynets .If there are already very advanced techniques of detecting and
disabling honeynets discussed in the open wild [5], [7], we have to
assume that there are much more evolved techniques available to highly
advanced attackers and there is always new ways to defeat it .
V. Further work
There is a broad range of possibilities to enhance our work in
further detecting sebek 3 . For further detecting Sebek we see lots of
possibilities. Some of them include:
• Sebek leaves many traces in memory: It is a kernel module and thus
uses some special data structures, it uses characteristic variables and
builds UDP packets in memory. Therefore it should be possible to search
through memory and detect its existence in several other places than by
looking for module structures.
• Hook into the low level networking layer at the level of the
network drivers to unhide Sebek’s logging packages. If we turn the table
again and take the view of a honeynet researcher, we see some topics of
interest in order to harden Sebek and its general approach to log activities
of intruders:
• Obviously, transforming Sebek to be a kernel patch instead of a
loadable kernel module should be aspired. Detecting and removing Sebek
if it is not dynamically loaded as a kernel module would be much more
difficult and installation after a reboot would become a non-issue. On the
other hand, deployment of Sebek would get complicated by doing so. In
our opinion this is actually desirable, since
honeynets are dangerous and ethically problematic tools and
entities wishing to deploy honeypots should be willing and able to got to
the pains of patching and compiling a kernel.
• Adding further cleaning of module structures in memory after
installing the Sebek kernel module, using a less predictable way of
generating the “random” symbol and module names.
• Further obfuscating the placement of Sebek’s variables in
memory and adding decoy variables.
• Using source and destination ports and MAC addressees in
addition to the magic number when identifying Sebek packages to extend
search space from 248 to 2160 Packets when brute-forcing.
On the other hand from all these methods we can gain what
problems are still sebek suffer and try to fined new solution for all these
problems
References
[1] “The honeynet project.” Internet: http://www.honeynet.org/.
[2] Know Your Enemy: Honeywall CDROM Roo, 3rd Generation
Technology”. Honeynet Project & Research Alliance,
http://www.honeynet.org. August, 2005
[3] “Sebek.” Internet: http://honeynet.org/papers/honeynet/tools/sebek/,
2004.
[4] The Honeynet Project, “Know your Enemy: Sebek,” November 2003.
http://www.honeynet.org/papers/sebek.pdf.
[5] “Phrack magazine.” Internet: http://www.phrack.org/.
[6] J. Corey, “Local Honeypot Identification,” September 2003.
http://www.phrack.org/fakes/p62/p62-0x07.txt.
[7] “Snort inline.” Internet: http://snort-inline.sourceforge.net/, 2004.
[8] J. Corey, “Advanced Honey Pot Identification,” Januar 2004.
http://www.phrack.org/fakes/p63/p63-0x09.txt.
[9] madsys, “Finding hidden kernel modules (the extremway),” 2003.
http://www.phrack.org/phrack/61/p61-0x03_Linenoise.txt.
[10] “chkrootkit homepage.” Internet: http://www.chkrootkit.org/.
[11] The Honeynet Project, “Know Your Enemy: GenII
Honeynets,”November 2003. http://www.honeynet.org/papers/gen2/.
[12] m1lt0n, “Keeping 0day Safe,” Januar 2004.
http://www.phrack.org/fakes/p63/p63-0x08.txt.
Recommended