[Cs22800] Robustness of BSD Sebek port, methods for covert transmission

[Benjamin Johnson]

Hey,

Mike O'Donnell wrote:

>Regarding the port, I hope we can get into one more layer of detail
>soon. In particular, I wonder how robust the port can be
>w.r.t. further changes to Sebek. Will Ben, or his successor, need to
>do additional configuration work for each such change? Or, can we
>provide patches to the core Sebek group so that they can produce a
>distribution that compiles automatically to BSD as well as Linux.
>  
>

So far, it looks like we might need a maintainer for the BSD version.  I 
want to stay with the honeynet group for a while so I figure I'll be 
able to.  I plan on trying to port this to the other BSD's as well as 
maybe OS X and Solaris, so BSDsebek will give me a good start.  The 
helper applications should be "compilable" in both linux and bsd, as Ed 
already began doing that earlier and i will finish it / touch it up. 
 The real problem is with the kernel modules.  I suppose you could do a 
lot of #IFDEF FBSD { } and stuff in the module.c, but that seems a 
little too ugly for the whole kernel module to be like that.

>The answer depends to some degree on how the core Sebek project is
>organized. Have they used the autoconf/automake/libtool types of
>tools, and if so, how well? I've done a bit of this, and it seems like
>a horrible black art. The individual pieces of documentation for make,
>autoconf, automake, libtool are hard to integrate into an
>understanding of the whole task. Somewhere in the Gnome project's Web
>space I found a pretty good how-to for the whole thing, at least in
>one reasonably workable style.
>  
>

We use makefiles for the helper applications and for the kernel modules, 
although kernel modules (especially the BSD ones) seem to have a 
slightly different style.  Since the configuration also involves 
deciding where to have the driver, what to call everything, what you 
want the deceitful packets to look like, etc, I believe we will end up 
writing a bash or csh script to prompt the user for answers to all these 
questions.  I actually wrote some scripts this summer that did this, but 
they now have to be redone to accompany newer features and changes that 
have been made in sebek since.  Also I am hoping that if sebek becomes 
useful that we can code up a gui installer, or at least a "gui-text type 
of installer (i guess maybe using ncurses? I'm not a gui person at all).

>Covert transmission
>-------------------
>
>This isn't Ben's chosen topic, but we might as well think about the
>whole Sebek project a bit. In the note from Ed that Ben posted on 28
>September, there's a lot of influence on the problem of dumping
>Sebek's data to another host across a LAN without arousing the
>intruder's suspicions. That sounds inherently difficult to me. Is it
>feasible, instead, to use a separate network connection for dumping
>Sebek data? 
>
Yes, feasable.  Ed told me that some of the people who setup honeynets 
want the traffic dumped onto the wire.  On a side note, and this isn't 
public knowledge (so please keep it to our class although I don't think 
the feds will come banging down any doors), Ed has written some code 
that will cause packet sniffers to not capture the traffic we dump onto 
the wire.  I haven't had time to see this yet but Ed is a good coder so 
I assume it works pretty well.  Therefore, unless the hacker gets into 
other systems on the network (which usually the way a honeynet is setup 
he won't), they will not see any unusual traffic.

>This could be a separate ethernet, or just a parallel port
>or a serial port, or maybe a USB. It looks to me like the big question
>is how well can you hide such a port and its activity from the
>intruder. In principle, it sounds very feasible. Take the device
>driver code, and hide it in a file somewhere, and invoke it directly
>instead of using the usual /dev interface. If this works, in principle
>you might even write to a covert disk, or better a write-once
>device. But there might be snags in the details. And the attempt to
>have a covert peripheral device might run afoul of attempts to make
>device detection and configuration automatic---maybe a modern BIOS
>will even interfere.
>  
>
Yah, these are all good ideas.  I'm hoping to explore some of them 
possibly over winter break and into winter quarter.  Unfortunately, I 
believe that the porting along with testing and documentation, might end 
up taking the rest of the quarter.  I keep running into bugs...it works 
pretty well right now, but everytime it crashes I have to try to 
decipher some crazy kernel panic message.  I recompiled my kernel so 
that it has all the debugging possible, but even when I get an error I 
can somewhat understand, there is hardly anything out there in mailing 
lists that is relevant to my needs.  I made some good progress this 
weekend but in trying to make nicer and more efficient code, somehow I 
managed to cause a lot more kernel crashes...so I ended up going back to 
what I had a couple days ago (I still made a few modifications tonight).

What I have left to do:
-fix really baffling bug (will describe in class)
-get reading from the device (/dev/sebek) to work flawlessly
-be able to determine the tty id of the process that is calling the read 
that BSDsebek hijacks
-add in some error checking
-combine with adorebsd for file/process/module hiding (should be 
basically cut & paste)
-port helper application (already started by Ed and since its 
user-space, should be real quick)
-TEST / DOCUMENT (yay and oh no!)

On a side note concerning the covert stuff, I know in linux that inode 0 
is reserved for bad blocks, so data can be "hidden" there.  Perhaps 
FreeBSD has something similar.  Also, I have used programs that hide 
data in the slack space of file blocks and then later extract it.  This 
is all feasable.  Unfortunately, in order to perform quality logging, 
not only does all the ssh traffic have to be captured, it also has to be 
timestamped and contain the user id, process name, pid, etc.

Anyways, I guess that's about it for tonight.  See you guys in class.

Ben

-- 
Benjamin Johnson <bsjohnso at midway.uchicago.edu>
"I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein