rrs(1)

NAME
rrs - Reverse Remote Shell
Copyright (C) 2004 Michel Blomgren <michel@cycom.se>
http://www.cycom.se/dl/rrs

SYNOPSIS
connect (serve shell to peer):
rrs [options] hostname [port]

listen (receive shell from peer):
rrs -l [options] [-p port]

DESCRIPTION
rrs is a reverse (connecting) remote shell. Instead of listening for incoming connections it will connect out to a listener (rrs in listen mode). The listener will accept the connection and receive a shell from the remote host. rrs features full pseudo-tty support, full OpenSSL support (high encryption, client/server authentication, choice of cipher suites), Twofish encryption, a simple XOR cipher, plain-text (unencrypted) session, peer-side session monitoring (snooping), daemon option and reconnection features. rrs is Free Software distributed under the MIT License and is known to compile and run under Linux, FreeBSD, NetBSD, OpenBSD and QNX.

OPTIONS

-h, --help
    Display help (you can execute rrs without arguments too).

-l, --listen
    Listen for incoming rrs connection, default port is 31337, change with -p.

-p, --port n
    For -l (listen), bind to port n instead of 31337.

-b, --source-port n
    For the connector, bind to source port n instead of letting the kernel choose a source port. Good if you bump into some strange fw config that only allows specific tcp source/dest port pairs through (then use -b and laugh at their lousy sec).

-r, --reconnect n
    Reconnect until we've got a connection, pause for n seconds between connection attempts. --timeout is relevant here, since it'll control how long connect() may take until timing out. The kernel max connect() timeout can never be increased though.

-R, --infinite-reconnect n
    Same as --reconnect, except it won't exit after a successful connection has been terminated. It will loop continuously, until killed.

-t, --timeout n
    Timeout in seconds, for both -l and connect().

-D, --daemon
    Tell the connector to fork into a background process before attempting to connect. --daemon automatically enables --quiet.

-k, --twofishkey phrase
    Tell rrs to use the built-in Twofish encryption for communication. This implementation isn't very efficient, something you will experience when typing, but not when receiving/sending a steady stream. phrase is either a password or phrase that you specify on the command line, or if you specify "-k-" rrs will read one from stdin. IMPORTANT! With a symmetric cipher both the listener and the connector has to use the same pass phrase in order to communicate. If you use the -k option, you can not use -s (OpenSSL) or -x (xorcrypt).

-x, --xorkey phrase
    Tell rrs to use the built-in per-byte XOR (very simple symmetric) encryption for communication. This cipher is quite weak and should not be considered decent encryption. It's useful for effectively evading a NIDS and general interception. As with -k above, phrase is either a password that you specify on the command line or from stdin using "-x-". Since this XOR cipher loops the key for the data received/transmitted, the engine will be initialized with a 144 byte ascii hash (SHA1+MD5+SHA1+MD5). The hash is generated by calculating a SHA1+MD5 hash of the phrase, then the phrase is reversed and hashed again (SHA1+MD5) to form the entire key.

-s, --ssl
    OpenSSL encrypted communication instead of plain text. rrs will use the TLSv1 protocol method by default, you can change it with, e.g., --ssl=tlsv1 for instance, or the -S option.

