*******************************************************************
*                                                                 *
*     The "Nazgul" Attack tool: Answers for Reverse Challenge     *
*                                                                 *
*******************************************************************

By G. Lamastra, P. Abeni, D. Sestito, E. Caprella
   F. Frosali, F. Coda Zabetta, G. Cangini
Be-Secure, Telecom Italia Labs
May 5th, 2002


1. Identify and explain the purpose of the binary.

After the reverse engineering process, we can conclude that this
binary seems to be a zombie server of a Distributed Denial-of-Service
network. It also provides a backdoor in the compromised host.


2. Identify and explain the different features of the binary. What
are its capabilities?

The binary (hereafter called nazgul, since this string was found
embedded in it) has the following capabilities:
- Remote command execution on the victim host; output data can be
  optionally feed back to the attacker.
- Remote shell, protected with a password; the password is encoded
  in the binary as TfOjG; the real password is derived by subtracting
  1 to each ASCII character (that is: SeNiF); see analysis.html
  for further explanations
- UDP Flood attack
- UDP/DNS Flood attack
- ICMP Flood attack
- TCP SYN Flood attack
A detailed description of the attacks is included in the analysis.html
file.

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

The encoding/decoding process is detailed in the source code at
line 1111 (scramble) and 1125 (descramble). It basically use an
obfuscation techinque, applied on the packet payload starting with
the third byte (bytes 0,1 of the payload are used to provide a kind of
packet identification and must be equal to 0x02,0x00 for any packet).
The descrambling algorithm is the following:
We assume that the *in and *out buffer contains the whole packet;
the scrambling/descrambling process does not touch the first two
bytes (the packet "signature"); len is the length of the entire IP
payload.
In the binary implementation, a pointer to the third byte of the
obfuscated payload is passed to the descrambling function, which
operate only on the effective data and not on the signature, which
is unmodified.

void descramble(int len, char *in, char *out)
{
    int i;
    out[0] = in[0];
    out[1] = in[1];
    out[2] = in[2] - 23;
    for (i = 3; i < len; ++ i) out[i] = in[i] + out[i - 1] + 23;
}

The scrambling algorithm is the following:

void scramble(int len, char *in, char *out)
{
    int i;
    out[0] = in[0];
    out[1] = in[1];
    out[2] = in[2] + 23;
    for (i = 3; i < len; ++ i) out[i] = in[i] - in[i - 1] - 23;
}


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

Command sequence can be identified with the following pattern:
IP.protocol == 11 && IP.payload[0] == 0x02

Response sequence can be identified with the following pattern:
IP.protocol == 11 && IP.payload[0] == 0x03

The weakness is given by the use of fixed elements in the obfuscation
process; hence, any process which use a fixed IP protocol number,
a fixed TCP (or UDP) port can be identified using a match on the 
protocol identifier.
Moreover, we can also try to identify anomalous packets for a given
protocol by looking at the effective length of the payload; for
example, nazgul control/response packet have to be greater than 200
bytes.
If a linear obfuscation algorithm is used, it is also possible to
extract some statistical information on the data payload and use this
information to do a cross-correlation on network traffic to match
"interesting" packets (i.e. packets with a high cross-correlation
index with a given set of known control packet).


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

The binary is stripped ans statically linked; this seems to be the
most effective measure used by the attacker, since it makes the
analysis process much more complicated. The remote-shell password has
been obfuscated with a trivial algorithm; the communication protocol
uses a scrambling algorithm which makes packet analysis fairly difficult,
if the algorithm is not known.


6. Identify two tools in the past that have demonstrated similar
functionalities
We believe that TFN and mstream had similar functionalities; mstream
provides remote shell which is password protected and a ACK TCP flood
functionality. nazgul is more evolved than mstream, because it provides
different patterns of attack, communication protocol obfuscation and
remote shell password obfuscation.
TFN uses an IP protocol to communicate between clients and daemon (the
equivalent of our nazgul zombie); however, TFN prefers to use a well
known ICMP_ECHOREPLY packet. TFN (like nazgul) use simple numbers to
identify commands; moreover, nor TFN neither nazgul support any form
of client authentication; they will accept packets from any client that
matches the protocol.


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

We believe that the tool has been created by someone with an average
level of skill. 
Nazgul seems to be assembled using pieces from other tools; so we
assume that the person who created it also studied some previous tools
and tried to do something better. The obfuscation process is trivial, so
we think that this person is not an expert programmer, otherwise a better
and more complicated obfuscation technique would have been adopted.

The use of a static linked executable is trivial but also very effective;
however, the attacker should at least know the implications of using the
-static switch when compiling the code. However, we cannot assume that
the person who created the code and the person who compiled and installed
it are the same

8. What advancements in tools with similar purpose can we expect in the
future?

Nazgul only obfuscate data (the shell password) and the communication
protocol; in our opinion, a possible evolution leap would be source
code obfuscation; if we analyze obfuscated C programs, they are almost
as impossible to understand as their assembly counterparts.
Code obfuscation requires an high programming skill in order to be
effective.

Using symmetric encryption for data communication makes the analysis
a bit harder; however, using a password which shows up as cleartext
in the .data section (hence, it will show up in a strings dump)
does very little for complicating the analysis. Instead, asymmetric 
encryption could make this situation much worse; if the client has
a private key and use this private key to encrypt data and the zombie
has a kind of "public" key to decrypt data, it could be very difficult
to build a working client from a reverse-engineered binary.

As last advancement, we think of a worm like duplication process; if
the zombie client is augmented with a worm-like engine which can
scan for some vulnerability, exploit it and transfer on a different
system, the building of the DDoS network could be extremely efficient
and the resulting attack could be devastating.