Honeypots mailing list archives

Honeynet Project Security Advisory 2004-001: Sebek


From: Edward Balas <ebalas () iu edu>
Date: Thu, 22 Jan 2004 14:02:21 -0500 (EST)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Honeynet Project Security Advisory 2004-001: Sebek
==================================================

Topic:      Linux client information disclosure vulnerability

Version:    All

Severity:   If best practices are NOT followed, this vulnerability
             allows an intruder to identify the Data Collection
             host.

             Even if best practices are followed this vulnerability
             allows an attacker to identify the presence of Sebek
             on a host.

Summary:    If a user has root access, they can examine /dev/kem to
             find identify the start of the Sebek kernel module as
             well as the client configuration.




Details:
========

A Recent article on anti-honeypot technology has been made
available. Phrack reports this article to be Phake but provides
access at:

        http://www.phrack.org/fakes/p63/.


This article has a section concerning Sebek, specifically the
Linux client and the server.  The article provides a proof of
concept application named sebek_rape.c.  This application, run as
root, scans /dev/kmem, identifies a symbol which is unique to the
Sebek kernel module, then proceeds to recover the Sebek client
configuration.  The symbol in question is "__insmod_sebek_S.data".
This symbol is not located within the kernel module itself but is
a ksymoops symbol provided by the kernel for debugging purposes.

Using the data gleaned from the client, the article then goes on to
imply the existence of a tool called phcebek.  This tool supposedly
uses a libpcap 0.81 vulnerability create a sbk_extract exploit.
sbk_extract is the data collector that comes with the Sebek server
distribution, it operates as a network sniffer to gather Sebek
records.  In theory the exploit could create a back-door on the
Data Capture host.  To date neither the existence of a generic
libpcap exploit or phcebek can be confirmed.

Solutions:
==========


In the immediate term, a revised sbk_install.sh script has been
added to the sebek-linux-2.1.4 code.  This installer first changes
the name of the kernel module, then it then modifies the module
loading process to reduce the number of symbols that are left
floating in memory.   This short term fix will cause sebek_rape to
fail , however one should always follow best practices.

      - "-y" flag has been added to the insmod command, this prevents
             the definition of ksymoops symbols for Sebek, which
             with then cause sebek_rape to fail.

      -  a few code changes have been added to make it a little
         bit harder extract the config.

This patched version is available at:

      http://www.honeynet.org/tools/sebek
      16708ad30e2caf8431735439fcb60fd5  sebek-linux-2.1.5.tgz

In the short term, a new version of the Linux client will be
available, that will make it more difficult to detect and extract
the configuration from memory.



Review of Best Practices:
=========================
As an open source technology, it is most likely impossible to
develop a version of Sebek that can not be detected once an attacker
gains privilaged access.  For more information on the risks and
issues facing honeynets, refer to:

        Know Your Enemy: Honeynets
             http://www.honeynet.org/papers/honeynet

Independent of the client implementation there are some practices
that we recommend to minimize the risk in this specific case:

   1.   It is recommended that you run sbk_extract in a chroot
        environment protected with Systrace and, if available,
        your favorite flavor of stack protection.  This
        recommendation applies to all data capture tools run on
        a honeynet data collection server.

   2.   To decrease the likelihood of detection, it is recommended
        that you modify the source of Sebek so that it is different
        from that which is publicly available.

   3.   In typical deployments where Data Capture occurs on a
        bridging firewall, it is recommended that the Sebek client
        be configured to send packets to the IP and MAC address of
        the default gateway.  By doing this, even if an intruder
        recovers the configuration,  the only information
        disclosed is the magic value, and destination port number.
        When possible DO NOT configure the IP or MAC address of
        the server into the Sebek Client.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)

iD8DBQFAEALjulH/ZGBJPj4RAvFMAJ49WUHrMT7PgN7Owfwg+KRDVAiHuACfd9OB
JE+8gkUBLtNLWOcjl5jbARc=
=C0JY
-----END PGP SIGNATURE-----



Current thread: