-----------------.---------------------------------------------.

  /|                 |                             .               |

 / | :               : :             : :             :             |

/  | ::        ------  ::            : ::          | ::     -      |-----

|  | ::              : ::     .      :      |      | ::            :     |

|  |                 :        .      |------|      |               :     |

|  |           ------^        :      |     /       |                     .

|  ;----------"---------------^------     /  ------'---------------------

| /          /               /      /----'        /                     /

|'----------'---------------'------'     --------'---------------------'

                                www.f8labs.com











[ INTRODUCTION ]



Advisory .........: Nasty tricks with ManTrap

Release Date .....: 11-01-00

Application ......: ManTrap by Recourse Technologies

Vendor Web Site ..: www.recourse.com

Version ..........: All versions prior to and including the newest version

1.6.1

Vendor Status ....: Contacted

By ...............: Fate Research Labs

WWW ..............: www.f8labs.com











[ OVERVIEW ]



ManTrap's intent is to set up a honeypot as a 'cage' which

can be filled with fake information running on a system

where the intruder can be lured and studied, and which

is also supposed to prevent erasing of logs etc. A great

idea - but the implementation is poor. Instead of running

as a VMware like virtual machine or such, it just runs as

a chroot like environment with some kernel patches, and thus

it can easily be identified and subverted. In case an

intruder breaks in and finds out that it's a cage, he/she

will most likely just trash it and move on instead of

fulfilling the purpose of staying long enough to be

studied/identified/traced.





[ ADVISORY ]



Problem 1:

ManTrap hides processes from the caged intruder

(or atleast tries to), by hiding them from the /proc in the

cage (resembles what many LKM trojans do), which sounds fine.



BUT, the cage still runs the SAME kernel as the real box, and

also has access to all kernel memory etc. So what we can do is

to use a syscall, in this case kill(), which gets its information

from the kernel instead of /proc, and compare it's results with

the information in /proc. What we do is to simply send a signal

(SIGCONT in this case) which hopefully shouldn't affect anything,

 to PID 1 to 65535 as a nonroot user, and compare the results with

/proc.



kill() gives EPERM and /proc/ exists -> Fine

kill() gives EPERM and /proc/ does not exist -> Not fine!

This can also possibly be used to detect LKM trojanss and the like.

It might give a false alarm though, as some kernel patches

designed to hide other user's processes might give the same result.

But together with the other tell-tale signs of ManTrap it gives a

very good fingerprint.



Problem 2&3:

This looks like a result from the /proc filtering/emulation

mentioned above. /proc/.. doesn't show up in any syscalls wanting

to get the directory listing! (such as getdents()).

Also, (cd /proc/self; cd cwd; pwd) gives an error.

Another interesting note is that the whole box can be made to lock

up and disconnect all users for a couple of minutes by doing:

   # cd /proc && cd self && cd cwd

   # pwd 

   # cd ../../../../../

   # cd proc

   # cd self 

   # ls, pwd, etc, 





Problem 4:

ManTrap accidentally seems to hide the first 4 processes always

running on a Solaris box (sched, init, fsflush, pageout).



Problem 5:

Since / isn't the real root of the filesystem, but /usr/rti/cage/root,

the inode number is very off, usually in the 100000-200000 range

instead of the normal 2. This can be checked by simply doing `ls -id /`.



Problem 6:

If the intruder got root in the cage, it's very possible to read/write

directly to/from /dev/mem, the raw disk device[s], etc.

The crash(1M) utility can be used to examine /dev/mem and get the real

process listing etc, which includes all ManTrap's processes. (Yes, they

can be killed...)



More serious damage can be caused using the raw disk device[s], such as

/dev/rdsk/c0t0d0s0. ANY data on the system can be read/modified by the

intruder, which can be used to wipe logs and such.

An utility such as fsdb(1M) can be used to view the directory listings

etc.





[ EXPLOIT? ]



We've written a small program to demonstrate problems 1-3. It's

capable of identifying ManTrap using these methods, and also list

all 'hidden' processes. It's available from <http://www.f8labs.com>.





[ FINAL WORDS ]



This basically shows that you can't rely upon anything but a

total instruction-level emulation to make a real-looking and

yet secure cage. We look forward to such a product as it would be

a great tool in intrusion detection. As VMware shows, this can be

done atleast on x86 CPUs and it would surprise me if it wouldn't

be possible on other platforms (such as Sparc).



One key thing to take in mind when deploying a honeypot is to take

special care in the architecture of the deployment. Place particular

attention on where in the network it is deployed. It is reccomended

that if an organization does deploy any honeypots, the systems are

firewalled off in a secured, second DMZ.





================================================================

Loki

Fate Research Labs

loki@f8labs.com

----------------------------------------------------------------

BEGIN PGP SIGNATURE



iQA/AwUBOfZvfGnwBJRV5bxfEQJu7gCfQ/T0O9u75nzRGWVSeurNmnFRVr8Anj0c

M+UXhPDBvsm+ffRpv41zevQN

=3IRx

================================================================