OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Vendor Response Re: Mantrap Advisory Vendor Followup - Fate Research Labs
From: Fred Kost (fkostRECOURSE.COM)
Date: Tue Nov 07 2000 - 01:34:41 CST


Recourse Technologies worked with Loki at F8 Labs
last week to review the advisory and v1.6 ManTrap
results. In the latest shipping release (v 2.0 with
most recent patches), all of the signatures are either
fixed or alarmed (see problem 6). Recourse
Technologies will upgrade all ManTrap 1.x customers
free of charge.

VENDOR RESPONSE TO FIRST ADVISORY
Mantrap By Recourse Technologies - Fate Advisory
(11-01-00)
Problem 1, 2&3, 4, 5
RESPONSE: Fixed in v2.0 with latest patches from
Recourse Technologies.

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.

RESPONSE: To do this attacker needs root on the
box and a fair amount of skill. Even if they have both,
ManTrap notices and alerts and logs, serving its
purpose in exposing an attacker. The purpose of the
ManTrap and a decoy is not eternal deception, but
identifying problems as soon as possible. If attackers
have to spend time worrying about deception, itís
done part of its job.

VENDOR RESPONSE TO ADVISORY FOLLOW-UP
Mantrap Advisory Vendor Followup - Fate Research
Labs (11-05-00)
F8 LABS POSTING
However, there is one more catch. Recourse was not
able to Repair the 'crash' utility problem, so it still
exists in the newest release. As we stated in our
advisory, it is possible for an attacker to view all
processes outside of the cage, which still allows for
fingerprinting and identification of the fact that they
are in a caged environment or honeypot.
This is not the worst, as it is still possible to get the
PID of those processes to further allow the attacker
to kill() the running process from within the cage.
Their exists several cage processes (rti_???), which
controls logging and other Mantrap functions, which
are included in this list of processes. The ability to
shut down logging functionality for the cage wipes
away all possible recourse (no pun intended:), for
further action against the intruder.

RESPONSE
This is related to problem 6 of the original F8 Labs
advisory. It is true you can use /usr/sbin/crash to
fingerprint a ManTrap but v2.0 doesnít allow killing
processes outside the cage.