Re: Honeypot article

[Jon <warchild () spoofed org>]

On Fri, Jan 24, 2003 at 04:40:48PM -0500, R. Anthony Kolstee wrote:

> Tracing the system calls made by sshd can reveal the contents of
> sessions. Test this theory with:
>
>   strace -p ${SSHD_PID} -f -e trace=read,write -e read=4 -e write=6
>
> The output is ugly, but it works...
>
> Couldn't this be turned into an automated tool for honeypot systems that
> detects the presence of an sshd daemon and taps it automatically? 
>
> I know that honeypot systems are kept as close to default installations
> as possible, but this feature would prove extremely valuable. If the
> intruder had erased his history file in the analysis referenced above,
> half the analysis would be at best much harder to perform. There is some
> precedent with the trojaned versions of bash that some honeypot admins
> use. 
>
> A modified sshd is too easily replaced by a rootkit (as is a modified
> bash, for that matter). 
>
> Maybe a nice unobtrusive kernel module? One that "knows" how to identify
> file descriptors that might be "interesting" and monitors all read/write
> syscalls involving them. Is there anything currently out there that
> resembles this notion at all?

One method I've found to be much more foolproof is to have a system sit
between your honeypot and the attacker.  Since the traffic is encrypted,
you have to get creative.  One method I've been particularly successful
with is using iob* to attach to their ssh session.  This way you get all
input and output -- something that history files generally don't get you.

This assumes a setup something like:

[ attacker ] <-----> [ your mitm box ] <-----> [ honeypot ]
     A                      M                       H

Assume you have something like pf running on M forwarding all ssh requests
to H.  When the attacker tries to ssh to your honeypot, they actually
unknowingly login to M without a password.  Their "shell" on M then sshs
them to your honeypot under iob which catches all I/O and logs it.

There are number of difficulties with this approach.  The most difficult
part is how you predict what usernames will be used.  Either you assume
they'll use root or you get creative and somehow detect or predict what
username they will use. 

Something like this is really really worth the effort.  Getting all input
*and* output gives a whole new meaning to "determining the skillset of the
attacker".  Its one thing to read their shell history file and see that
they typed 'nano /etc/passwd', but its an awesome experience to tail -f the
iob log files and watch their activity in real time (including spelling
mistakes, cursor movement, etc etc).  You even get all the terminal colors
and escape codes.  Watching someone recompile my kernel sent shivers down
my spine.

Fortunately, you don't have to cobble something together like I did with
iob.  A while back someone announced a tool that did what you are looking
for.  I  believe it was announced on this list, but I can't recall what the
name was.  Check the archives.

For the record, the shell on box M simply did this

/usr/local/bin/iob -- /usr/bin/ssh -Xl root honeypot 


-jon

(PS.  I'm going to email the fine folks at marc.theaimsgroup.com and see if
they can start archiving this list.  Having a searchable set of archives is
a great thing.)

* http://www.team-teso.net/releases/iob-0.1.tar.gz