Advisory

"the-binary" a distributed denial of service attack agent

May 27, 2002

Introduction

The following is an analysis of "the-binary", a distributed denial of service attack tool, based on a reverse engineering analysis of binary code discovered on a compromised system belonging to the Honeynet project.

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.

Communication

Handler to Agent: NVP-II, packet[0] == 2
Agent to Handler: NVP-II, packet[0] == 3

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 byte

Decoding is simply the revers of this process. A simple decoder is provided (libpcap required).

Commands

Twelve commands are understood by the-binary. Once decoded, the fourth byte in a command packet specifies which of the 12 commands to execute. Some commands require parameters, and these follow in bytes five and on.

The twelve commands, their purpose, and links to additional information are detailed below

Command 1 - report agent status.
Command 2 - Configure handler list
Command 3 - Execute command and return results.
Command 4 - Execute a DNS response flood.
Command 5 - Execute a UDP or ICMP flood.
Command 6 - Open a root shell listener on port 23281.
Command 7 - Execute command, do not return results.
Command 8 - Terminate the active service.
Command 9 - Execute a DNS response flood.
Command 10 - Execute a TCP SYN flood.
Command 11 - Execute a TCP SYN flood.
Command 12 - Execute a DNS request flood.

Fingerprints

Methods used for installation of the-binary will likely be the same as those used for installing any software on compromised Unix system.
Standard methods include but are not limited to the use of hidden directories, root kits, and kernel modules.

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[0] 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

Another unique feature of the-binary is a static list of 11444 DNS servers used in one of its attacks. Any 8 byte sequence chosen from that list is likely to be rather unique. There are also 9 canned DNS queries contained in the-binary. Four of the nine are malformed. Any one of these four queries is probably somewhat unique as well.

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 > 109.197.191.34:  nvp 480
172.16.183.2 > 126.85.250.183:  nvp 480
172.16.183.2 > 233.96.38.22:  nvp 480
172.16.183.2 > 210.13.117.98:  nvp 480
172.16.183.2 > 219.93.216.82:  nvp 480
172.16.183.2 > p35-tnt7.syd.ihug.com.au:  nvp 480
172.16.183.2 > 41.230.157.197:  nvp 480
172.16.183.2 > 20.17.169.129:  nvp 480
172.16.183.2 > 214.104.164.84:  nvp 480
172.16.183.2 > 109.197.191.34:  nvp 583
172.16.183.2 > 126.85.250.183:  nvp 583
172.16.183.2 > 233.96.38.22:  nvp 583
172.16.183.2 > 210.13.117.98:  nvp 583
172.16.183.2 > 219.93.216.82:  nvp 583
172.16.183.2 > p35-tnt7.syd.ihug.com.au:  nvp 583
172.16.183.2 > 41.230.157.197:  nvp 583
172.16.183.2 > 20.17.169.129:  nvp 583
172.16.183.2 > 214.104.164.84:  nvp 583

the-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

With ps the-binary looks like this

# 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]

We further investigate process 11299 because it matches the name [mingetty]

# ps -e | grep 11299
11299 ? 00:00:00 the-binary

Defenses

This program uses a rather obscure (?) protocol, nvp, for communications between handler and agent. This protocol along with every other unused protocol should be blocked. Blocking TCP access to all but non-essential ports should prevent the use of the root shell feature of 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.

Weaknesses

If the source has not been modified, you can identify the-binary by the embedded strings shown earlier.

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.

Future Developments

Advances to this tool would include command authentication as well as improved encryption of command/result data. As these capabilities are already present in existing DoS tools such as stacheldraht and TFN, it is not a huge leap to expect to see them appear in derivative works of the-binary.

References

The DoS Project's "trinoo" distributed denial of service attack tool
http://staff.washington.edu/dittrich/misc/trinoo.analysis.txt

The "Tribe Flood Network" distributed denial of service attack tool
http://staff.washington.edu/dittrich/misc/tfn.analysis.txt

The "stacheldraht" distributed denial of service attack tool
http://staff.washington.edu/dittrich/misc/stacheldraht.analysis.txt

CERT Distributed System Intruder Tools Workshop report
http://www.cert.org/reports/dsit_workshop.pdf

CERT Advisory CA-99-17 Denial-of-Service Tools
http://www.cert.org/advisories/CA-99-17-denial-of-service-tools.html

tcpdump:
http://www.tcpdump.org