Vendor Response Re: Mantrap Advisory Vendor Followup - Fate Research Labs

[Fred Kost <fkost () RECOURSE COM>]

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.