[17480] in bugtraq
Mantrap By Recourse Technologies - Fate Advisory (11-01-00)
daemon@ATHENA.MIT.EDU (Loki)
Sat Nov 4 01:23:59 2000
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0009_01C044F4.18928B60"
Message-Id: <PGEAJALLCLNHFIPHDCNOIEMMCDAA.loki@f8labs.com>
Date: Thu, 2 Nov 2000 17:41:14 -0800
Reply-To: loki@f8labs.com
From: Loki <loki@F8LABS.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
This is a multi-part message in MIME format.
------=_NextPart_000_0009_01C044F4.18928B60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
-----------------.---------------------------------------------.
/| | . |
/ | : : : : : : |
/ | :: ------ :: : :: | :: - |-----
| | :: : :: . : | | :: : |
| | : . |------| | : |
| | ------^ : | / | .
| ;----------"---------------^------ / ------'---------------------
| / / / /----' / /
|'----------'---------------'------' --------'---------------------'
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/<PID> exists -> Fine
kill() gives EPERM and /proc/<PID> 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 <causes error response>
# cd ../../../../../
# cd proc
# cd self <should receive error response>
# ls, pwd, etc, <BOOM!>
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
================================================================
------=_NextPart_000_0009_01C044F4.18928B60
Content-Type: text/plain;
name="f8-110100-mantrap.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="f8-110100-mantrap.txt"
-----------------.---------------------------------------------.
/| | . |
/ | : : : : : : |
/ | :: ------ :: : :: | :: - =
|-----
| | :: : :: . : | | :: : =
|
| | : . |------| | : =
|
| | ------^ : | / | =
.
| ;----------"---------------^------ / =
------'---------------------
| / / / /----' / =
/
|'----------'---------------'------' --------'---------------------'
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=20
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=20
and studied, and which is also supposed to prevent erasing of logs etc.=20
A great idea - but the implementation is poor. Instead of running as a=20
VMware like virtual machine or such, it just runs as a chroot like =
environment=20
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/<PID> exists -> Fine
kill() gives EPERM and /proc/<PID> 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 <causes error response>
# cd ../../../../../
# cd proc
# cd self <should receive error response>
# ls, pwd, etc, <BOOM!>
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.
------=_NextPart_000_0009_01C044F4.18928B60--