-S, --ssl=method
    Choose OpenSSL protocol (case doesn't matter):
        -S SSLv2
        -S SSLv3
        -S TLSv1
    If you use --ssl instead of -S, please remember to use the equal sign, e.g., --ssl=sslv3.

-P, --pem file
    Specify private key and certificate (public key) file. The file should begin with a PEM encoded private key followed by a PEM encoded certificate. Both the listener and the connector must provide a private key and certificate since authentication of the listener is the default behavior. If you specify -v0 on both sides, only the listener (-l) needs a PEM file, not the connector. The PEM file can contain several certificates after each other that you trust. Whoever has got the private key to those certificates will be allowed to receive the connection by the connector (in default -v1 mode). As a security precaution, the receiver (listener) verifies the connector's certificate by default, thus, both the listener and the connector must exchange their public keys (certificates), or trust a common CA (self-signed certificate) who's signed each party's certificate.

-C, --ca file
    Optional. If you want to specify additional certificates you trust, just append them to file, one certificate after the other. By default, the certificate(s) in the -P (--pem) file is/are trusted. You may also use the -C option to add CRL (Certificate Revocation List) files (only supported in OpenSSL 0.9.7 or later). The -C (--ca or --crl) can be specified several times on the command line to include an arbitrary amount of certificate files and/or CRL files, e.g.: -C ca.crt -C subca.crt -C subca.crl. If no CRL file is added, no CRL checking is done.

--crl file
    Same as above. Option added for logical reasons.

-c, --cipher cipher
    Define permitted SSL ciphers in a colon delimited list, for example:
        --cipher AES256-SHA:AES128-SHA
        --cipher HIGH
        --cipher HIGH:MEDIUM
        --cipher "DES-CBC3-SHA"
    DO NOT USE EXPORT OR NULL CIPHERS SUCH AS "EXPORT40", "NULL", "aNULL" or "EXPORT". Type "openssl ciphers" or "openssl ciphers HIGH" for a list of your OpenSSL suite's ciphers.

-v, --verify n
    Verify peer SSL certificate (authentication), this is on by default. Replace n with:
        0 = no verification/authentication
        1 = verify both listener and connector (default)
    Both the connector (the shell provider) and the listener trust the certificate(s) in the --pem file and in the --ca file (if --ca file was provided).

-e, --exec command
    Have the listener execute command on remote host. Please note that after the command line has been executed, it won't exit the shell (like ssh, e.g.). You'll manually have to add " ; exit" to your command to log out.

-m, --monitor
    Connector only. When serving a shell, echo/monitor everything that the listener is doing. You can record the session with a program called ttyrec found at http://namazu.org/~satoru/ttyrec/.

-0, --setuid
    With this option, rrs will try to setuid(geteuid()) if current UID and the effective UID isn't the same (if rrs is chmodded 4755 and chowned root, e.g.). The primary purpose of this option is to offer a root shell from a regular account or if you want to receive connections to privileged ports (<1024). You must chmod rrs 4755 or 6755 and chown it to root if you plan to offer root shells. The security issues involved with chmodding rrs 4755 are quite obvious! ;)

-q, --quiet
    Be quiet, don't print anything.

-L, --license
    Print the MIT License and exit.

-V, --version
    Print program banner, copyright and RCS id then exit.

EXAMPLES
Generate an OpenSSL private/public key file like this, e.g.:

$ openssl req -new -x509 -nodes -out rrs.crt -keyout rrs.pem -days 3650
$ cat rrs.crt >> rrs.pem
$ cat rrs.crt | mail -s "My certificate" other@side.tld

-nodes means not to encrypt the private key, you can remove it, either way, make sure you keep the private key private! The example above is PKC (public-key cryptography).

PKI example (first, create a CA):

$ openssl genrsa -aes256 -out ca.key 4096
$ openssl req -new -key ca.key -out ca.csr
$ openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt

Then, create a cert and sign it with the CA's key:

$ openssl genrsa -out rrs.key 4096
$ openssl req -new -key rrs.key -out rrs.csr
$ openssl x509 -req -days 3650 -CA ca.crt -CAkey ca.key \
  -CAcreateserial -in rrs.csr -out rrs.crt
$ cat rrs.key rrs.crt > rrs.pem
$ rrs -s -P rrs.pem -C ca.crt host 1234

The CA's certificate (ca.crt) is shared (just like Verisign's cert, e.g.). Ask your other side to generate a key and certificate signing request (CSR) as described above. The other side should only send his/her .csr file nothing else. You sign the request with the CA's key (described above) to generate a valid certificate (.crt) and sends it to the other side (along with the ca.crt for instance).

fubar wants to give snafu a root shell, fubar executes the following:
fubar# rrs -s -r5 -t5 --pem fubar.pem --ca ca.crt snafu.dom.tld 1234

snafu executes the following:
snafu$ rrs -ls -p1234 --pem snafu.pem --ca ca.crt

LICENSE
rrs - Reverse Remote Shell
Copyright (C) 2004 Michel Blomgren <michel@cycom.se>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Twofish implementation Copyright (c) 1995-2001 The Cryptix Foundation Limited. Twofish API (farm9crypt) by jojo@farm9.com. Twofish encryption was derived from cryptcat.

Independent implementation of MD5 (RFC 1321) Copyright (C) 1999, 2000, 2002 Aladdin Enterprises.

The SHA1 implementation is Copyright (C) 2000 by Peter Selinger and is distributed under the GNU General Public License (GPL).

AUTHOR
My name is Michel Blomgren. I'm an information security consultant specializing in risk/vulnerability assessment and penetration testing with Cycom AB, www.cycom.se. I'm the developer of SENTINIX, a GNU/Linux distribution designed for monitoring, intrusion detection, anti-spam, anti-virus and clustering. You may contact me by sending an e-mail to <michel@cycom.se>. If you like to keep the conversation private, fetch my PGP public key on http://www.cycom.se/misc/pubkeymichel.asc (886A 7B17 1747 6C82 7A7E EAC0 A3F1 2943 101C 18FA).

SEE ALSO
gwee(1) openssl(1) genrsa(1) req(1) x509(1) ca(1) crl(1)