the-binary is an agent component of a distributed denial of service
attack network. While it conatins the capability to perform a variety
of types of denial of service, it is not nearly as sophisticated as previous tools in the same family such as Stacheldraht or Tribal Flood
Network (TFN). The only new feature it seems to add is a novel means of agent/handler communications via a seldom used IP protocol, Network Voice Protocol II (NVP-II). The protocol itself is not actually adhered to, instead it is specified by setting the IP protocol byte to 11. Poorly configured firewalls may fail to filter this protocol, providing a clear communications channel for agent/handler traffic.
the-binary has the capability to provide an on-demand root shell bound to a TCP port, much like TFN, and it provides an encoding mechanism for agent/handler communications. the-binary fails however to perform any authentication on handler commands and as a result can be easily instructed to reveal itself, subverted, and/or shutdown.
Placement of the-binary on a system would be an attackers last step
in construction of a DDoS network. It is likely that an attacker would
seek to compromise hundreds if not thousands of computers in order to amplify the effect of a DoS launched with this particular agent. As
the-binary requires root privelages in order to execute, one should assume that any computer on which it is found has been completely
compromised. the-binary appears to contain no features that allow it to compromise a system on its own.
Without client or handler code to accompany the-binary, we must speculate that a typical DoS network in which the-binary participates looks as follows:
An attacker controls one or more handlers which in turn control many the-binary agents. On command from a handler, the-binary would initiate any one of 5 types of denial of service.
By avoiding the use of TCP, UDP, or ICMP, the-binary may communicate through poorly configured firewalls.
Commands from the handler to the-binary are not authenticated in any way. the-binary accepts a packet as a valid command if it's first byte is 2 and the overall size of the packet, including the IP header is larger than 200 bytes. The longest command a handler sends uses only only the first 45 bytes of the command packet. Commands are never acknowledged, though two commands cause the agent to send responses back to the handler. All commands/responses between the handler and the-binary are encoded using a simple additive encoding algorithm explained below. The first two bytes of any command/response packet are unencoded, all subsequent bytes are encoded.
Data encoding is used in all command and response packets. With the exception of the first two bytes of each packet, all remaining packets are encoded according to the following algorithm
if this is the first byte to be encoded add 23 to this byte else add 23 plus the previous byte to this byteDecoding is simply the revers of this process. A simple decoder is provided (libpcap required).
The twelve commands, their purpose, and links to additional information are detailed below
Unlike Stacheldraht et al., the-binary does not make use of text based
and therefore does not have a very unique string based signature. A few
possibly unique strings are:
nvp-II --the IP protocol used
TfOjG --the upshifted password for a root shell
[mingetty] --substituted argv for forked child processes
The bulk of the strings content are C library strings as the-binary appears to be statically linked with a minimal subset of the C library.
The entire output of 'strings' can be seen here: the-binaryStrings.txt
When the agent starts, it makes no attempt to initialize its handler list and consequently no attempts are made to contact any handlers. This means that there is no handler configuration file required or present, and that the-binary emits no network traffic on startup. It goes directly into receive mode. the-binary will only communicate with a handler on demand.
tcpdump output shows clearly the use of the nvp protocol:
172.16.196.132 > 172.16.183.2: nvp 402 172.16.196.132 > 172.16.183.2: nvp 402 172.16.196.132 > 172.16.183.2: nvp 402 172.16.196.132 > 172.16.183.2: nvp 402 172.16.183.2 > 220.127.116.11: nvp 480 172.16.183.2 > 18.104.22.168: nvp 480 172.16.183.2 > 22.214.171.124: nvp 480 172.16.183.2 > 126.96.36.199: nvp 480 172.16.183.2 > 188.8.131.52: nvp 480 172.16.183.2 > p35-tnt7.syd.ihug.com.au: nvp 480 172.16.183.2 > 184.108.40.206: nvp 480 172.16.183.2 > 220.127.116.11: nvp 480 172.16.183.2 > 18.104.22.168: nvp 480 172.16.183.2 > 22.214.171.124: nvp 583 172.16.183.2 > 126.96.36.199: nvp 583 172.16.183.2 > 188.8.131.52: nvp 583 172.16.183.2 > 184.108.40.206: nvp 583 172.16.183.2 > 220.127.116.11: nvp 583 172.16.183.2 > p35-tnt7.syd.ihug.com.au: nvp 583 172.16.183.2 > 18.104.22.168: nvp 583 172.16.183.2 > 22.214.171.124: nvp 583 172.16.183.2 > 126.96.36.199: nvp 583the-binary is seen on the system with "lsof" like this:
# lsof | grep raw the-binar 11299 root 0u raw 244837 00000000:000B->00000000:0000 st=07 # lsof -p 11299 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME the-binar 11299 root cwd DIR 3,6 4096 2 / the-binar 11299 root rtd DIR 3,6 4096 2 / the-binar 11299 root txt REG 3,6 205108 257470 /root/honeynet/the-binary the-binar 11299 root 0u raw 244837 00000000:000B->00000000:0000 st=07
# ps -x | grep mingetty 1071 tty1 S 0:00 /sbin/mingetty tty1 1072 tty2 S 0:00 /sbin/mingetty tty2 1073 tty3 S 0:00 /sbin/mingetty tty3 1074 tty4 S 0:00 /sbin/mingetty tty4 1075 tty5 S 0:00 /sbin/mingetty tty5 1076 tty6 S 0:00 /sbin/mingetty tty6 11299 ? S 0:00 [mingetty]
# ps -e | grep 11299 11299 ? 00:00:00 the-binary
The best defense involves keeping all systems up to date with the latest security patches in order to minimize your vulnerability profile. Unnecessary services should be disabled and system administrators should be trained in the proper administration and monitoring of all systems under their supervision.
Any use of the nvp protocol is a good trigger as well.
Handler commands to the-binary are unauthenticated. It is a simple matter to scan a network for active instances of the-binary (see scanner.c) Once found an agent can be terminated with killer.c. Scanner.c first sends a handler list configuration command to a host, then requests the same host's status with a status request. A reply indicates an active agent.
The "Tribe Flood Network" distributed denial of service attack tool
The "stacheldraht" distributed denial of service attack tool
CERT Distributed System Intruder Tools Workshop report
CERT Advisory CA-99-17 Denial-of-Service Tools