SAdoor step-by-step
By CMN <cmn@darklab.org> 2003-08-28

Daemon 

1.1 - Install the daemon package

    # cd SAdoor-daemon-1.0/daemon/
    # make <systype>
    # make install

    The following files are then installed:
    /etc/sadoor/sadoor.conf
    /etc/sadoor/sadoor.pkts
    /usr/sbin/sadoor
    /usr/bin/mksadb
    /usr/share/man/man5/sadoor.conf.5
    /usr/share/man/man5/sadoor.key.5
    /usr/share/man/man5/sadoor.pkts.5
    /usr/share/man/man8/mksadb.8
    /usr/share/man/man8/sadoor.8

    You can change the locations by editing the Makefile
    (SAdoor-daemon-1.0/daemon/Makefile), and remove them by
    running 'make uninstall'.

    Note that the path's do not match in the manuals if you change
    the install locations since I ignore to run them over by sed(1) 
    before installing them. I will fix this in the next release.


1.2 - Create the key file

    The first thing to do after installation is to create the
    448 bit Blowfish key that the client(s) will use when encrypting
    the commands sent to the daemon.

    The default location of the key is in /etc/sadoor/sadoor.key, 
    and the simplest way to create it is to use dd(1) and read from
    a random device, like:
    
    dd if=/dev/srandom of=/etc/sadoor/sadoor.key bs=56 count=1

    Use /dev/random if you lack /dev/srandom (do not run OpenBSD).
    If you do not have a random device at all (run Solaris ?), you 
    have to come up with something random and edit the file by hand, 
    or perhaps use perl like:

    perl -e 'print "\xaf\xbf...\xff"' > /etc/sadoor/sadoor.key.

1.3 - Configure the daemon

    When the key is generated, you should start configuring
    the daemon himself.
    The main configuration file is /etc/sadoor/sadoor.conf
    by default, but could be changed on the command line
    with the -c option.

    There is alot of options and tuning that can be done
    in this file, we will stick to the most basic configuration
    for now (sadoor.conf(5) describes them all).

    1.3.1 - ListenIface

    This option let's you specify which network interface that
    sadoor(8) should listen for packets on, lets pick 'ne3':
    
    ListenIface ne3

    1.3.2 - IPv4address

    The IPv4 address set on the interface choosen above
    (ListenIface option). This is the adress used when
    a connection is established with a client, but it
    also works as a key in the client's host-database.

    If you already have read the manuals, and wonder what to do 
    if you plan to run sadoor(8) on an interface without a 
    IPv4 address (like an IDS sensor or a bridge), then answer 
    is that you can use whatever address you like, as long as 
    all hosts in the client's database has different addresses.

    Lets say that our interface has the address 192.168.1.4
    (or perhaps 127.0.0.1 to test the configuration locally):

    IPv4address 192.168.1.4

    1.3.3 - PrivateLogVerboseLevel

    Decide how verbose your private log messages will be.
    These logs is written to /etc/sadoor/sadoor.log by
    default and contains information about received key
    packets among other things. It's a good choise to
    set this to it's maximum value as a start:

    PrivateLogVerboseLevel 3

    1.3.4 - SyslogVerboseLevel

    Decide how verbose the syslog should be. 
    Set this to the highest possible value to be able to
    watch connections establish when testing sadoor.

    SyslogVerboseLevel 3

    1.3.5 - RunPromisc

    Should sadoor listen for packets in promiscous mode or not?
    Well, it all depends on how you plan to configure the packets
    later on, we keep it simple for now and set this to no.

    RunPromisc no

    1.3.6 - PacketsTimeoutSec

    To avoid sadoor(8) to trigger on "false" packets, we can set a 
    timeout wich will make sadoor start all over again when it is 
    reached (this does really not matter here since we need the 
    key anyway, but it is important if the NULLCommand option is 
    used). Lets set it to 60 seconds:
    
    PacketsTimeoutSec 60

    1.3.7 - Minimum configuration done

    The configuration is done and our file looks like this:

    -- Begin /etc/sadoor/sadoor.conf

    ListenIface ne3
    IPv4address 192.168.1.4
    PrivateLogVerboseLevel 3
    SyslogVerboseLevel 3
    RunPromisc no
    PacketsTimeoutSec 60
    
    -- End /etc/sadoor/sadoor.conf

    It's time to hit the packet configuration.

