$Header: /cvsroot/sid/sid/docs/README,v 1.7 2005/01/08 19:37:48 deppeler Exp $

Abstract

Pseudo Termincal Intrusion Detection: aims at detecting unwanted shell
activity on UNIX systems (spawned on pseudo terminals).  Consists of a
kernel part and a user part. The kernel part plugs into the terminal
processing subsystem and logs hashed terminal lines. The user part
reads log entries (hashes), consults a list of allowed entries, and
takes appropriate action upon unexpected log entries.


Content:
1) Purpose
2) Solaris Theory of Operation
3) Linux 2.4 Theory of Operation
3a) Linux 2.6 Theory of Operation
4) Design and Implementation
5) Example
6) References

1) Purpose:

The pSeudo terminal Intrusion Detection system (SID) fits within the
'burglar alarm' type of host-based intrustion detection software. It aims
at automatically detecting unexpected shell activity.  For any pseudo
terminal opened, SID logs the activity (characters typed). Unexpected
terminal activity may trigger an action (raise an alert and execute
some program).

SID is probably best deployed on exposed servers with few or no
interactive user accounts (besides administrative accounts) and
well-known maintenance time and activity. As the frameworks only detects
activity within pseudo terminals, it probably does not offer protection
against automated intruder tools that don't launch interactive terminal
shells. SID's purpose is to take notice of and react to 'custom' attacks
where the intruder further explores a successfully compromised system
by making use of an interactive (pseudo terminal) shell session.

SID offers a way to turn off the surveillance of certain pseudo terminal
sessions in order for the system administrator to be able to do her work.


2) Solaris Theory of Operation:

SID consists of two main parts: a kernel part that logs hashed
keystrokes, and a user part that parses the logfile for the occurence
of such hashed lines. The theory of operation for the Solaris
implementation can be depicted as follows:

  ------------
  | terminal |
S |  driver  |           -------------------------------------           |
T |    .     |           |kernel STREAMS module:             |           |
R |   SID    |---------->|assemble typed characters into line|  kernel part
E |    .     |           |generate hash of line              |           |
A |    .     |           |log                                |           |
M |streamhead|           -------------------------------------           |
  ------------             |                                             |
  (/dev/pts/n)             v                                            ---
       ^                 syslog  ------------> /var/adm/messages         |
       |                   |                      ^               user part
   -----------------       |                      |                      |
   |user process:  |       v           ------------------------------    |
   |e.g. user login|      loghost  <---| logfile watcher (user proc)|
   |session        |                   | process matched lines      |
   -----------------                   | take action upon match     |
                                       ------------------------------
                                                  ^
                                                  |
                                                configuration file


The kernel module is platform dependent. For STREAMS based pseudo
terminal implementations a custom kernel module copies characters that
pass through the STREAM, and assembles them until it encounters an EOL
or reaches a certain limit of copied characters. The assembled
characters are hashed and logged.

As every characted typed passes through the stream, shell escapes or
other tricks performed on the command line will also be considered for
generating the hash. It shouldn't be possible to escape the hash
signatures this way.

The user part is mainly a logfile watcher that is mostly platform
independent. Its operation depends on a configuration file. The
configuration file includes a description of what commands are expected
when (e.g. remote manual backup, etc). The configuration file also
allows for the specification of entries that deactivate the logfile
watcher for the corresponding terminal, thus enabling an unwatched
pseudo terminal - the intention is to provide the administrator with a
maintenance terminal without disrupting the surveillance of the other
terminals.

3) Linux 2.4 Theory of Operation:

[TODO]
The Linux 2.4 kernel part is based on the Linux kernel keylogger described
in Phrack (see references below).

3a) Linux 2.6 Theory of Operation:

[TODO]

4) Design and Implementation:

SID is written in C and provides a command line interface only.  The
kernel part obviously is most convenient when written in C for most
operating systems. As SID is to be deployed on exposed and usually
stripped down systems, the user part is also written in C in order to
avoid dependency on other languages' libraries.

Contrary to other terminal watcher systems, SID does not clear-text log
the user's entries in the pseudo terminal so as not to disclose any
information to the intruder that has managed to circumvent the
intrusion detection system (e.g. by having gained access to logs or
backups). In order to still identify allowed terminal entries, SHA-1 is
used to hash the entries. 

The user part may also run on a different system than the kernel part
(typically, on the loghost specified for the kernel syslog channel).
Automated intruder response may not be as straightforward as in the
case where the logfile watcher runs on the same sytem as the kernel
logger.

SID does not analyse typed lines into tokens. It synchronously reads
characters as they are typed and generates hashes thereof. The user
trying to edit the command line (before hitting enter) in order to avoid
the surveillance wil fail as the escape characters used to edit the line
are also used for creating the hash.

The administrative mode turns off log evaluation for the corresponding
pseudo terminal session (other sessions on the same host and on other
hosts are still watched and evaluated) may be entered by typing a
password. The password to enter the administrative mode *must* be
entered exactly the same way they are entered when specified at startup
of the logfile watching part.  The use of terminal control characters
(e.g. move the prompt on the terminal line or use delete and erase
control characters) will render the attempt futile (unless the password
was entered this way at startup of the logfile watcher as well).

The password(s) for individual hosts that are configured to be watched are
entered manually upon startup of the user part (the logfile watcher). The
passwords are immediately hashed and after startup, the hash comparison
is used to check whether an administrative session is opened.

5) Example:

