© by Als and Vizzy, 2002.
[Ukraine - United Kingdom] Team
answers.html
~~~~~~~~~~


1. Identify and explain the purpose of the binary.

This file is an ELF executable, developed for Linux Operation System. It was written in C, using compiler 2.7.2.1.2 (it may not be true, this number present in ELF .comment section and might be tampered with). It's statically linked with libc5, on what shows a text string inside binary "The Linux C library 5.3.12". Again, it need not be. Command `file ./the-binary` gives following result: "the-binary: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, stripped". Executable does not use dynamic libraries, thus it is not tied to specific libraries versions.
This program appeared to be a multifunctional remote administration tool, which after been installed on a computer running Linux operating system, can be used later to gain unauthorised root access to that system and remotely instructed to perform several types of "flooding" denial-of-service attacks against specified IP address(es).

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

After detailed analysis of the binary code in IDA interactive disassembler, we have identified the following. Binary will work only started with root privileges. It runs as a daemon (fork on start) and changes name of the process to "[mingetty]". Then it opens raw socket and waits for IP packets with protocol number 0x0B (seems like an unregistered protocol, which could be used at one's discretion). Packets are decrypted with a simple algorithm and then, depending on packet data, program calls one of the requested features. There are 12 different features, we'll name only significant here (see analysis.html for the detailed description of every feature and subroutines):

* bind root shell on 23281 TCP port.
* execute command.
* execute command and return output.
* DNS flood using name servers from binary internal list.
* DNS flood using supplied name servers.
* TCP SYN flood with spoofed source addresses.
* UDP/ICMP flood.


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

Data encoding is pretty simple. First data byte is incremented by 0x17. Then each next is a sum of previous byte plus 0x17. Our decode procedure, written in C, is shown below:

void decode (char *dst, char *src, int len) {
  int i = len;
  int j = i;
  int b;
  
  while(i >= 0) {
    if (i == 0) {
      b = src[i] - 0x17;
    } else {
      b = (src[i] - src[i-1]) - 0x17;
    }
    while (b < 0) { 
      b = b + 0x100;
    }
    dst[j] = b;
    i--;
    j--;
  }
}
We've written a decoder for the sample packet.
decode.c

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

One of the methods is an interception on routers, on server itself or on servers in the same ethernet segment (sniffing) and analysing of IP traffic, where number of IP protocol is not standard. In particular, the-binary uses IP protocol number 0x0B, which does not belong to any of the existing IP protocols.

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

As we've seen, there is no serious protection against reverse-engineering. Let's just underline some minor things:

- statically linked and stripped executable; Made so to run on different Linux versions, but as a side-effect, much harder to reverse, since all called functions has no symbol names.
- two quick fork()'s one after another. It seems as a very primitive anti-debugging trick, which might fool gdb, but to us armed with IDA, gives just a surprised smile.

6. Identify two tools in the past that have demonstrated similar functionality.

We didn't understand exactly the deep meaning of this question. Whether we talk here about remote administration tools (for linux, various rootkit's or meant BackOrifice and NetBus?) or about denial-of-service tools (doomDNS, dnsabuser.c, syn-flood.. etc). Moreover, there are might be dozen of tools known to us, or to underground community, but not known to jury.




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

He is a tall, blond and goes skating. He also listens to "Eminem". Oh, well no.. I bet he prefer "Rammstein".

We believe it's "less than average level". Denial-of-service attacks are easy to rip from well-documented sources, but the rest and, what is called "basic programming" seems to be far from ideal. Bugs implementing attacks repeat counters (or is it feature?), weird realization of byte by byte encoding via sprintf(), static name servers list and DNS queries... Traffic encryption is very simple, and probably shows that author had no experience with cryptography, because he didn't pick an algo which is also simple to implement, but much more stronger. Root shell password is stored shifted by one letter and immediately draws attention.. and 'SeNiF', is that a nickname? So, the quality is not high, however the tool works and brings all required functionality.

* Additional question 2. What advancements in tools with similar purposes can we expect in the future?

- Stronger network traffic encryption, using digital signatures to prevent others from issuing commands to server.
- Encryption of the binary to make reversing harder and some real anti-debugging (anti-disassembling) code.
- Hiding the-binary from a process list showed by 'ps' and 'top'. Mask into Loadable Kernel Modules.
- More features. As long as your creativity allows. But for a war tool, we suggest adding distributed DoS feature, nuke's and remote opening of the CD-ROM drive, to remind always-tired admin about coffee break.
- Worm functionality.
- Porting to Windows platform. xDSL users are piece of cake to recruit them as a flooders.