1.4 - Configure the key and command packets

    The packet configuration is what it's all about, we keep it 
    simple here to get things running, but this is the thing to 
    focus upon to achieve real stelth.

    The packets is defined in the file /etc/sadoor/sadoor.pkts.
    The syntax is described in sadoor.pkts(5), so I won't go any 
    deeper into that here, but focus upon a simple example
    configuration instead.

    We start by defining the key packets, the packets to send
    before the actual command packet is sent. These packets must
    arrive in the defined order, and is sort of a "secret knock".

    The command packet is described in the same way, but it contains
    a command for sadoor (or it does not contain any command, and 
    theirfore runs the predefined NULLCommand if that is set).

    To keep things simple, lets say that we await these three
    key packets before the command packet.

    o Keypacket 1
    ICMP echo request to 192.168.1.4 from 192.168.1.1

    o Keypacket 2
    TCP SYN to 192.168.1.4 port 80 with source address 192.168.1.1 
    and source port 3456.

    o Keypacket 3
    UDP packet to 192.168.1.4 port 7898 from 192.168.1.1, containing 
    the string "Hello SAdoor" in the payload.

    Now it's time to decide what the command packet should look like.
    (the sadoor command will be placed encrypted right after any data in the 
    payload, but since this command packet has no data set, the only data
    will be the actual command).

    o Command packet
    TCP SYN to 192.168.1.4 port 22 from 192.168.1.1 with source port 12345.

    The packet configuration then looks like this:

    -- Begin /etc/sadoor/sadoor.pkts
    
    # Key packet 1
    keypkt
    {
        ip {
            daddr = 192.168.1.4;
            saddr = 192.168.1.1;
            icmp {
                type = 8;
            }
        }
    }
    
    # Key packet 2
    keypkt
    {
        ip {
            daddr = 192.168.1.4;
            saddr = 192.168.1.1;
            tcp {
                flags = SYN;
                dport = 80;
                sport = 3456;
            }
        }
    }
    
    # Key packet 3
    keypkt
    {
        ip {
            daddr = 192.168.1.4;
            saddr = 192.168.1.1;
            udp {
                dport = 7898;
                data { Hello\x20Sadoor }
            }
        }
    }
   
    # Command packet 
    cmdpkt
    {
        ip {
            daddr = 192.168.1.4;
            saddr = 192.168.1.1;
            tcp {
                dport = 22;
                sport = 12345;
            }
        }
    }

    -- End /etc/sadoor/sadoor.pkts

1.5 - Generate an image for the client to use

    In order to make the packet-sending process as transparant 
    as possible, there is a client program to take care of everything.
    
    /*
     * Everything depends on the configuration. If you do this wisely,
     * you can generate the required packets from real connections 
     * without the need of a client, or a raw socket too for that matter.
     *
     * Most implementation of ping(8) allows data to be set as well, 
     * and you can use the client only for generation of the required 
     * command packet payloads to feed into for example hping(8) or 
     * simply set the NULLCommand in sadoor.conf to a command to run when 
     * the command packet does not contain any command.
     */

     The client needs to know what packets to send, the key to use when 
     encrypting the command etc. So we need to generate an image out of 
     the configuration. This is done by simply running mksadb(8).

     By default, mksadb(8) generates an image (or call it an entry to 
     the clients database) to the file /etc/sadoor/sadoor.db.
     
     # mksadb
     # ls /etc/sadoor
     sadoor.conf sadoor.db   sadoor.key  sadoor.pkts
     #

    Since sadoor.db is unencrypted, you should make sure that it is
    transfered in a secure channel and then erase it (preferable using
    srm(1)) Or perhaps use the client program sadbcat(1) to create an 
    encrypted database ready to feed into the client before transfering it.

1.6 - Run the daemon

    The configuration is done (simple but a working example), and it is time
    to start sadoor(8). Make sure that you are root and run /usr/sbin/sadoor.

    You will now see something like:
    
    "Aug 27 22:50:09 lappy sadoor[10636]: Listening on ne3"
    
    in the logfile for the facility 'daemon' with priority 'info', as well as
    in the private log file /etc/sadoor/sadoor.log (yes, some log entries is
    duplicated to the private log file).
    SAdoor is now up and running, hungry for packets.


2.0 - Client 

    2.1 - Install the client programs
    
    NOTE: I aparently failed badly to name the 
    client in a good way since sash also exist as 
    "stand alone shell", sorry for that ...

    # cd SAdoor-client-1.0/client/
    # make <systype>
    # make install

    The following files is then installed:
    /usr/bin/sash
    /usr/bin/sadump
    /usr/bin/sadbcat
    /usr/share/man/man1/sadbcat.1
    /usr/share/man/man1/sadump.1
    /usr/share/man/man1/sash.1
    /usr/share/man/man5/sash.conf.5

    And you can run 'make uninstall' to remove them, or
    edit SAdoor-client-1.0/client/Makefile to change the
    destination.

2.2 - Creating the sadoor database

    The first thing to do is to create the encrypted database 
    which will hold the information about what packets to send
    and the key to use when sending commands to the machine at
    192.168.1.4 as we configured above.

    This is as simple as running sadbcat(1) and enter a password,
    but we first create the directory that the client (sash(1))
    will look for the default database in:
    
    # mkdir ~/.sash

    Then we create the database using the sadoor.db file that we
    got when configuring sadoor at 192.168.1.4:

    # sadbcat sadoor.db ~/.sash/sash.db
    /root/.sash/sash.db does not exist, create? [y/n]: y
    Passphrase for '/root/.sash/sash.db':
    Retype passphrase:
    #

