Index of /spa

Icon  Name                    Last modified      Size  Description
[DIR] Parent Directory                             -   
[   ] AUTHORS                 12-Feb-2008 11:41  180   
[TXT] COPYING                 12-Feb-2008 11:41   18K  
[TXT] spa.conf                12-Feb-2008 11:41  1.0K  
[TXT] spa.txt                 12-Feb-2008 11:41  8.5K  
[TXT] spa_client.pl           12-Feb-2008 11:41  8.3K  
[TXT] spa_engine.pl           12-Feb-2008 11:41   19K  
[   ] spa_user.conf           12-Feb-2008 11:41   62   
[TXT] spad.c                  12-Feb-2008 11:41   21K  
[   ] sparc                   12-Feb-2008 11:41   59   

SPA: Single Packet Authentication
     MadHat <madhat@unspecific.com>
     Simple Nomad <thegnome@nmrc.org>

http://www.unspecific.com/spa/


DESCRIPTION
-----------

We needed a protocol that allowed us to tell a server that we are who we say
we are, have it work across NAT, use TCP, UDP, or ICMP as the transport
mechanism, act as an extra layer of security, and be secure itself. Oh, and
do so with a single packet. Sound crazy? It's actually very useful. We've come 
up with Single Packet Authentication (SPA). This is a protocol for a remote 
user to send in a request to a server which cannot be replayed and which 
uniquely identifies the user. The proof-of-concept code alone is worthy of a
presentation itself, but SPA is so much more. This is not port-knocking
(although SPA can easily replace port-knocking with something much more
secure).

Single Packet Authentication (SPA) is a protocol that does just what it says --
identifies the client to the server with a single packet. What you do next is 
up to you, but we came up with several scenarios. Port knocking too insecure? 
SPA to the rescue. Behind a client's NAT on a consulting gig and need to 
restart the mail server back at the main office? SPA has a plan. Reverse shell
out of your secure DMZ back to you in your hotel room? SPA commands all. Need
a new protocol to impress potential sexual partners? SPA is deeeead sexy.

HOW IT WORKS
------------

SPA is a protocol to allow for simple and secure remote control of a machine 
with no ports open to the public.  The issues we are addressing are 
detectability, ability to replay the data and flexability.

SPA focuses on a single packet.  To protect the data as well as verify the 
sender, the data is signed and encrypted with GPG or PGP.  Inside the 
GPG part of the packet there are 5 fields of data.  They are timestamp,
sequence numbers, identity, and command/control data for the application
using SPA. 

The first is the timestamp, this allows us another method to insure the packet 
is not being replayed.  

The sequence numbers allow for a sliding window of numbers that will work.  
The resaon for the sliding windows is since SPA is a single packet, there is 
no method to notify the client of successful use of a sequence number.  There 
are 3 sequence numbers used in the packet.  The previous, current and next 
seqence number.  The server keeps track of 2 secuence numbers, the current 
and next.   There has to be a match to be accepted.

The rest of the data is specific to the implimentation.  In our implimentaion 
the third item is the identity.  This allows the user to specific an IP 
address or a 0 to either ignore the field or to use the source IP of the 
paccket to be used.  This allows you to open ports on firewalls  from behind 
a NATed IP where you may not know the IP, like at a hotel.  The next set 
of items tell the server exxactly what to do.


SAMPLE IMPLIMENTATION
---------------------

SPA consists of a sniffer that looks at each packet on a server.  The sniffer 
identifies the SPA packet by looking for the GPG ID in the data portion.  
Because of the way it detects the SPA packet, the packets can be TCP, UDP or 
ICMP.  Average data size is under 450 bytes.

The sniifer passes two pieces of data to the SPA engine.  If it is a SPA 
packet, the data portion of the packet is passed with the source IP of the 
packet.  The data is then decrypted and the user is identified and verified 
by their GPG/PGP ID.   The configs for the engine contains data telling the 
engine what they are allowed to do.  The data in the encrypted packet is then 
used to verify the packet as described as above.  The last few fields are 
then used to allow a user to perform specific tasks.  The first is a port 
knock replacement.  This will allow you to open or close a port on a firewall. 
If the IP to be used is not included in the packet the sr=ource port of the 
packet is used.  The second option is a reverse shell, or "call back" VPN.   
The thrid option is to run arbitrary command.  In our setup, we have to 
specific what can be run in the user configs.

If it is a random packet, it sends the source IP and the desination 
port.  If it is a SPA packet, it passes the source IP and the SPA packet's 
data.  When the engine gets this data, it checks the timeut on the ports it
has already opened.  If the session has timed out, it closes the port.  If
it has not timed out, it updates the time of the last packet seen.



INSTALLATION OF SAMPLE CODE
---------------------------

$ tar xvzf spa-x.x.tgz
$ cd spa-x.x
$ ./configure
$ make
# make install

In a perfect world that would work...  Let's look at what you really have to do.

$ tar xvzf spa-x.x.tgz
$ cd spa-x.x
$ gcc -O3 -Wall -o spad spad.c -lpcap
$ perl -MCPAN -e'install GnuPG::Interface; install Net::RawIP'

SETUP
-----


RUNNING
-------



-SPA_CLIENT
-
At this time, the spa client does need to use root to send packets.

$ sudo ./spa_client.pl
./spa_client.pl [-p <proto>] [-i <IP>] [-S <seq>] \
                 -c <code> -s <server> <details>
  -c <code>  code to send to <server>
     'open' to open a port
     'rvsh' *TODO* reverse shell
     'exec' to execute a command
  -s <server>  server to send encrypted <code> to
  -S <seq>  sequence number to use overriding config (reset seq from admin)
  -i <IP>  to specify the IP to open a port for
     leave blank to use the IP the packet comes from (good for NAT)
  -p <proto> protocol to use for the spa packet
     tcp, udp or icmp - defaults to tcp

     <details>  with 'open' would be the port to open
               with 'exec' is the command to execute on the remote host

  Examples: 
 ./spa_client.pl -c open -i 10.0.0.5 -s spa_server.foocorp.biz 22
     will open port 22 for 10.0.0.5 on spa_server.foocorp.biz

 ./spa_client.pl -c exec -s spa_server.foocorp.biz /usr/bin/reboot
     will reboot spa_server.foocorp.biz

 To resync the spa client, have the admin generate a new sequence number, 
 and use -S to specify the sequence number on the commandline.

 ./spa_client.pl -S6534 -c open -i 10.0.0.5 -s spa_server.foocorp.biz 22
     will open port 22 for 10.0.0.5 on spa_server.foocorp.biz and use the
     Seq# 6534


  Expected GPG public key for spa@<server> in your local keyring




TODO LIST
---------

* Impliment reverse shell