Additional Features — Stealth

Samhain
Prev |  | Next

# Chapter 9. Additional Features — Stealth

If an intruder does not know that samhain is running, s/he will make no attempt to subvert it. Hence, you may consider to run samhain in stealth mode, using some of the options discussed in this section.

# 9.1. Hiding the executable

samhain may be compiled with support for a stealth mode of operation, meaning that the program can be run without any obvious trace of its presence on disk. The following compile-time options are provided:

--enable-stealth=`xor_val` provides the following measures:

1. All embedded strings are obfuscated by XORing them with some value xor_val chosen at compile time. The allowed range for xor_val is 128 to 255.

2. The messages in the log file are obfuscated by XORing them with xor_val. The built-in routine for validating the log file (samhain -L /path/to/logfile) will handle this transparently. You may specify as path an already existing binary file (e.g. an executable, or a JPEG image), to which the log will get appended.

   | Tip
   | Use samhain -jL /path/to/logfile if you just want to view rather than verify the logfile.

3. Strings in the database file are obfuscated by XORing them with xor_val. You may append the database file to some binary file (e.g. an executable, or a JPEG image), if you like.

4. The configuration file must be steganographically hidden in a postscript image file (the image data must be uncompressed). To create such a file from an existing image, you may use e.g. the program convert, which is part of the ImageMagick package, such as convert +compress `ima.jpg ima.ps`.

   | Tip
   | make install will do this automatically before installation.

   To hide/extract the configuration data within/from the postscript file, a utility program samhain_stealth is provided. Use it without options to get help.

   | Note
   | If --enable-stealth is used together with --with-gpg, then the config file must be signed before hiding it (rather than signing the PS image file afterwards).

--enable-micro-stealth=`xor_val` is like --enable-stealth, but uses a 'normal' configuration file (not hidden steganographically).

--enable-nocl[=ARG] will disables command line parsing. The optional argument is a 'magic' word that will enable reading command-line arguments from stdin. If the first command-line argument is not the 'magic' word, all command line arguments will be ignored. This allows to start the program with completely arbitrary command-line arguments.

--enable-install-name=`NAME` will rename every installed file from samhain to NAME when doing a make install (standalone/client installation), and likewise rename installed files from yule to NAME when doing a make install (server installation). Also, the boot scripts will be updated accordingly. Files created by samhain (e.g. the database) will also have samhain replaced by NAME in their filenames.

| Tip
| The man pages have far too much specific information enabling an intruder to infer the presence of samhain. There is no point in changing samhain to NAME there — this would rather help an intruder to find out what NAME is. You probably want to avoid installing man8/samhain.8 and man5/samhainrc.5.

## 9.1.1. Using kernel modules to hide samhain (Linux/ix86 only)

| Important
| These modules modify the running kernel. Please read this section carefully (in particular the caveats noted at the end), and test the modules before installing. Without proper testing it may happen that you need to reboot into single user mode to remove the modules and to make your system useable again ...

If the configure option --enable-khide=SYSTEM_MAP is used, two (pre-2.6 kernel) or one (2.6 kernel) loadable kernel module(s) will be built. These are named `samhain_hide.o / samhain_erase.o` (pre-2.6) or `samhain_hide.ko` (2.6).

SYSTEM_MAP must be the path to the System.map file for your current kernel (e.g. `/boot/System.map-rh-2.4.18-3`). `samhain_hide.o` will hide every file/directory/process with the string NAME (from the configure option --enable-install-name=NAME). If the configure option --enable-install-name is not used, NAME is set to samhain. To hide the module itself, the second module `samhain_erase.o` is provided. Loading and immediately thereafter unloading this module will hide any module with the string NAME in its name. make install will install the kernel modules to the appropriate place. They will be loaded when booting into runlevel 2, 3, 4, or 5.

With 2.6 kernels, only one kernel module `samhain_hide.ko` will be build. This module is self-hiding, i.e. the separate `samhain_erase` module is not needed anymore. Otherwise it works as described above. Self-hiding can be switched off by passing the option 'removeme=0' to the module: insmod ./samhain_hide.ko removeme=0

Building a linux kernel module requires a proper build environment. You should have a link `/lib/modules/`uname -r`/build` which points to a functional build environment. Usually, you need to install the kernel sources for your kernel, and eventually (if compiling the modules fails) you may need to configure the kernel source for your kernel:

      sh$ cd /your/kernel/source/directory
      sh$ make mrproper
      sh$ make cloneconfig
      sh$ make dep (obsolete for 2.6)
      sh$ make modules (only for 2.6)
      sh$ cd /lib/modules/`uname -r`
      sh$ ln -s /your/kernel/source/directory build

| Caveat no. 1
| The hiding module will hide any process or file containing the name of the samhain. This implies that an intruder can hide herself if she can guess that name. You are strongly encouraged to use the ./configure option --enable-install-name=NAME to change the executable name to something really difficult to guess.

| Caveat no. 2
| The modules are kernel-specific, and must be recompiled whenever the currently used kernel is recompiled or replaced by another one (even if the kernel version is identical). Failure to do so might lead to a kernel panic. The same is true if the `System.map` that you have specified at build time is not the one corresponding to your current kernel.

| Caveat no. 3
| When the `samhain_hide` module is hidden, the kernel doesn't know anymore about its existence, thus it cannot be removed except by rebooting. On pre-2.6 kernels, hiding the `samhain_hide.o` module requires loading/unloading the `samhain_erase.o` module. On 2.6 kernels, the `samhain_hide.ko` module will automatically hide itself after loading, except if you pass the option 'removeme=0' to the module: insmod ./samhain_hide.ko removeme=0

| Caveat no. 4 - Important Linux 2.6 issue
| The stealth module builds fine on Linux 2.6 (if the build system is properly configured — see above). It was tested on two systems: 2.6.5-7.104-smp (SuSE 9.1) and 2.6.6 (no SMP). It only worked on the latter system, while the first one was rendered unuseable (ls and ps didn't work anymore). Not sure about the reason. Because on 2.6 the module will by default automatically hide itself, and cannot be removed then (except by rebooting), you should test the module with the option 'removeme=0', like e.g.: insmod ./samhain_hide.ko removeme=0

| Tip
| Hidden files can still be accessed if their names are known, thus using the option --enable-install-name to rename installed files is recommended for security (also see caveat no. 1 above).

| Tip
| Using the modules at system boot may cause problems with the GNOME (1.2) gdm display manager (seen on SuSE 7.4 with the Ximian desktop; no problems observed with kdm). In case of problems, you may need to reboot into single-user mode and edit the boot init script ...

Prev | Home | Next
Additional Features — Signed Configuration/Database Files |  | Packing the executable