2.4 - Sending commands

    When the database contains our target host we are ready to use 
    sash(1) to run arbitrary commands without the need of establishing 
    a connection.
    We use the -r option for that (and add some verbosity with -v
    option to see what is going on):

    # sash 192.168.1.4 -vv -r 'ls -al /etc/sadoor > /tmp/list'
    Resolved local IP as 192.168.1.1
    Attempting to read entry for 192.168.1.4 from /root/.sash/sash.db
    Passphrase for '/root/.sash/sash.db': 
    Sending packets for 192.168.1.4 (lappy)
    Sending key packet 1: (ICMP) 192.168.1.1 (superbox) -> 192.168.1.4 (lappy)
    Sending key packet 2: (TCP) 192.168.1.1:3456 (superbox) -> 192.168.1.4:80 (lappy)
    Sending key packet 3: (UDP) 192.168.1.1:14621 (superbox) -> 192.168.1.4:7898 (lappy)
    Sending command packet: (TCP) 192.168.1.1:12345 (superbox) -> 192.168.1.4:22 (lappy)
    #

2.3 - Establish a connection
    
    2.3.1 Wait for a connection

    By default, sash(1) sends a CONNECT command to target sadoor, 
    so we simply type the IP as an argumet and let sash(1) do the rest:

    # sash 192.168.1.4 -vv
    Resolved local IP as 192.168.1.1
    Attempting to read entry for 192.168.1.4 from /root/.sash/sash.db
    Passphrase for '/root/.sash/sash.db': 
    Sending packets for 192.168.1.4 (lappy)
    Sending key packet 1: (ICMP) 192.168.1.1 (superbox) -> 192.168.1.4 (lappy)
    Sending key packet 2: (TCP) 192.168.1.1:3456 (superbox) -> 192.168.1.4:80 (lappy)
    Sending key packet 3: (UDP) 192.168.1.1:15721 (superbox) -> 192.168.1.4:7898 (lappy)
    Awaiting connection from SAdoor to 192.168.1.1:65360
    Sending command packet: (TCP) 192.168.1.1:12345 (superbox) -> 192.168.1.4:22 (lappy)
    192.168.1.4:1053 (lappy) connected.
    Received session key
    Sending window size
    sh-2.05b# cat /tmp/list 
    drwx------    2 root     root         4096 Aug 28 00:16 .
    drwxr-xr-x   72 root     root         4096 Aug 27 23:45 ..
    -rw-------    1 root     root          676 Aug 27 23:46 sadoor.conf
    -rw-------    1 root     root          340 Aug 27 23:46 sadoor.db
    -r--------    1 root     root           56 Aug 27 18:05 sadoor.key
    -rw-------    1 root     root          505 Aug 28 00:17 sadoor.log
    -rw-------    1 root     root          732 Aug 27 23:46 sadoor.pkts
    sh-2.05b# 
    

    2.3.2 Connect to sadoor

    In case we are behind a firewall sadoor(8) cannot connect back to us,
    so we send the ACCEPT command instead, telling target sadoor to listen on
    a port for us to connect to (the command sent also contains the address of
    our socket (ip:port) that we will use for the connection).

    Since we do not know anything about what ports are available on the remote
    machine, we simply try one:

    # sash 192.168.1.4 -p 31337 -vv
    Resolved local IP as 192.168.1.1
    Attempting to read entry for 192.168.1.4 from /root/.sash/sash.db
    Passphrase for '/root/.sash/sash.db': 
    Sending packets for 192.168.1.4 (lappy)
    Sending key packet 1: (ICMP) 192.168.1.1 (superbox) -> 192.168.1.4 (lappy)
    Sending key packet 2: (TCP) 192.168.1.1:3456 (superbox) -> 192.168.1.4:80 (lappy)
    Sending key packet 3: (UDP) 192.168.1.1:8054 (superbox) -> 192.168.1.4:7898 (lappy)
    Sending command packet: (TCP) 192.168.1.1:12345 (superbox) -> 192.168.1.4:22 (lappy)
    Trying 192.168.1.4:31337 from local address 192.168.1.1:65357
    Connection established
    Received session key
    Sending window size
    sh-2.05b# 


2.4 - Configuring the client

    Lets say that you make use of the TTL field in the IP header when
    configuring the sadoor-packets to limit the radius of computers 
    that is able to generate valid packets.

    In this case you manually have to tell sash how many hops away you 
    are from sadoor (so that sash can add it to the expected value to 
    compensate for reduction in transit) by editing the configuration 
    file, which is ~/.sash/sash.conf by default.

    -- Begin ~/.sash/sash.conf
    
    # We are 10 hops away from 10.0.0.1
    10.0.0.1
    {
        addtottl = 10;
    }

    -- End ~/.sash/sash.conf

    To get ride of the annoying warning message displayed if TTL
    is set to it's max value (255) (forcing packets to be generated
    on the same segment as sadoor), and we are 0 hops away, simply 
    set addtottl to zero.
    
    You can also change the default values on unused fields, as well
    as using different databases for different hosts.
    All the options is explained (with examples) in sash.conf(5).


    That's all folks!