Solaris system 'blade' has been configured via the system's 'autopush'
command to insert SID kernel part 'tsw' onto every pseudo terminal
stream that is opened. Typically produced logs look as follows:

Apr  5 15:42:03 blade tsw: [ID 769231 kern.notice] tsw: tty=10 \
        digest=4e128c33 c8a62ddf fe4e5a00 20058e55 d6bef6d7


The adminstrator on 'blade' may enter a password (that is interactively
read in and hashed at start-up of the SID user part) to enter an unwatched
terminal session for system maintenance tasks.  The corresponding
configuration file on the loghost specifies this as follows:

# <-- the configuration file starts here -->
# global options
# where are the kern.* messages logged?
logfile: "/var/adm/messages"

# how is the password for global administrative access entered?
# currently, only 'interactive' and 'sha1' is implemented.
#admin: interactive
admin: sha1 "ebfdec64 1529d4b5 9a54e18f 8b0e9730 f85939fb"

# sample host definition
host: "solaris8x86"
	# how is the password for this specific host entered?
	# currently, only 'interactive' and 'global' is implemented.
	admin: interactive 
	
	# when will the specified automated action be carried out upon
	# unexpected pty lines?
	automated_time: Mo-Th 19:00 +12h
			Fr 17:00 +2d13h

	automated_action: "/usr/sbin/ifconfig pcn0 down"

	# when an unexpected pty lines are encounted, what is logged and
	# how is it logged?
	syslog: message: "unexpected command"
		facility: "user"
		priority: "error"
		tag: "HOST_IDS"

host: "blade"
	admin: interactive

	automated_time: Fr 15:00 +2d19h
			Thursday 11:00 +4h

	automated_action: "ssh -i key blade '/usr/sbin/ifconfig eri0 down'"

	syslog: message: "Intrusion detected"
		facility: "user"
		priority: "error"
		tag: "HOST_IDS"

# <-- the configuration file ends here -->

A sample attacker who successfully compromises system 'blade' using
Solaris' 2002 telnet login vulnerability and typing 'w' leaves these
log entries on loghost 'solaris8x86':

[...]
May 29 14:35:42 blade tsw: [ID 277328 kern.notice] sid: open for
terminal device 3
May 29 14:35:57 blade tsw: [ID 362363 kern.notice] tsw: tty=3 line=0
digest=b6b8929f 0cbef989 e234e881 054941ab ec81f8e1
May 29 14:35:57 solaris8x86 HOST_IDS: [ID 476734 user.error] Intrusion
detected
May 29 14:35:57 solaris8x86 HOST_IDS: [ID 303076 user.error] automated
action executed
May 29 14:35:58 blade tsw: [ID 362363 kern.notice] tsw: tty=3 line=1
digest=de90f83b 003a0242 ce22a805 767fa823 a93d0ea4
May 29 14:35:58 solaris8x86 HOST_IDS: [ID 476734 user.error] Intrusion
detected
May 29 14:36:09 blade tsw: [ID 362363 kern.notice] tsw: tty=3 line=2
digest=aff024fe 4ab0fece 4091de04 4c58c9ae 4233383a
May 29 14:36:08 solaris8x86 HOST_IDS: [ID 476734 user.error] Intrusion
detected
May 29 14:36:10 blade tsw: [ID 896792 kern.notice] sid: close for
terminal device 3
[...]

The hashes do not match the adminitrative password given at startup
of the logfile watcher. SID's user part thus raises an alert (that is
hopefully propated towards an escalation system) and executes - since the
unexpected activity took place within a timeslot of automated response
- the specified action of e.g. shutting the Internet exposed network
interface down.


6) References

- Know Your Enemy: Revealing the Security Tools, Tactics, and Motives
of the Blackhat Community by The Honeynet Project (Editor), Honeynet
Project, Lance Spitzner (Preface), Bruce Schneier, The Honeynet Project

The idea for SID came to my mind when reading 'Know Your Enemy'.
Instead of checking what intruders type I would just be interested in
whether anything unexpected is typed in an environments where I know
exactly what to expect.

- doord: TTY-Watcher (see below) modified by K2
  Referenced by the book above, also included on the CD with the book.

Implements clear text logging of terminal activity. Includes a daemon
that automatically activates terminal surveillance within 2 seconds of
opening the terminal.

- TTY-Watcher: well, a tty watcher ...
  by Mike Neuman at http://www.engarde.com

Implements clear text logging of terminal activity. Includes a GUI and
allows for hijacking of terminal sessions.
Terminals to be watched must be manually added.

- tap:  monitor/manipulator for STREAMS-devices
  by Simon Ney neural@cs.tu-berlin.de -- simon@bbisun.uu.sub.org

Implements clear text logging of terminal activity. Allows for
hijacking of terminal sessions.
Terminals are individually and manually configured to be
watched/hijacked.

- STREAMS Programming Guide
  by SUN Microsystems at http://docs.sun.com

- Writing Device Drivers
  by SUN Microsystems at http://docs.sun.com

- rd <rd@thehackerschoice.com>, "Writing Linux Kernel Keylogger",
  Phrack 59, Article 14
  http://www.phrack.org/phrack/59/p59-0x0e.txt

Kernel based keystroke logger for Linux 2.4. Clear-text
logs pseudo-terminal keystrokes, including special and escape
characters. Includes (hardcoded) password-based facility to switch
between different logging types.

- Alessandro Rubini & Jonathan Corbet: "Linux Device Drivers", O'Reilly.

