Answers

Q1. Identify and explain the purpose of the binary.

The binary is a daemon program acting as a slave in a Distributed Denial of Service (DDoS) system which consist of at least a 2-tier structure. The daemon is planted and executed on a victim machine. It will then open a raw socket of IP protocol 11, and waits on the socket for commands sent to it by a master, to carry out a selected DDoS attack against a specific victim. By instructing numerous such slaves to act simultaneously and in a concerted manner, the master can achieve bandwidth amplification and cause considerable damage to the bandwidth and responsiveness of the victim, thus causing a denial of service on the victim.

Readers are urged to refer to the CERT document on "Trends in Denial of Service Attack Technology" [1] to learn about the past, present and future trends of DDoS technology.

Q2. Identify and explain the various features of the binary. What are it's capabilities?

The binary has 12 functions that can be called upon by its master. These 12 functions can be broadly categorized into 3 types: administrative functions, shell functions and DoS attack functions.

Administrative functions include:

Poll for status: The information returned consist of the tuple: 1,7, attacking child pid, attacking type ( if child pid != 0 )
The numbers 1 and 7 may be some form of version information, as it is hardcoded into the binary.
Also, payloadbuf[1] is set to 3, which probably indicates a reply packet, as opposed to payloadbuf[1] == 2 for traffic from a master to a slave.
Set reply addresses: There can be 10 possible reply addresses, and a reply may be sent to all 10 of them, but only 1 should be the real master's IP address. The rest are most possibly decoys. There are 3 possible cases:

payloadbuf[2] == 2: all the reply addresses are copied from the payload, of which one should be the true IP address of the master.
payloadbuf[2] == 0: all the reply addresses are generated randomly except the first, which is copied from the payload. This also sets a global var (ctrl_parameter) which causes all future replies to be sent to only 1 host -- the master.
payloadbuf[2] == other values: An index is generated randomly. All reply addresses are generated randomly except for the address at the particular index generated earlier. This special address is copied from the payload and should be the master's IP address.

Kill current attack or shell: Issues a kill -9 command to terminate either the current attack, or the currently listening remote shell. At any one time, one 1 of the attack functions or remote shell function can be active.

Shell functions include:

execute a command contained in payload and send back output.
execute a command contain in payload without sending back output.
spawning of listener on TCP port 23281. A remote telnet connection supplying the password "SeNiF" will cause a remote shell to be created.

DDoS attack functions include:

The daemon can carry out the following DDoS attack types:

Single packet TCP SYN attack
Multiple packet TCP SYN attack
Fragmented IP packet attack
DNS query attack
Single packet reflective DNS query attack
Multiple packet reflective DNS query attack

The source IP address can be spoofed.

The binary also features a network encoding process to hide the communications between itself and the master. See the next question.

Q3. The binary uses a network data encoding process. Identify the encoder process and develop a decoder for it.

The encoding and decoding algorithm is actually quite simple. It can be described succinctly as follows:

Encoder:

Co = Po + 0x17
Cn = Pn + Cn-1	+ 0x17,	 for n > 0
	where Cn and Pn are the n'th byte of the encoded text and plain text respectively.

Decoder:

Pn = Cn - Cn-1 - 0x17,  for	n > 0
Po = Co - 0x17
	where Cn and Pn are the n'th byte of the encoded text and plain text respectively.

Here is the encoder asm listing and its pseudo-C equivalent.
Here is the decoder asm listing and its pseudo-C equivalent.

Q4. Identify one method of detecting this network traffic using a method that is not just specific to this situation, but other ones as well.

The binary uses IP protocol 11 to communicate with its master. This is an uncommon Internet protocol. Deploying an IDS like snort [2] can easily detect this kind of anomolous network traffic, among others.

Q5. Identify and explain any techniques in the binary that protect it from being analyzed or reversed engineered.

There appears to be three main protection mechanisms:

The binary is statically linked, with symbols stripped. While this does not make disassembly impossible, it does make life more difficult. It is also more difficult to use the gdb debugger without symbols information.
The network traffic is encoded to prevent network sniffing. If the encoding algorithm is not known first, it will not be possible to analyze any network traffic to and from the binary. It will also not be possible to trigger the binary externally in order to step through its code.
The password to the remote shell is encoded, albeit trivially (just add 1 to each of the bytes of the password). At least it is not plain obvious to the naked eye from the strings command output.

Q6. Identify 2 tools in the past that have demonstrated similar functionalities.

The binary seems to sit in between the Tribes Flood Network (TFN) [3] and Stacheldraht [4] DDoS tools in terms of functionalities and features. Their architectures and control structures are similar. This binary has more attack options than TFN. It also sports network encoding, but in this regard is not as advanced as Stacheldraht which uses proper encryption instead of a home-brew encoding algorithm.

Bonus Q1. What kind of information can be derived about the person who developed this tool? For example, what is their skill level?

This DDoS daemon does not seem to have any particularly clever features. Functionality wise, it is very much a standard set. There are ample sources of sample codes that the programmer can base his code on to implement these functions. Where the programmer tried to be clever, he fell short of putting in a proper effort. For example, both the network data encoding algorithm and the remote shell password hiding scheme are trivial. He could have easily employed proper encryption, or proper password hashing, which are already becoming commonplace in today's rootkits.

At the end of the Analysis.html document, we also highlighted a bug that we uncovered that may cause plain-text to appear in the reply packets sent by the binary, even though the data is supposed to be fully encoded. This is a result of poor programme design and insufficient testing.

Therefore we consider the programmer's skill level to be at most intermediate only.

Bonus Q2. What advancements in tools with similar purposes can we expect in the future?

We see advancement in DDoS tools in the following areas:

Shift of Control Architecture from Master/Slave to Peer-to-Peer: Thus far, almost all DDoS tools follow a master/slave architecture. This is an "old-school" networking model. The new networking trend is towards peer-to-peer computing. DDoS architecture may well follow this trend. One advantage of a peer-to-peer model is that the controlling source is much more difficult to trace. On the flip side, precise coordinated control of the zombies will be much more difficult to achieve.
Shift from network level attacks to service level attacks: Why not flood an email server with spoofed emails? A website with http requests? An SMS gateway with SMS messages? Service level messages tend to be more "normal-looking", and is therefore more difficult to block or filter.
Shift of focus towards desktop computers and personal devices as zombies: New networking technologies like broadband and 3G brings high-bandwidth, always-on computing to home desktop computers and mobiles devices. Very soon these devices will become attractive targets as DDoS zombies.
Shifft from platform dependence to platform independence: Current DDoS tools tend to be targeted at one platform, e.g. either Windows only, or Linux only. An obvious advancement will be a tool that is platform independent, and can work across OSes like Windows, Linux and MacOS. Technologies like Java may make this possible.

References

[1] "Trends in Denial of Service Attack Technology", www.cert.org/archive/pdf/DoS_trends.pdf
[2] Snort - The Opensource Network Intrusion Detection System, http://www.snort.org
[3] "The 'Tribe Flood Network' distributed denial of service attack tool", http://staff.washington.edu/dittrich/misc/tfn.analysis, Dave Dittrich, Oct 1999.
[4] "The "Stacheldraht" distributed denial of service attack tool, http://staff.washington.edu/dittrich/misc/stacheldraht.analysis, Dave Dittrich. Dec 2002.